// Use when executing implementation plans with independent tasks in the current session
| name | subagent-driven-development |
| description | Use when executing implementation plans with independent tasks in the current session |
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
vs. Executing Plans:
Read plan, extract all tasks with full text, note context, create todo list
For each task:
Dispatch spec reviewer subagent
Dispatch code quality reviewer subagent
Mark task complete
Repeat for remaining tasks
After all tasks: Use finishing-a-development-branch skill
When dispatching subagents, use the runSubagent tool:
runSubagent(
prompt: "Detailed task description with full context",
description: "Brief 3-5 word summary"
)
For implementer:
runSubagent(
prompt: "Implement Task 1: [full task text from plan]
Context: [relevant project context]
Requirements:
- Follow TDD
- Commit when done
- Self-review before finishing
Return: Summary of implementation and any issues found",
description: "Implement [component name]"
)
For spec reviewer:
runSubagent(
prompt: "Review implementation against spec.
Task spec: [task requirements]
Check:
- All requirements met
- Nothing extra added
- Tests cover requirements
Return: ✅ Spec compliant OR ❌ Issues: [list]",
description: "Spec review task N"
)
For code quality reviewer:
runSubagent(
prompt: "Review code quality of recent changes.
Review for:
- Clean code principles
- Proper error handling
- Test coverage
- No obvious bugs
Return: Strengths, Issues (by severity), Assessment",
description: "Code review task N"
)
Never:
If subagent asks questions:
If reviewer finds issues:
Required workflow skills:
Subagents should use:
You MUST use this before any creative work - creating features, building components, adding functionality, or modifying behavior. Explores user intent, requirements and design before implementation.
Use when facing 2+ independent tasks that can be worked on without shared state or sequential dependencies
Use when you have a written implementation plan to execute with review checkpoints
Use when implementation is complete, all tests pass, and you need to decide how to integrate the work - guides completion of development work by presenting structured options for merge, PR, or cleanup
Use when receiving code review feedback, before implementing suggestions, especially if feedback seems unclear or technically questionable - requires technical rigor and verification, not performative agreement or blind implementation
Use when completing tasks, implementing major features, or before merging to verify work meets requirements