---
name: "subagent-driven-development"
description: "Execute a multi-task implementation plan in the current session by dispatching each task to an implementer sub-agent and then a reviewer sub-agent, with pre-flight plan review, model selection, status handling, and durable progress tracking between tasks. Use when the plan has independent tasks and you want them built and reviewed without burning main-session context. Triggers: work through the plan with subagents, delegate these tasks, build this out task by task."
---

Execute a plan by dispatching a fresh implementer subagent per task, a task review (spec compliance + code quality) after each, and a broad whole-branch review at the end.

**Why subagents:** delegate tasks to specialized agents with isolated context. Precisely craft their instructions so they stay focused. They never inherit your session's history — construct exactly what they need. This preserves your own context for coordination.

**Core principle:** fresh subagent per task + task review (spec + quality) + broad final review = high quality, fast iteration.

**Narration:** between tool calls, narrate at most one short line.

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

## When to Use
- You have an implementation plan with mostly-independent tasks
- You're staying in this session (not a parallel session — use executing-plans for that)
- Not tightly coupled tasks needing manual/sequential judgment

## The Process (per task)
1. Dispatch an implementer subagent with: the task's full text/brief, interfaces and decisions from earlier tasks, any ambiguity you've resolved, and a report contract (what to return).
2. If the implementer asks questions, answer them and re-dispatch.
3. Implementer implements, tests, commits, self-reviews, and reports one of four statuses (see below).
4. On DONE: dispatch a task-review subagent with the diff (git diff/log for the task's commit range) and the task's requirements — check spec compliance AND code quality.
5. If review finds Critical/Important issues: dispatch a fix subagent with the full findings list, then re-review.
6. Mark task complete in your todo list once review is clean.
7. Repeat for all tasks.
8. After all tasks: dispatch a final whole-branch code reviewer (broad review across the entire diff from the branch's merge-base).
9. Use the finishing-a-development-branch skill to wrap up.

## Pre-Flight Plan Review
Before dispatching Task 1, scan the plan once for conflicts — tasks that contradict each other or the plan's Global Constraints. Present everything found as one batched question before execution begins. If clean, proceed without comment.

## Model Selection
Use the least powerful model that can handle each role.
- Mechanical implementation (isolated functions, clear specs, 1-2 files): fast/cheap model
- Integration/judgment tasks (multi-file coordination, debugging): standard model
- Architecture/design tasks and the final whole-branch review: most capable model
- Always specify the model explicitly when dispatching — an omitted model inherits your session's (often most expensive) default.
- Turn count beats token price: a mid-tier model as the floor for reviewers/implementers-from-prose is often cheaper overall than a cheap model taking 2-3x the turns.

## Handling Implementer Status
- **DONE:** proceed to task review with the diff.
- **DONE_WITH_CONCERNS:** read the concerns. If about correctness/scope, address before review. If observational, note and proceed.
- **NEEDS_CONTEXT:** provide missing info, re-dispatch.
- **BLOCKED:** assess — provide more context and retry same model; escalate to a more capable model if reasoning-limited; break into smaller pieces if too large; escalate to the human if the plan itself is wrong. Never force the same model to retry without changing something.

## Handling Reviewer Findings
A finding that conflicts with what the plan's text requires is the human's decision — present the finding and the plan text, ask which governs. Don't dismiss it because the plan mandates it, and don't dispatch a contradicting fix without asking.

## Constructing Reviewer Prompts
- Don't add open-ended directives ("check all uses") without a concrete reason.
- Don't ask reviewers to re-run tests the implementer already ran on the same code.
- Never pre-judge findings for the reviewer ("don't flag X") — let the reviewer raise it and adjudicate afterward.
- Give the reviewer the binding Global Constraints verbatim (exact values/formats/relationships).
- Hand the reviewer the diff as a file reference where possible, not pasted into your context.
- A dispatch prompt describes one task, not the session's history — don't paste accumulated prior-task summaries.
- Record Minor findings for the final whole-branch review to triage.

## Durable Progress
Conversation memory does not survive compaction. Track progress in a durable ledger/todo list, not only in your head — re-dispatching completed tasks after losing context is the most expensive failure mode. If you lose your place, trust the ledger/git log over your own recollection.

## Prompt Templates
Use the requesting-code-review skill's reviewer template for the final whole-branch review.