/subagent-driven-development

name: subagent-driven-development
description: The implementation engine. Routed to by /sprint (full plan, autonomous) and by executing-plans (scoped batch, checkpoint-gated). One fresh subagent per task — test-first via tdd — followed by spec-compliance review, quality review, and fresh-run verification. No single context accumulates drift, and nothing is accepted on a subagent's word.
disable-model-invocation: true

subagent-driven-development

One task, one fresh subagent, two reviews, proof on a fresh run. Routed to by `/sprint` (full plan, autonomous) and by `executing-plans` (one batch at a time, with human checkpoints between batches). The loop processes tasks in dependency order and never trusts a self-report.

Pre-flight

Read these, or STOP and surface the gap — never guess scope, command, or obligation:

• `{{PROJECT_DIR}}/.codearbiter/CONTEXT.md` — the `stage:` frontmatter (the maturity value) and project context.
• `{{PROJECT_DIR}}/.codearbiter/plans/<slug>.md` — the approved plan. Each task carries an exact path set and a verification command. This is the task source.
• `{{PROJECT_DIR}}/.codearbiter/specs/<slug>.md` — the approved spec. Each task's obligation traces to it. The spec-compliance review measures against it.
• `{{PROJECT_DIR}}/.codearbiter/tech-stack.md` — build, test, and verification invocations; file layout; the scope-to-author mapping.
• `{{PROJECT_DIR}}/.codearbiter/security-controls.md` — only when a task touches a security boundary (auth, crypto, secrets, a trust boundary).

**Optional `scope` parameter:** when invoked by `executing-plans`, a list of task IDs is passed. The loop processes only those tasks (in their internal dependency order). When `scope` is absent (the `/sprint` path), the loop processes the full plan from first unblocked task to last.

Phase 1 — Task selection · gate: BLOCK

Pull the next unblocked task from the plan in dependency order. When a `scope` was passed, restrict selection to tasks in that list. A task is one verifiable unit of work with a path set, a spec obligation, and a verification command.

• Confirm every dependency task is `ACCEPTED` before selecting.
• Confirm no unresolved `[CONFIRM-NN]` blocks the task. One that does halts the loop — see Hard rules.

Gate: exactly one task selected, dependency-clean, with its spec obligation and verification command in hand.

Phase 2 — Implementation dispatch · gate: BLOCK

**Farm path (when `<slug>.plan.json` exists alongside the `.md` plan):** skip the subagent dispatch loop below and follow `{{PLUGIN_ROOT}}/skills/subagent-driven-development/references/farm-dispatch.md`. The farm path replaces only the *authoring* step for the plan's tasks (cheap Zen workers under hard gates instead of premium subagents); it does **not** replace review — every task the farm reports green is still routed through Phases 3–5 before acceptance. The cost arbitrage is in who *writes* the code, never in whether it is *reviewed*. In brief: select a model (canary-probe with a cache→websearch fallback ladder), {{IF:pi}}invoke the trusted `codearbiter_farm_preview` tool with the project-relative plan path{{ELSE}}dispatch `{{PLUGIN_ROOT}}/tools/farm.js`{{END}}, honor a circuit-breaker abort as a hard-gate STOP, then for each result either accept-after-Phases-3–5 (green) or re-dispatch via premium Phase 2 (escalate). Results stream to `.farm/farm-results.jsonl` and are consumed in completion order — Phase 3 + Phase 5 per green task as it lands, Phase 4 still the once-per-scope barrier (reconcile against `farm-report.json` on abort). The reference has the full step-by-step.

---

**Normal path (no `plan.json`):** dispatch ONE fresh subagent for the selected task — `backend-author`, `frontend-author`, or `infra-author` by the scope mapping in `tech-stack.md` (`{{PLUGIN_ROOT}}/agents/<name>.md`). A fresh context per task is the whole point: no carried-over assumptions, no accumulated drift.

The subagent works test-first by routing through the `tdd` skill (`{{PLUGIN_ROOT}}/skills/tdd/SKILL.md`) — no implementation code before `tdd` Phase 1. Brief it with the task's path set, its spec obligation, and its verification command. Nothing else from prior tasks leaks in.

Gate: the subagent reports `tdd` complete — all six phases green. A `tdd` BLOCK halts the loop; do not re-dispatch around it.

Phase 3 — Spec-compliance review · gate: BLOCK

Did the change satisfy the task's obligation? Measure the result against the spec line the task traces to — not against whether tests merely pass.

• Every acceptance claim in the task's obligation is met by the change.
• Scope is clean: nothing implemented beyond the task; nothing required by it omitted.
• Out-of-scope work the subagent noticed is recorded with an inline `[NEEDS-TRIAGE]` marker — never

acted on inside this task.

Gate: the obligation is fully satisfied and scope is clean. A shortfall returns the task to Phase 2 with a corrective brief.

Phase 4 — Quality review (once per scope) · gate: BLOCK

Runs ONCE per scope — after every task in the current scope has cleared Phase 3 and Phase 5 — over the **combined diff** of the scope, not per 2–5-minute task. Per-task review at that granularity costs more context than the work and catches nothing the batch diff doesn't; the batch boundary is where review pays. (A scope of one task reviews that task's diff — same rule, degenerate case.)

Dispatch the reviewers applicable to what the combined diff touches, then `finding-triage` (`{{PLUGIN_ROOT}}/agents/finding-triage.md`) to classify every finding by severity. Select reviewers by the diff, not blanket — dispatching an irrelevant reviewer wastes a context:

• `security-reviewer` (`{{PLUGIN_ROOT}}/agents/security-reviewer.md`) — any security-relevant path (authn/authz, deploy, CI, trust boundary).
• `auth-crypto-reviewer` (`{{PLUGIN_ROOT}}/agents/auth-crypto-reviewer.md`) — auth, crypto, key, or secret changes.
• `dependency-reviewer` (`{{PLUGIN_ROO