subagent-driven-development

Read the plan once, create a ledger in the plan's workspace, then dispatch one fresh implementer subagent per task with a file-based brief. After each task, dispatch a task reviewer against the diff, run the fix loop if needed, and finish with a whole-branch review.

Subagent-driven development stays in the same session but gives each task a fresh subagent with isolated context and a review gate after every task. Direct plan execution keeps everything in one context, which risks pollution and skipped verification on longer plans.

Rounds one through three resume the original implementer with the findings verbatim; rounds four and five dispatch a fresh implementer on a more capable model. Every round ends with a scoped re-review, and after five rounds the controller adjudicates remaining findings with ledgered rulings.

No. The dispatch contract forbids implementers from spawning any subagents, including reviewers. Review arrives only from the controller after the implementer reports; a worker-spawned reviewer duplicates the task review and its verdict counts for nothing.

Progress is tracked in a per-plan ledger file, not conversation memory. After compaction, the controller reads the ledger and git log to see which tasks are complete and resumes at the first task without a completion line.

When the plan lists several small, same-shape edits like repeated one-line fixes across files, batch them into a single dispatch brief and review the combined diff as one unit. Reserve per-task dispatch for work needing its own judgment, tests, or review surface.