5.3 KiB
| name | description |
|---|---|
| subagent-driven-development | 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)
- 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).
- If the implementer asks questions, answer them and re-dispatch.
- Implementer implements, tests, commits, self-reviews, and reports one of four statuses (see below).
- 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.
- If review finds Critical/Important issues: dispatch a fix subagent with the full findings list, then re-review.
- Mark task complete in your todo list once review is clean.
- Repeat for all tasks.
- After all tasks: dispatch a final whole-branch code reviewer (broad review across the entire diff from the branch's merge-base).
- 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.