subagent-driven-development

Dispatch a fresh implementer subagent per task with a task brief file and report file, then run a task review on the diff. Track progress in a ledger file so completed tasks are never re-dispatched after context compaction.

Subagent-driven development runs in the same session but gives each task a fresh subagent with isolated context and a review after each task. Inline execution keeps everything in one context, which risks pollution and skipped reviews on long plans.

Rounds one through three resume the original implementer with the findings; rounds four and five dispatch a fresh implementer with fuller context. Each round ends with a scoped re-review, and after five rounds remaining findings are adjudicated and parked or escalated.

Conversation memory does not survive compaction, and controllers without a ledger have re-dispatched entire completed task sequences. The ledger records per-task completion lines and commit ranges so recovery relies on git history, not recollection.

No. Implementation subagents must run sequentially because parallel implementers conflict on the same working tree. Only one fix dispatch is used for final-review findings as well, to avoid redundant context rebuilds.

Skip it when tasks are tightly coupled and cannot be decomposed independently, or when no implementation plan exists yet. In those cases brainstorm or write the plan first, or use a parallel-session execution approach instead.