/coder-eval-implement-plan

description: Implement an approved coder_eval plan phase by phase with risk-scaled per-phase review, then a final code review
argument-hint: <plan-file-path>

Context

• Current git status: !`git status --short`
• Current branch: !`git branch --show-current`
• Recent commits: !`git log --oneline -5`

Implement Plan

Implement an approved plan produced by `/coder-eval-create-plan` phase by phase, verifying and reviewing each phase before moving on, then run one cross-cutting review of the whole change. The plan is your contract: it carries, per phase, a **Risk** tag, **Changes**, **Edge Cases**, **Tests to Write**, **Tests to Run** (scoped commands), and **Acceptance Criteria**, plus a global **Master Acceptance Checklist**, **Patterns to Mirror** (real code snippets), and a **Confidence Score**. Drive off those — do not re-derive what the plan and `CLAUDE.md` already specify. The plan path is: $ARGUMENTS

If no plan path was provided, ask for one.

When to use this

This command is for **multi-phase plans** where phases build on each other and the cost of a wrong turn is high. For a single trivial change (one file, a rename, a typo, a one-line fix), skip the ceremony below — make the change, run the relevant scoped test, and stop. Do not spawn review sub-agents for work a human would eyeball in ten seconds. (If the plan's Confidence Score is below 7, stop — per `/coder-eval-create-plan` it isn't ready; surface that instead of implementing.)

The loop

Everything below expands this core loop. Hold it in your head:

pre-flight (understand plan + Patterns to Mirror, learn conventions, capture <start-sha>, build task list + findings file)
for each phase, in order:
    implement   → write the phase's "Tests to Write" first for new behaviour, then the code
    verify      → Stage 1: the phase's "Tests to Run" + scoped lint must pass
    review      → Stage 2: spec-compliance, then (risk-scaled) quality
    commit      → conventional message with a progress counter
final review of the whole change → fix → tick Master Acceptance Checklist → summary

Complete one phase fully before starting the next. Stay within the plan's scope — do not refactor or extend beyond what it specifies.

---

Pre-flight

Do all of this once, before writing any code:

• **Check readiness.** Read the plan's Confidence Score; if it's below 7 (or the plan carries a "not ready" warning callout), stop and surface it — don't implement.
• **Determine the resume point.** A phase counts as done if **any** of these hold — do not rely on checkboxes alone (plans are often completion-tracked by commit, leaving boxes unticked): its Acceptance Criteria are checked `- [x]`; a commit with a matching `N/M` progress counter exists (`git log --oneline | grep -E '\b<N>/<M>\b'`); or the findings file already has a `## Phase N` block. The first phase satisfying none is where you start.
• **Capture the baseline** (`<start-sha>`, the final-review reference point) — it must sit **before the first phase's work**, not at current HEAD. Fresh run (start = Phase 1): `git rev-parse HEAD`. Resuming (start = Phase K > 1): the commit before the `1/M` commit — `git rev-parse "$(git log --oneline | grep -E '\b1/<M>\b' | tail -1 | cut -d' ' -f1)^"`; if no `1/M` commit exists, ask the user for the pre-work SHA rather than guessing. Store it in a task note. This keeps the completion suite and final review covering **all** phases, not just the resumed ones.
• **Read everything, fully.** The plan (including its **Patterns to Mirror**), the originating ticket/issue, and every file in **Affected Files & Modules** — read those files completely (no limit/offset). The Patterns to Mirror snippets are how this codebase does it; mirror them, don't invent.
• **Learn the conventions.** Read `CLAUDE.md` and `.claude/shared/review-rubric.md` and **follow them exactly** — CLAUDE.md is the source of truth for where models/criteria/agents live, the registry patterns, the 5-layer config merge, the agent lifecycle, sandbox isolation, token accounting, and the custom-lint harness; the shared rubric is the source of truth for Risk triggers, the Severity rubric, the Fix Policy, the Harness loop, and the 18-item Review Criteria. When the plan and these conventions conflict, stop and use the **Mismatch Format**.
• **Read the plan skeptically.** Look for contradictions, gaps, steps that conflict with the current code, or stale assumptions (the codebase may have moved since the plan was written). Resolve minor gaps yourself (prefer the plan's intent over its letter) and note the decision for your summary. For a real conflict — a step that is impossible or would break existing behaviour — stop and use the **Mismatch Format**. A bug caught now is far cheaper than one caught mid-implementation. If anything needs human judgment (not a codebase lookup), batch all such questions into one message and ask before starting.
• **Set up working state.** Build a `TaskCreate` checklist mirroring the plan's phases, noting prerequisites. Set up the **findings file** alongside the plan — `<plan-dir>/<plan-basename>-findings.md`; do not commit it. **Create it only if absent; if it already exists (a resumed run), read it in full and append — never overwrite prior phases' blocks.** Seed it with pre-flight discoveries ("Module X already does Y — don't reimplement"). See **Findings file** for what to append per phase.

Once questions (if any) are answered and the task list and findings file exist, begin Phase 1.

Project invariants (hot list)

The plan's Master Acceptance Checklist and the **Review Criteria** below are the full set; `CLAUDE.md` has the complete rules. As the last pre-flight act, keep this short hot list of **cheap-to-violate, expensive-to-catch-late** coder_eval invariants live while coding — these pass typecheck and silently break at runtime or in CI:

• **All models import from `coder_eval.models`** — never from submodules (lint-guarded). New models are