subagent-driven-development

name	subagent-driven-development
description	Use when executing implementation plans with independent tasks in the current session
domain	development
author	oyi77
license	Apache-2.0
subdomain	software-development
tags	["coding","driven","software-engineering","subagent","testing"]
version	1.0.0

persona: name: "Domain Expert" title: "Master of Subagent Driven Development" expertise: ['Specialized Knowledge', 'Best Practices', 'Industry Standards'] philosophy: "Excellence through expertise." credentials: ['Industry leader', 'Practiced expert', 'Thought leader'] principles: ['Quality first', 'Continuous improvement', 'Evidence-based decisions', 'Customer focus']

Subagent-Driven Development

World-Class Expert Persona

Kent Beck - Creator of Extreme Programming, Test-Driven Development Pioneer

• Credentials: Author of "Extreme Programming Explained", "Test-Driven Development by Example", pioneered XP methodology
• Expertise: Agile methodologies, iterative development, team collaboration, evolutionary design, continuous feedback
• Philosophy: "Make it work, make it right, make it fast" - Small, safe steps with continuous feedback
• Core Principles:
  • Small batches reduce risk
  • Fresh perspective catches mistakes
  • Review early, review often
  • Independent tasks enable parallelism
  • Feedback loops accelerate learning
  • Specialization improves quality

Overview

Execute plan by dispatching fresh subagent per task, with two-stage review after each: spec compliance review first, then code quality review.

Anti-Rationalization Table

Rationalization	Reality
"I'll figure it out as I go"	A structured approach saves time and reduces errors. Follow the workflow in this skill rather than improvising.
"I already know this topic"	Familiarity breeds shortcuts. Use the checklist to verify you haven't missed critical steps.
"This doesn't apply to my situation"	The patterns here generalize across contexts. Adapt, don't skip — the underlying principles hold.
"One more tool will fix it"	Adding complexity rarely solves process gaps. Master the core workflow first.

When to Use

Trigger phrases:

• "subagent driven development"

• "Implementation plan with independent tasks"

• "Stay in same session preferred"

• "Fresh subagent per task (no context pollution)"

• Implementation plan with independent tasks

• Stay in same session preferred

• Fresh subagent per task (no context pollution)

• Two-stage review needed

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)

When NOT to Use

• When tasks are tightly coupled (use sequential execution)
• When you need parallel session execution (use executing-plans)
• When there's no implementation plan
• When you need to stay in the same subagent context

Quick Reference

Process:

1. Dispatch fresh subagent per task
2. First review: spec compliance
3. Second review: code quality
4. Iterate if needed
5. Move to next task

Key advantage: Fresh subagent = no context pollution

Common Mistakes

• Using same subagent for multiple tasks (context pollution)
• Skipping the two-stage review
• Not verifying spec compliance before code quality
• Trying to use for tightly coupled tasks
• Not following the plan structure

The Process

1. Read plan, extract tasks with full text
2. Dispatch implementer subagent
3. First review: spec compliance
4. Second review: code quality
5. Fix if needed
6. Mark task complete
7. Repeat for remaining tasks [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

**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

**Cost:**
- More subagent invocations (implementer + 2 reviewers per task)
- Controller does more prep work (extracting all tasks upfront)
- Review loops add iterations
- But catches issues early (cheaper than debugging later)

## 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

## Common Rationalizations

| Rationalization | Reality |
|---|---|
| "I'll do this later" | Explain why this excuse is wrong for this skill |
| "This is simple, skip steps" | Even simple tasks benefit from process |

## Verification

After completing this skill, confirm:

- [ ] All existing tests pass after code changes are applied
- [ ] Error handling covers documented failure modes and edge cases
- [ ] All required outputs generated
- [ ] Success criteria met

## Process

1. Analyze the task requirements
2. Apply domain expertise
3. Verify output quality