القائمة
Structured dev workflows via /brainstorm, /write-plan, /execute-plan. Use when breaking down complex projects into systematic steps.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
Builds multi-repo context hubs and compiled markdown knowledge maps. Use when profiling repo portfolios or assembling LLM-ready cross-repo knowledge bases.
Builds per-repo code graphs in JSON and markdown-ready derived artifacts. Use when you need blast radius, symbol-level maps, import graphs, inheritance, or test links.
Context-driven AI development with AGENTS.md, repo knowledge bases, Claude Code, Codex, and Copilot. Use when adopting repo-native AI workflows or multi-repo setups.
Technical writing for READMEs, ADRs, API docs, and changelogs. Use when revising or consolidating a repo documentation folder.
Design, implement, and troubleshoot NUKE-based CI/CD pipelines for .NET services with fast local-to-CI feedback loops. Use when creating or refactoring `nuke/Build.cs` target graphs, tuning `DependsOn`/`After`/`Triggers`/`OnlyWhenDynamic` behavior, orchestrating unit/API/DB test categories, merging and publishing coverage and test reports, building and pushing Docker images with traceable tags and digests, producing artifact contracts such as `deploy.env`, and diagnosing flaky or slow pipeline execution. For service code changes use $software-csharp-backend, for NUnit fixture design use $qa-testing-nunit, and for safe logging rewrites use $dev-structured-logs.
Systematic debugging for crashes, regressions, flakes, and production bugs. Use when diagnosing stack traces, logs, traces, or profiling data.
| name | dev-workflow-planning |
| description | Structured dev workflows via /brainstorm, /write-plan, /execute-plan. Use when breaking down complex projects into systematic steps. |
This skill enables structured, systematic development workflows. The assistant should apply these patterns when users need to break down complex projects, create implementation plans, or execute multi-step development tasks with clear checkpoints.
Inspired by: Obra Superpowers patterns for structured agent workflows.
| Command | Purpose | When to Use |
|---|---|---|
/brainstorm | Generate ideas and approaches | Starting new features, exploring solutions |
/write-plan | Create detailed implementation plan | Before coding, after requirements clarification |
/execute-plan | Implement plan step-by-step | When plan is approved, ready to code |
/checkpoint | Review progress, adjust plan | Mid-implementation, after major milestones |
/summarize | Capture learnings, document decisions | End of session, before context reset |
The assistant should invoke this skill when a user requests:
Purpose: Explore the problem space and generate potential solutions.
/brainstorm [topic or problem]
OUTPUT:
1. Problem Understanding
- What are we solving?
- Who is affected?
- What are the constraints?
2. Potential Approaches (3-5)
- Approach A: [description, pros, cons]
- Approach B: [description, pros, cons]
- Approach C: [description, pros, cons]
3. Questions to Resolve
- [List of unknowns needing clarification]
4. Recommended Approach
- [Selected approach with justification]
Purpose: Create a detailed, actionable implementation plan.
/write-plan [feature or task]
OUTPUT:
## Implementation Plan: [Feature Name]
### Goal
[Single sentence describing the outcome]
### Success Criteria
- [ ] Criterion 1
- [ ] Criterion 2
- [ ] Criterion 3
### Steps (with estimates)
#### Step 1: [Name] (~Xh)
- What: [specific actions]
- Files: [files to modify/create]
- Dependencies: [what must exist first]
- Verification: [how to confirm done]
### Risks & Mitigations
| Risk | Likelihood | Impact | Mitigation |
|------|-----------|--------|------------|
| Risk 1 | Medium | High | Plan B if... |
### Open Questions
- [Questions to resolve before starting]
When a plan will be executed with multiple subagents, each task must declare its dependencies explicitly. This enables the orchestrator to determine which tasks can run in parallel.
### Task Dependency Graph
| Task ID | Name | depends_on | Files | Agent Scope |
|---------|------|------------|-------|-------------|
| T1 | Setup database schema | [] | db/schema.sql | db-engineer |
| T2 | Create API routes | [T1] | src/routes/*.ts | backend-dev |
| T3 | Build auth middleware | [T1] | src/middleware/auth.ts | backend-dev |
| T4 | Frontend components | [] | src/components/*.tsx | frontend-dev |
| T5 | Integration tests | [T2, T3, T4] | tests/integration/*.test.ts | qa-agent |
Rules for dependency graphs:
depends_on: [] with explicit task IDs (empty array = no blockers).Swarm Waves (Accuracy-First) — Launch one subagent per unblocked task, in dependency-respecting waves. Wait for each wave to complete before launching the next. Best for production code and complex interdependencies.
Super Swarms (Speed-First) — Launch as many subagents as possible at once, regardless of dependencies. Best for prototypes and greenfield scaffolding. Expect merge conflicts.
See references/planning-templates.md for the full swarm-ready plan template.
Purpose: Implement the plan systematically with checkpoints.
/execute-plan [plan reference]
EXECUTION PATTERN:
1. Load the plan
2. For each step:
a. Announce: "Starting Step X: [name]"
b. Execute actions
c. Verify completion
d. Report: "Step X complete. [brief summary]"
3. After completion:
a. Run all verification criteria
b. Report final status
For production coding sessions, wrap /execute-plan with a delivery guardrail:
npm run test:analytics-gate)../scripts/git/feature-workflow.sh start <feature-slug>
cd .worktrees/<feature-slug>
# implement plan steps
../../scripts/git/feature-workflow.sh gate
../../scripts/git/feature-workflow.sh pr --title "feat: <summary>"
Key rules from production experience (Feb 2026):
See references/session-patterns.md for the full production evidence table and checkpoint protocol for long sessions.
Before broad edits, tests, or reviews — run a 60-second preflight:
pwd / git branch --show-current / ls -latest -e <path> to verify target paths before heavy commandsnpx <tool> --help to validate flags before first use[], *, ?, or spacesSee references/operational-checklists.md for the full git/branch safety preflight, E2E/server preflight, shell safety gate, and SDK type verification.
PATTERN: Test assumptions before committing
Before implementing:
1. State hypothesis: "If we [action], then [expected outcome]"
2. Define experiment: "To test this, we will [minimal test]"
3. Execute experiment
4. Evaluate: "Hypothesis confirmed/rejected because [evidence]"
5. Proceed or pivot based on result
Build in verifiable increments: smallest testable unit → implement and verify → expand scope → verify at each expansion → integrate and verify whole.
See references/planning-templates.md for an authentication feature example with 5 increments.
PATTERN: Maintain visible progress
[X] Step 1: Create database schema
[X] Step 2: Implement API endpoints
[IN PROGRESS] Step 3: Add frontend form
[ ] Step 4: Write tests
Current: Step 3 of 4 (75% complete)
Blockers: None
Next: Complete form validation
Limit concurrent work: individual (2-3 tasks), team stories (team size + 1), in-progress column (3-5 items), code review (2-3 PRs). If limits are never reached, lower them. If constantly blocked, investigate the bottleneck.
See references/planning-templates.md for the full WIP limits reference and setting guidelines.
For multi-step execution, constrain scope and checkpoint progress at milestone boundaries.
1-2 deliverables only.At each milestone, record:
Stop and rescope when any occur:
See references/session-scope-budgeting.md for full scope budgeting model and enforcement rules.
Session initialized.
- Project: [name]
- Goal: [today's objective]
- Context loaded: [files, previous decisions]
- Plan status: [steps remaining]
Ready to continue from: [last checkpoint]
/summarize
OUTPUT:
## Session Summary
### Completed
- [List of completed items]
### In Progress
- [Current state of incomplete work]
### Decisions Made
- [Key decisions with rationale]
### Next Session
- [ ] [First task for next time]
### Context to Preserve
[Critical information for continuity]
When faced with choices:
1. State the decision clearly
2. List options (2-4)
3. For each option: Pros / Cons / Effort / Risk
4. Recommendation with justification
5. Reversibility assessment
Example:
| Option | Pros | Cons | Effort | Risk |
|--------|------|------|--------|------|
| JWT | Stateless, scalable | Token management | 2 days | Low |
| Sessions | Simple, secure | Server state | 1 day | Low |
| OAuth only | No passwords | External dependency | 3 days | Medium |
Recommendation: Sessions for MVP, plan JWT migration for scale.
/write-plan with TDD:
Step 1: Write failing test
Step 2: Implement minimal code
Step 3: Verify test passes
Step 4: Refactor
Step 5: Add edge case tests
/brainstorm system design:
1. Requirements clarification
2. Component identification
3. Interface definition
4. Data flow mapping
5. Implementation plan
assets/template-dor-dod.md - Checklists for work readiness and completion.
assets/template-work-item-ticket.md - Ticket template with DoR/DoD and testable acceptance criteria.
Key sections: Definition of Ready / Done checklists, Acceptance Criteria templates (Gherkin), Estimation Guidelines (story point scale 1-21+), Planning Levels (Roadmap → Sprint → Task), Cross-Functional RACI.
| Anti-Pattern | Problem | Fix |
|---|---|---|
| No DoR | Unclear requirements discovered mid-sprint | Gate sprint entry with DoR |
| Soft DoD | "Done" means different things | Written DoD checklist |
| Mega-stories | Never finish, hard to track | Slice to <8 points |
| Missing AC | Built wrong thing | Gherkin format AC |
| No ownership | Work falls through cracks | RACI for every epic |
| Hope-based estimates | Always late | Use reference scale + buffer |
Note: AI can assist but should not replace human judgment on priorities and acceptance.
AI-generated criteria and estimates require human calibration before committing to them.