// Use when a design exists and it's time to break it into tasks and execute with subagent dispatch and review
| name | implement |
| description | Use when a design exists and it's time to break it into tasks and execute with subagent dispatch and review |
Break a design into bite-sized TDD tasks, execute each with a fresh subagent, review every task before moving on.
Core principle: Small tasks + fresh subagents + two-stage review = high quality.
/architect or provided by user)Look for the most recent *-design.md in docs/plans/. If none found or multiple exist, ask the user which to use. If no design exists, suggest /architect first.
Each task must be:
Template per task:
### Task N: [Title]
**Goal**: [one sentence]
**Test**: [describe the test to write first]
**Implementation**: [describe the code to make it pass]
**Files**: [which files to create/modify]
**Acceptance Criteria**: [specific, testable]
docs/plans/YYYY-MM-DD-<name>-plan.md
Record base SHA: git rev-parse HEAD
For each task, in order:
Use Task tool with subagent_type: "tdd". In the prompt, include inline:
Context goes inline. The subagent receives everything it needs in the prompt.
When implementer completes, dispatch spec-reviewer via Task tool with subagent_type: "superpowers:code-reviewer". Include:
If FAIL: resume implementer to fix, then re-review.
Dispatch quality-reviewer via Task tool with subagent_type: "superpowers:code-reviewer". Include:
If critical issues: resume implementer to fix, then re-review.
Only proceed to next task when both reviews pass.
Implementation complete. Use
/qafor adversarial testing, or/refactorfor a quality pass.
| Mistake | Fix |
|---|---|
| Tasks too large (whole features) | One TDD cycle per task. If it takes >10 min, split it. |
| Expecting subagent to read plan files | Provide ALL context inline in the dispatch prompt. |
| Skipping review for "simple" tasks | Every task gets spec review + quality review. No exceptions. |
| Phase-based grouping instead of task list | Flat numbered list. Dependencies noted, not phase boundaries. |
| No plan file saved | Always save to docs/plans/YYYY-MM-DD-<name>-plan.md. |
| Moving on despite failed review | Fix first. Never proceed with review failures. |
| Not referencing next step | End with: "use /qa or /refactor when ready" |
Use EVERY TIME you need to run tests, verify tests pass, or check for regressions. ALWAYS use this instead of running eldev directly.
Use when code quality needs improvement after implementation, without changing behavior
Use when implementation is complete and you want to verify quality through adversarial testing that writes code and provides evidence
Use when requirements exist and a technical design is needed before implementation begins
Use when a new feature request, bug report, or work request needs requirements defined before implementation
Use when starting any conversation - establishes how to find and use skills, requiring Skill tool invocation before ANY response including clarifying questions