Execute a plan by dispatching a fresh subagent for each task, followed by a two-stage review after each task: first a spec compliance review, then a code quality review.
Why use subagents: You delegate tasks to specialized agents with isolated context. By precisely crafting their instructions and context, you can ensure they stay focused and successfully complete the task. They should never inherit your session context or history—you construct only what they need. This also preserves your own context for coordinating the work.
Core principle: Fresh subagent for each task + two-stage review (first spec, then quality) = high quality, fast iteration
Continuous execution: Do not pause between tasks to confirm with your human partner. Execute all tasks in the plan without interruption. The only reasons to stop are: a BLOCKED state you cannot resolve, ambiguity that genuinely prevents progress, or all tasks complete. "Should I continue?" prompts and progress summaries waste their time—they asked you to execute the plan, so execute it.
When to use
digraph when_to_use {
"Have implementation plan?" [shape=diamond];
"Tasks mostly independent?" [shape=diamond];
"Stay in this session?" [shape=diamond];
"subagent-driven-development" [shape=box];
"executing-plans" [shape=box];
"Manual execution or brainstorm first" [shape=box];
"Have implementation plan?" -> "Tasks mostly independent?" [label="yes"];
"Have implementation plan?" -> "Manual execution or brainstorm first" [label="no"];
"Tasks mostly independent?" -> "Stay in this session?" [label="yes"];
"Tasks mostly independent?" -> "Manual execution or brainstorm first" [label="no - tightly coupled"];
"Stay in this session?" -> "subagent-driven-development" [label="yes"];
"Stay in this session?" -> "executing-plans" [label="no - parallel session"];
}
Comparison with Executing Plans (parallel session):
- Same session (no context switching)
- Fresh subagent for each task (no context contamination)
- Two-stage review after each task: first spec compliance, then code quality
- Faster iteration (no human intervention between tasks)
Process
digraph process {
rankdir=TB;
subgraph cluster_per_task {
label="Per Task";
"Dispatch implementer subagent (./implementer-prompt.md)" [shape=box];
"Implementer subagent asks questions?" [shape=diamond];
"Answer questions, provide context" [shape=box];
"Implementer subagent implements, tests, commits, self-reviews" [shape=box];
"Dispatch spec reviewer subagent (./spec-reviewer-prompt.md)" [shape=box];
"Spec reviewer subagent confirms code matches spec?" [shape=diamond];
"Implementer subagent fixes spec gaps" [shape=box];
"Dispatch code quality reviewer subagent (./code-quality-reviewer-prompt.md)" [shape=box];
"Code quality reviewer subagent approves?" [shape=diamond];
"Implementer subagent fixes quality issues" [shape=box];
"Mark task complete in TodoWrite" [shape=box];
}
"Read plan, extract all tasks with full text, note context, create TodoWrite" [shape=box];
"More tasks remain?" [shape=diamond];
"Dispatch final code reviewer subagent for entire implementation" [shape=box];
"Use superpowers:finishing-a-development-branch" [shape=box style=filled fillcolor=lightgreen];
"Read plan, extract all tasks with full text, note context, create TodoWrite" -> "Dispatch implementer subagent (./implementer-prompt.md)";
"Dispatch implementer subagent (./implementer-prompt.md)" -> "Implementer subagent asks questions?";
"Implementer subagent asks questions?" -> "Answer questions, provide context" [label="yes"];
"Answer questions, provide context" -> "Dispatch implementer subagent (./implementer-prompt.md)";
"Implementer subagent asks questions?" -> "Implementer subagent implements, tests, commits, self-reviews" [label="no"];
"Implementer subagent implements, tests, commits, self-reviews" -> "Dispatch spec reviewer subagent (./spec-reviewer-prompt.md)";
"Dispatch spec reviewer subagent (./spec-reviewer-prompt.md)" -> "Spec reviewer subagent confirms code matches spec?";
"Spec reviewer subagent confirms code matches spec?" -> "Implementer subagent fixes spec gaps" [label="no"];
"Implementer subagent fixes spec gaps" -> "Dispatch spec reviewer subagent (./spec-reviewer-prompt.md)" [label="re-review"];
"Spec reviewer subagent confirms code matches spec?" -> "Dispatch code quality reviewer subagent (./code-quality-reviewer-prompt.md)" [label="yes"];
"Dispatch code quality reviewer subagent (./code-quality-reviewer-prompt.md)" -> "Code quality reviewer subagent approves?";
"Code quality reviewer subagent approves?" -> "Implementer subagent fixes quality issues" [label="no"];
"Implementer subagent fixes quality issues" -> "Dispatch code quality reviewer subagent (./code-quality-reviewer-prompt.md)" [label="re-review"];
"Code quality reviewer subagent approves?" -> "Mark task complete in TodoWrite" [label="yes"];
"Mark task complete in TodoWrite" -> "More tasks remain?";
"More tasks remain?" -> "Dispatch implementer subagent (./implementer-prompt.md)" [label="yes"];
"More tasks remain?" -> "Dispatch final code reviewer subagent for entire implementation" [label="no"];
"Dispatch final code reviewer subagent for entire implementation" -> "Use superpowers:finishing-a-development-branch";
}
Model selection
Use the least capable model that can handle each role, to save cost and improve speed.
Mechanical implementation tasks(isolated functions, clear specs, 1-2 files): use a fast, cheap model. When the plan specs are clear, most implementation tasks are mechanical.
Integration and judgment tasks(multi-file coordination, pattern matching, debugging): use a standard model.
Architecture, design, and review tasks: use the strongest available model.
Task complexity signals:
- Touches 1-2 files with complete specs → cheap model
- Touches multiple files with integration concerns → standard model
- Requires design judgment or broad understanding of the codebase → strongest model
Handling implementer statuses
Implementer subagents report one of four statuses. Handle each appropriately:
DONE: Proceed to the spec compliance review.
DONE_WITH_CONCERNS: The implementer completed the work but flagged concerns. Read these concerns before continuing. If a concern involves correctness or scope, address it before the review. If it is just an observation (e.g., "this file is getting large"), note it and continue with the review.
NEEDS_CONTEXT: The implementer needs information that was not provided. Provide the missing context and re-dispatch.
BLOCKED: The implementer cannot complete the task. Evaluate 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, split it into smaller parts
- If the plan itself is wrong, escalate to the human
NeverIgnore reporting, and do not force the same model to retry when there is no change. If the implementer says it is stuck, something needs to change.
Prompt template
./implementer-prompt.md- Dispatch implementer subagent./spec-reviewer-prompt.md- Dispatch spec compliance reviewer subagent./code-quality-reviewer-prompt.md- Dispatch code quality reviewer subagent
Example workflow
You: I'm using Subagent-Driven Development to execute this plan.
[Read plan file once: docs/superpowers/plans/feature-plan.md]
[Extract all 5 tasks with full text and context]
[Create TodoWrite with all tasks]
Task 1: Hook installation script
[Get Task 1 text and context (already extracted)]
[Dispatch implementation subagent with full task text + context]
Implementer: "Before I begin - should the hook be installed at user or system level?"
You: "User level (~/.config/superpowers/hooks/)"
Implementer: "Got it. Implementing now..."
[Later] Implementer:
- Implemented install-hook command
- Added tests, 5/5 passing
- Self-review: Found I missed --force flag, added it
- Committed
[Dispatch spec compliance reviewer]
Spec reviewer: ✅ Spec compliant - all requirements met, nothing extra
[Get git SHAs, dispatch code quality reviewer]
Code reviewer: Strengths: Good test coverage, clean. Issues: None. Approved.
[Mark Task 1 complete]
Task 2: Recovery modes
[Get Task 2 text and context (already extracted)]
[Dispatch implementation subagent with full task text + context]
Implementer: [No questions, proceeds]
Implementer:
- Added verify/repair modes
- 8/8 tests passing
- Self-review: All good
- Committed
[Dispatch spec compliance reviewer]
Spec reviewer: ❌ Issues:
- Missing: Progress reporting (spec says "report every 100 items")
- Extra: Added --json flag (not requested)
[Implementer fixes issues]
Implementer: Removed --json flag, added progress reporting
[Spec reviewer reviews again]
Spec reviewer: ✅ Spec compliant now
[Dispatch code quality reviewer]
Code reviewer: Strengths: Solid. Issues (Important): Magic number (100)
[Implementer fixes]
Implementer: Extracted PROGRESS_INTERVAL constant
[Code reviewer reviews again]
Code reviewer: ✅ Approved
[Mark Task 2 complete]
...
[After all tasks]
[Dispatch final code-reviewer]
Final reviewer: All requirements met, ready to merge
Done!
Advantages
Compared to manual execution:
- Subagents naturally follow TDD
- Fresh context for each task (no confusion)
- Parallel-safe (subagents do not interfere with each other)
- Subagents can ask questions (before work and during work)
Compared to Executing Plans:
- Same session (no handoff)
- Continuous progress (no waiting)
- Automated review checkpoints
Efficiency gains:
- No file reading overhead (the controller provides the full text)
- The controller precisely curates the required context
- Subagents receive complete information in advance
- Questions surface before work begins (not after)
Quality gates:
- Self-review catches issues before handoff
- Two-stage review: spec compliance, then code quality
- The review loop ensures fixes actually work
- Spec compliance prevents over/under-building
- Code quality ensures the implementation is well built
Cost:
- More subagent calls (1 implementer + 2 reviewers per task)
- The controller does more preparation work (extract all tasks in advance)
- The review loop adds iterations
- But it catches issues early (cheaper than debugging later)
Red flags
Never:
- Start implementation on the main/master branch without the user's explicit consent
- Skip review (spec compliance or code quality)
- Continue with unresolved issues
- Dispatch multiple implementer subagents in parallel (they will conflict)
- Let subagents read the plan file (provide the full text instead)
- Skip scenario-setting context (subagents need to understand where the task fits)
- Ignore subagents' questions (answer them before letting them continue)
- Accept "close enough" on spec compliance (spec reviewer finds issues = incomplete)
- Skip the review loop (reviewer finds issues = implementer fixes = review again)
- Let implementer self-review replace real review (both are needed)
- Start code quality review before spec compliance is ✅(wrong order)
- Move to the next task while either review still has unresolved issues
If a subagent asks a question:
- Answer clearly and completely
- Provide additional context if needed
- Do not rush them into implementation
If the reviewer finds issues:
- The implementer (same subagent) fixes them
- The reviewer reviews again
- Repeat until approved
- Do not skip re-review
If a subagent's task fails:
- Dispatch a fix subagent with specific instructions
- Do not try to fix it manually (context contamination)
Integration
Required workflow skills:
- superpowers:using-git-worktrees - Ensure an isolated workspace (create one or verify an existing workspace)
- superpowers:writing-plans - Create a plan for this skill's execution
- superpowers:requesting-code-review - Code review template for the reviewer subagent
- superpowers:finishing-a-development-branch - Complete development after all tasks
Subagents should use:
- superpowers:test-driven-development - Subagents follow TDD for each task
Alternative workflow:
- superpowers:executing-plans - For parallel sessions, rather than same-session execution