# Implement

> Use when executing an implementation plan — dispatches subagent per task with self-review, verification along the way, and commits

- Skill: `dodi-hq/implement` (Agent Skill, multi-file: 2 files)
- Install (CLI): `npx skillmds@latest add dodi-hq/implement`
- Raw SKILL.md: https://api.skillmd.com/api/skills/dodi-hq/implement/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Productivity
- Author: dodi-hq (https://skillmd.com/u/dodi-hq)
- Updated: 2026-09-10
- Page: https://skillmd.com/skills/dodi-hq/implement

---


# 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 judgment surprise on an unlabeled ticket demotes to the spec lane instead of escalating the model.

## 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