subagent-driven-development

Subagent-Driven Development

Core Principle

Fresh context per task, then review before moving on. The coordinator stays thin; workers get exact task context.

When To Use

• A plan exists and tasks are mostly independent.
• The implementation benefits from isolated context.
• The user wants parallel or delegated execution.
• The task is large enough that the main session would accumulate context rot.

Per-Task Protocol

1. Extract the full task text, files, constraints, and verification from the plan.
2. Dispatch one implementer subagent with only the needed context.
3. Require the subagent to report DONE, DONE_WITH_CONCERNS, NEEDS_CONTEXT, or BLOCKED.
4. Run spec-compliance review before code-quality review.
5. Fix review issues before starting the next task.
6. Run verification and record evidence.

Status Handling

• DONE: review and verify.
• DONE_WITH_CONCERNS: read concerns before review; resolve correctness or scope doubts.
• NEEDS_CONTEXT: provide missing context and re-dispatch.
• BLOCKED: change task size, model, context, or plan; do not force retries.

Red Flags

• Dispatching multiple implementers that edit the same files.
• Letting subagents read the whole plan instead of giving exact task text.
• Skipping spec review or code-quality review.
• Accepting “close enough” against the plan.

Output Contract

## Plan Source
## Task Queue
## Subagent Assignments
## Review Results
## Verification Evidence
## Blockers
## Remaining Work