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
中文简介正在准备中。当前显示原文说明。
实测评分 未实测
查看安装方法安装前可以查看交给 AI 代理的指令内容。
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
中文简介正在准备中。当前显示原文说明。