Subagent-Driven Development: Fresh Agents per Task, Two Reviews per Diff

Introduction: The Two Quiet Failures of Solo Execution

A single agent executing its own big plan fails in two quiet ways. The first is context drift: by task six, the session is stuffed with diffs and half-remembered decisions from five earlier tasks, and the model attends to all of it. The second is self-grading: the agent that wrote the code is also the agent declaring it done, and nobody trusts a student who writes both the exam and the answers. The Superpowers subagent driven development skill attacks both problems structurally — a fresh subagent per task, a two-stage review after every task, and a broad whole-branch review at the end.

If executing-plans is the discipline of working a checklist honestly, subagent-driven-development is hiring a new worker for every task and refusing to take their word for it.

What the Subagent-Driven-Development Skill Actually Does

At its core the skill is one sentence: execute the plan by dispatching a fresh implementer subagent per task, run a task review (spec compliance plus code quality) after each one, and finish with a broad whole-branch review. The orchestrating session — the controller — never implements anything itself. It coordinates, packages, reviews, and records.

The isolation principle is the load-bearing design decision. Subagents never inherit the session’s context or history; the controller constructs exactly what each one needs and nothing more. That does two jobs at once: the worker stays focused on one task brief, and the controller preserves its own context for coordination instead of burning it on implementation detail.

The skill also refuses to babysit. Continuous execution is explicit: do not pause between tasks to ask “should I continue?” Conflicts and plan defects get settled as rulings, not stalls — recorded in the ledger with what being wrong costs. Four things stop a run: irreversible or destructive operations; security-sensitive actions; side effects outside the worktree such as a merge or push; and a plan so broken that every path forward is a guess.

Finally, there is the ledger. Conversation memory does not survive context compaction; the skill’s war stories include controllers that re-dispatched entire completed task sequences. So each plan owns a git-ignored workspace under .superpowers/sdd/ holding the ledger, task briefs, implementer reports, and review packages. After a compaction, the controller trusts the ledger and git log over its own recollection.

The Task Loop, Step by Step

Setup first: an isolated worktree, the plan read once with its spec and Global Constraints, and a pre-flight scan for internal conflicts. Then, per task:

1. Dispatch the implementer. Record the base commit first — the review diff needs it; the skill warns against HEAD~1, which silently truncates multi-commit tasks. A script extracts the task’s full text into a brief file, and the subagent is dispatched with it.
2. Implement, test, commit, self-review. The implementer returns DONE, DONE_WITH_CONCERNS, NEEDS_CONTEXT, or BLOCKED, each with a defined handling path; questions get answered fully, never rushed past.
3. Review the task. A script bundles the commit list, diff stat, and full diff into one file. The reviewer receives three paths (brief, report, diff) plus the binding global constraints, copied verbatim.
4. Fix loop if needed. A spec failure or any Critical or Important finding triggers a capped loop: fixes go back to the implementer, each round ends with a scoped re-review, and past the cap the controller adjudicates and parks findings with a written ruling.
5. Complete the task. One ledger line — commits, review clean or findings parked — then the next task. Never move on with an open Critical issue that is neither fixed nor parked-with-ruling.

When every task closes, the final whole-branch review runs on the most capable available model — the one dispatch where a cheap model defeats the purpose — and the skill hands off to finishing-a-development-branch to close out.

The Two-Stage Review: Spec Compliance First, Then Code Quality

Every task review must return both verdicts, and a report missing either one is rejected. Stage one asks the boring, brutal question: does this diff do exactly what the brief demanded — the exact values, exact formats, and exact stated relationships between components? To sharpen that check, the reviewer is handed the project’s binding constraints verbatim from the plan or spec, because that block is its attention lens. Stage two asks the craft question: YAGNI, test hygiene, structure — whether the code deserves to live. The reviewer’s own template carries those process rules.

The rules around the review are as deliberate as the review itself. Self-review never replaces the task review; both are required. No reviewer is dispatched without a diff file. And the controller must never pre-judge findings: if a dispatch prompt starts to contain “do not flag” or “at most Minor” — stop. That is the controller laundering its own review loop, a rationalization the skill names to catch.

Real Example: Dispatching Parallel Storage and Network Audits

Here is the dispatch discipline on a real job. SYNAS, a home server running 32 Docker containers across 26 networks, needed a health audit. The work decomposed into three lanes, two of which were textbook-parallel: a storage audit (images, containers, volumes, build cache) and a network audit (all networks, attachments, isolation quality, orphans). The lanes shared nothing — different commands, data, conclusions, zero file overlap — so the orchestrator dispatched both as one batched call, running concurrently while the dependent third lane waited.

