implement

implement — turn the task list into tested code

You have a spec, a plan, and an ordered task list (from specify → plan → tasks), and the analyze gate has cleared. This skill does the building: it walks the tasks in order, writes each one test-first, stops to show its work after every task, and records the decisions it makes along the way. It is the intent → shipped code engine's hands — verify is the gate that comes after, not part of this skill.

This is a process skill. It owns the discipline (red → green → refactor, checkpoints, decision logging, constitution adherence). It does not own the test tooling — pytest fixtures, go test table-drivers, Vitest/Playwright, flutter test — those belong to the stack skill, and you call into them rather than reinventing them.

Before you write a line of code

Run this short gate. Skipping it is the most common way an implement session goes sideways. This gate is a hard refuse, not a checklist to feel good about: if it fails you stop and route back — you do not write feature code anyway.

1. The spec + plan must exist AND be approved. Open the spec (02-DOCS/wiki/sdd/specs/<slug>.md), the plan (02-DOCS/wiki/sdd/plans/<slug>.md, which holds the task list), and the constitution (02-DOCS/wiki/sdd/constitution.md). If any is missing, you are not allowed to implement — route back: no spec → specify; no plan → plan; no task list inside the plan → tasks; unresolved analyze findings → resolve them first. If a spec/plan exists but the user has not actually seen and approved it, get that approval first. Never "start coding to discover the plan as you go", and never accept "just build it, skip the spec" on a non-trivial feature — name the gate in one friendly line and route to specify. (Only a true one-line, low-risk change earns a skip, and you say so.)
2. Read the SDD runtime config. Open 02-DOCS/wiki/sdd/config.yaml. If it is missing on non-trivial work, stop and route to sdd-init. Use testing.strict_tdd, testing.commands.apply, testing.commands.verify, sdd.review_budget and sdd.registry_path. Do not choose a different test command from memory while config exists.
3. Read the skill registry. Open .rsc/skill-registry.json if present. Select only the relevant stack/process skills for this task, then digest them into compact rules. If the registry is missing, run or recommend npx @ericrisco/rsc registry refresh and record the fallback.
4. Read the accompaniment dial. Open 02-DOCS/wiki/harness/user-profile.md and read the technical + accompaniment level. It sets how loud you are at each checkpoint (see the dial table below). No profile yet → assume non-technical, narrate more, and ask before any irreversible step.
5. Confirm isolation. Implementation happens on a feature branch or worktree, never directly on the default branch. If you are on main/master, stop and hand to worktrees before the first commit.
6. Scan the tasks for independence. Mark which tasks share files/state and which are disjoint. Disjoint clusters are candidates for parallel; everything else runs in order.