- Subagent-Driven (recommended)
- Inline Execution
Subagent-driven development
Thesubagent-driven-development skill dispatches a fresh subagent per task in the current session. Each subagent gets exactly the context it needs — nothing more. This keeps context clean, prevents confusion between tasks, and enables automatic two-stage review without waiting for human input.Core principle: Fresh subagent per task + two-stage review (spec compliance then code quality) = high quality, fast iteration.When this mode starts, the agent announces: “I’m using the subagent-driven-development skill to execute this plan.”The per-task loop
Extract all tasks upfront
Read the plan file once. Extract every task with its full text and context. Create a TodoWrite entry for each task. The agent does not re-read the plan file during execution — all content is already extracted.
Dispatch the implementer subagent
Provide the implementer with: the full task text, relevant context from the plan (architecture, tech stack, file structure), and the scene-setting description of where this task fits in the overall feature.The implementer gets exactly what it needs. It never reads the plan file itself.
Answer implementer questions
If the implementer asks questions before starting, answer them clearly and completely. Do not rush the subagent into implementation. Questions surfaced before work begins are cheaper to answer than ones discovered after.
Implementer implements, tests, and self-reviews
The implementer follows TDD for every step: write the failing test, watch it fail, write minimal code, watch it pass, commit. It self-reviews before reporting back. Self-review catches issues before the formal review stages.
Spec compliance review
Dispatch a spec reviewer subagent with the task requirements and the git commits produced. The reviewer checks: did the implementation deliver everything in the spec? Did it add anything not requested?If issues are found, the implementer (same subagent) fixes them and the spec reviewer reviews again. Repeat until approved. Do not proceed to code quality review until spec compliance is confirmed.
Code quality review
Dispatch a code quality reviewer subagent. The reviewer checks: Is the code well-built? Are there magic numbers, missing constants, unclear naming, or unnecessary complexity?If issues are found, the implementer fixes them and the reviewer reviews again. Repeat until approved.
Mark task complete and move to next
Mark the task as complete in TodoWrite. Proceed to the next task with a fresh subagent. Continue until all tasks are done.
Model selection
Use the least powerful model that can handle each role to save cost and increase speed:| Role | Task complexity signals | Model |
|---|---|---|
| Implementer | 1–2 files, clear spec, mechanical | Cheap/fast model |
| Implementer | Multi-file, integration concerns | Standard model |
| Spec reviewer | All tasks | Most capable model |
| Code quality reviewer | All tasks | Most capable model |
| Architecture/design judgment | Broad codebase understanding required | Most capable model |
Handling implementer status codes
Implementers report one of four statuses:DONE
DONE
Proceed to spec compliance review.
DONE_WITH_CONCERNS
DONE_WITH_CONCERNS
The implementer completed the work but flagged doubts. Read the concerns before proceeding. If they are about correctness or scope, address them before review. If they are observations (e.g., “this file is getting large”), note them and proceed to review.
NEEDS_CONTEXT
NEEDS_CONTEXT
The implementer needs information that was not provided. Provide the missing context and re-dispatch. Do not retry with the same instructions.
BLOCKED
BLOCKED
The implementer cannot complete the task. Assess the blocker:
- If it is a context problem, provide more context and re-dispatch with the same model
- If the task requires more reasoning, re-dispatch with a more capable model
- If the task is too large, break it into smaller pieces
- If the plan itself is wrong, escalate to the human
Red flags
Never start onmain/master without user consent, skip review stages, proceed with unfixed issues, dispatch multiple implementers in parallel, make a subagent read the plan file directly, accept “close enough” on spec compliance, or start the code quality review before spec compliance passes.What comes after execution
Both execution modes end by invoking thefinishing-a-development-branch skill. A final code reviewer subagent reviews the complete implementation before the branch completion options are presented.
Next: Finishing a branch
Verify tests, run a final review, and choose to merge, create a PR, keep the branch, or discard the work.