The prompts followed the same contract as the task loop: one lane each, self-contained instructions, explicit constraints, a named output format, and least-privilege read-only toolsets — a storage auditor with a browser open is one accidental detour from a wasted run. What came back was evidence, not vibes: the storage agent surfaced roughly 1.9 GB of dangling images, 532 MB of dead build cache, and a container writing 1.87 GB into its own writable layer instead of a volume; the network agent mapped every attachment and delivered an isolation assessment. Headline claims got re-checked with fresh commands before the report shipped.

The rule that keeps this honest is the one people trip over: audit lanes are read-only, so they parallelize; implementation subagents never run in parallel. Two implementers editing the same tree is a guaranteed conflict, and the skill forbids it by name. Parallel dispatch across independent lanes is the domain of dispatching-parallel-agents, which composes with either execution skill.

Anatomy of an Agent Prompt That Works

Everything pasted into a dispatch prompt stays resident in the controller’s context for the session, so prompts get written like budget documents. Three properties carry the run:

• Focused. One task, never the session’s history. The skill cites a real dispatch that hit 42,000 characters, 99 percent of it pasted history. A fresh subagent needs its task, the interfaces it touches, and the global constraints — nothing else.
• Self-contained. The brief file is the single source of requirements — exact numbers, magic strings, signatures, and test cases live only there. Around it, the dispatch adds what the brief cannot know: interfaces and decisions from earlier tasks, and the controller’s resolution of any ambiguity spotted while reading it.
• Specific about output. The dispatch names a report file and a contract: the implementer writes the full narrative report to the file and returns only status, commits, a one-line test summary, and concerns. Artifacts move as files, not paste-back, so the controller’s context stays lean task after task.

Two clauses ride along on every dispatch. The no-subagents contract: the implementer never spawns its own reviewer or helpers — in real sessions, worker-spawned reviewers just re-reviewed the same diff from duplicate seats. And an explicitly named model, because an omitted model silently inherits the session’s most expensive one. The selection rule is the least powerful model that can do the role, with one caveat: turn count beats token price, so the cheapest models are a false economy on multi-step work.

When Subagent-Driven Development Beats Executing-Plans

Both skills run the same plans; the choice is a real decision with real costs.

The honest cost ledger: inline execution pays one context plus a final reviewer; subagent-driven development pays a fresh context per task and per review. You buy that with two things inline cannot give you — un-drifted attention on every task, and an independent gate before a defect compounds into the next one. The deeper criterion is review pressure: risky code deserves two verdicts per diff; a status sweep does not. As Anthropic’s guidance on building effective agents puts it, add coordination complexity only when the task structure demands it.

Related Deep Dives in the Series

• executing-plans — the sequential single-agent fallback, and the foundation this skill is built on.
• dispatching-parallel-agents — concurrency for genuinely independent tasks; composes with both execution skills.
• writing-plans and brainstorming — upstream: the loop only works when the plan is written in task-shaped units.
• verification-before-completion — the companion discipline: no completion claim without fresh evidence.
• finishing-a-development-branch and receiving-code-review — downstream: closing the branch, and how to take the findings when the reviewers are right.
• Superpowers Using Superpowers — the meta-skill: skill discovery and priority at the start of every session.
• Requesting Code Review — how to ask for review so problems surface before they cascade.

Frequently Asked Questions

Q: Do the subagents share my session’s context?
No — that is the point. Each subagent starts fresh, and the controller hand-builds its world: a brief file, interfaces from earlier tasks, global constraints, and an output contract.

Q: Doesn’t two reviews per task double the cost?
It raises it, deliberately, and bounds it: the review model scales to the diff’s size and risk, re-reviews are scoped to the fix only, and the fix loop has a hard cap with escalation. What you stop paying is the late-discovery tax — a spec violation found at task eight touches eight tasks’ worth of dependent work.

Q: What happens when the plan itself is wrong mid-run?
The Superpowers subagent driven development skill answers with a ruling, not a stall: the controller records the decision and its cost-if-wrong in the ledger and keeps going — unless one of the four named stop conditions applies.

Key Takeaways

• The Superpowers subagent driven development skill replaces one drifting context with many focused ones: a fresh implementer per task, built from a brief file instead of session history.
• Every task clears a two-stage gate — spec compliance, then code quality — with both verdicts mandatory and pre-judging the reviewer forbidden.
• Parallelism is earned, not assumed: read-only lanes like the SYNAS storage and network audits batch cleanly; implementation subagents never overlap.
• Dispatch prompts are focused, self-contained, and specific about output; models are chosen per role and always named explicitly.
• The ledger, not the chat, is the durable record — it survives compaction and prevents the costliest failure: re-running completed work.

Next in this series: executing plans — the single-agent path for plans that don’t need a review seat per task. Browse the full Skills We Use series index for every article.