Skill: subagent-driven-development
name: subagent-driven-development description: Use when executing implementation plans with independent tasks in the current session
Subagent-Driven Development
Execute plan by dispatching fresh subagent per task, with two-stage review after each: spec compliance review first, then code quality review.
Core principle: Fresh subagent per task + two-stage review (spec then quality) = high quality, fast iteration
When to Use
dot
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"];
}
vs. Executing Plans (parallel session):
- •Same session (no context switch)
- •Fresh subagent per task (no context pollution)
- •Two-stage review after each task: spec compliance first, then code quality
- •Faster iteration (no human-in-loop between tasks)
The Process
Read plan, extract all tasks with full text, note context, create TodoWrite with all tasks, then dispatch implementer subagent per task with two-stage review:
- •Spec compliance review - Does code match requirements?
- •Code quality review - Is implementation well-built?
For each task:
- •Mark as in_progress
- •Dispatch implementer subagent
- •Handle subagent questions
- •Implementer self-reviews
- •Dispatch spec reviewer
- •If issues: implementer fixes, reviewer re-reviews
- •Dispatch code quality reviewer
- •If issues: implementer fixes, reviewer re-reviews
- •Mark as completed
Advantages
vs. Manual execution:
- •Subagents follow TDD naturally
- •Fresh context per task (no confusion)
- •Parallel-safe (subagents don't interfere)
- •Subagent can ask questions (before AND during work)
vs. Executing Plans:
- •Same session (no handoff)
- •Continuous progress (no waiting)
- •Review checkpoints automatic
Efficiency gains:
- •No file reading overhead (controller provides full text)
- •Controller curates exactly what context is needed
- •Subagent gets complete information upfront
- •Questions surfaced before work begins (not after)
Quality gates:
- •Self-review catches issues before handoff
- •Two-stage review: spec compliance, then code quality
- •Review loops ensure fixes actually work
- •Spec compliance prevents over/under-building
- •Code quality ensures implementation is well-built
Red Flags
Never:
- •Start implementation on main/master branch without explicit user consent
- •Skip reviews (spec compliance OR code quality)
- •Proceed with unfixed issues
- •Dispatch multiple implementation subagents in parallel (conflicts)
- •Make subagent read plan file (provide full text instead)
- •Skip scene-setting context (subagent needs to understand where task fits)
- •Ignore subagent questions (answer before letting them proceed)
- •Accept "close enough" on spec compliance (spec reviewer found issues = not done)
- •Skip review loops (reviewer found issues = implementer fixes = review again)
- •Let implementer self-review replace actual review (both are needed)
- •Start code quality review before spec compliance is ✅ (wrong order)
- •Move to next task while either review has open issues
If subagent asks questions:
- •Answer clearly and completely
- •Provide additional context if needed
- •Don't rush them into implementation
If reviewer finds issues:
- •Implementer (same subagent) fixes them
- •Reviewer reviews again
- •Repeat until approved
- •Don't skip the re-review
If subagent fails task:
- •Dispatch fix subagent with specific instructions
- •Don't try to fix manually (context pollution)
Integration
Required workflow skills:
- •superpowers:using-git-worktrees - REQUIRED: Set up isolated workspace before starting
- •superpowers:writing-plans - Creates the plan this skill executes
- •superpowers:requesting-code-review - Code review template for reviewer subagents
- •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 - Use for parallel session instead of same-session execution