subagent-driven-development

name	subagent-driven-development
description	Use when executing implementation plans with independent tasks in the current session
metadata	{"user-invocable":true,"disable-model-invocation":true}

Subagent-Driven Development

Execute plan by creating focused work sessions per task, with review after each.

Why separate sessions: You delegate tasks to specialized contexts. By precisely crafting their instructions and context, you ensure they stay focused and succeed at their task. This also preserves your own context for coordination work.

Core principle: Fresh context per task + review = high quality, fast iteration

Continuous execution: Do not pause to check in with the user between tasks. Execute all tasks from the plan without stopping. The only reasons to stop are: blocked status you cannot resolve, ambiguity that genuinely prevents progress, or all tasks complete.

When to Use

Use when:

• Have implementation plan
• Tasks mostly independent
• Want to stay in current session

Don't use when:

• Tasks are tightly coupled
• Need to work in parallel session

The Process

Setup

1. Read plan file once
2. Extract all tasks with full text and context
3. Create inline checklist with all tasks

Per Task Loop

For each task:

1. Create focused work session with:

   • Specific scope (one task)
   • Full task text and context
   • Clear goal
   • Expected output

2. Handle questions - If the work session asks questions, answer clearly before letting them proceed

3. Review completion - When work session reports done:

   • Verify changes match requirements
   • Check code quality
   • Run tests
   • If issues found, create fix session

4. Mark complete - Update checklist

5. Continue to next task - No pause between tasks

After All Tasks

1. Run full test suite
2. Use /finishing-a-development-branch to complete

Handling Work Session Status

DONE: Proceed to review.

DONE_WITH_CONCERNS: Read concerns. If about correctness/scope, address before review. If observations, note and proceed.

NEEDS_CONTEXT: Provide missing information and restart work session.

BLOCKED: Assess blocker:

1. If context problem, provide more context
2. If task too complex, break into smaller pieces
3. If plan is wrong, escalate to user

Never ignore an escalation or force retry without changes.

Example Workflow

You: I'm using /subagent-driven-development to execute this plan.

[Read plan file once: docs/plans/feature-plan.md]
[Extract all 5 tasks with full text and context]
[Create checklist with all tasks]

Task 1: Hook installation script

[Create work session with full task text + context]

Work session: "Before I begin - should the hook be installed at user or system level?"

You: "User level (~/.config/hooks/)"

Work session: "Got it. Implementing now..."
[Later] Work session:
  - Implemented install-hook command
  - Added tests, 5/5 passing
  - Committed

[Review: verify changes, check quality, run tests]
[Mark Task 1 complete]

Task 2: Recovery modes

[Create work session with full task text + context]

Work session: [No questions, proceeds]
Work session:
  - Added verify/repair modes
  - 8/8 tests passing
  - Committed

[Review: finds missing progress reporting from spec]
[Create fix session to add progress reporting]
[Review again: approved]
[Mark Task 2 complete]

...

[After all tasks]
[Run full test suite]
[Use /finishing-a-development-branch]

Done!

Advantages

vs. Manual execution:

• Fresh context per task (no confusion)
• Natural test-driven development
• Can ask questions before AND during work

Efficiency gains:

• No file reading overhead (you provide full text)
• You curate exactly what context is needed
• Complete information upfront
• Questions surfaced before work begins

Quality gates:

• Review catches issues before moving on
• Verify changes match requirements
• Ensure implementation is well-built

Red Flags

Never:

• Start implementation on main/master branch without explicit user consent
• Skip reviews
• Proceed with unfixed issues
• Let work sessions read plan file (provide full text instead)
• Skip scene-setting context
• Ignore work session questions
• Move to next task while review has open issues

If work session asks questions:

• Answer clearly and completely
• Provide additional context if needed
• Don't rush them into implementation

If review finds issues:

• Create fix session with specific instructions
• Review again
• Repeat until approved
• Don't skip the re-review

Integration

Related workflows:

• Use /brainstorming to create design first
• Use /writing-plans to create the plan this executes
• Use /finishing-a-development-branch to complete after all tasks
• Use /test-driven-development principles in each work session