Implement

Execute a plan by dispatching a fresh subagent per task. Each subagent implements, tests, self-reviews, and commits. No heavy review gates per task — the full review happens after all tasks complete (see dodi-dev:review).

Process

1. Read the plan, extract all tasks with full text
2. For each task sequentially: a. Dispatch implementer subagent with full task text + context (see implementer-prompt.md) b. Handle subagent status (see below) c. Mark task complete
3. After all tasks: invoke dodi-dev:review

Never dispatch multiple implementers in parallel — they'll conflict.

Model Selection

Default is model: sonnet (pinned in implementer-prompt.md). Adjust per task:

• Mechanical tasks (1-2 files, clear spec): model: haiku
• Integration tasks (multi-file, pattern matching): model: sonnet
• Architecture/judgment tasks: model: opus

Ticket-level override — needs-capable-delivery: if the ticket carries the label (applied at plan review — see mature-ticket), pin every implementer and fix worker at model: opus, with no per-task demotion. The label means the plan reviewer judged the work invariant-dense; on that class of work the bugs live in tasks that look structural, so the per-task adjustments above do not apply.

In the epic lane, escalation is pre-routed by the label, never improvised mid-lane: a surprise requiring a change to product behavior, architecture, shared contracts, scope, or the approved plan contract demotes to the spec lane instead of escalating the model. Routine coding judgment within that contract belongs to the implementer at the assigned tier.

Plan Adherence

Implement the approved task outcomes in dependency order, preserving scope, interfaces, compatibility, correctness invariants, and acceptance criteria. Implementers own function bodies, local helpers, internal naming, and other local engineering choices within those boundaries. Plans define work and verification; they do not supply implementation code or pseudocode. Missing code is not missing planning context. Correct implementation bugs in-lane; return to specification when the approved contract itself requires a new or changed decision.

Handling Implementer Status

Status	Action
DONE	Mark complete, next task
DONE_WITH_CONCERNS	Read concerns. If correctness issue, address first. If observation, note and proceed
NEEDS_CONTEXT	Provide missing context, dispatch a fresh implementer
BLOCKED	Assess: provide more context, use more capable model, break task smaller, or escalate to human — any retry is a fresh implementer, never a re-entry

Never ignore an escalation or retry without changes.

Verification Along the Way

After each subagent completes, verify its claims before moving on:

• Check git diff or git log to confirm changes were actually made
• If the task included tests, confirm they actually ran and passed
• Don't trust "tests pass" without evidence