Use when requirements exist and a technical design is needed before implementation begins
한국어 요약은 준비 중입니다. 원문 설명을 표시하고 있습니다.
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 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 implementation is complete and you want to verify quality through adversarial testing that writes code and provides evidence
한국어 요약은 준비 중입니다. 원문 설명을 표시하고 있습니다.
Use when code quality needs improvement after implementation, without changing behavior
한국어 요약은 준비 중입니다. 원문 설명을 표시하고 있습니다.
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 starting any conversation - establishes how to find and use skills, requiring Skill tool invocation before ANY response including clarifying questions
한국어 요약은 준비 중입니다. 원문 설명을 표시하고 있습니다.