implement-feature

# Skill: Implement a Planned Feature

This is the step after `plan-feature`. Research is done and a plan exists. Your job is to
turn that plan into a change that builds, runs end to end, and stays green, then to write it
up and put it on a branch.

You are the orchestrator. You do not write the whole feature yourself in one pass. You drive
the feature through phases and spin a narrow subagent for each phase, handing it full
context. You stay in the loop between phases, read each result, update the plan, and decide
the next move. This mirrors the subagent discipline in the `agent-workflows-qa` skill: every
fixer is followed by a reviewer, and every fix is followed by a retest.

## Precondition: a plan workspace exists

The feature must already have a planning workspace from `plan-feature`:

- `docs/design/<project>/` with at least `README.md`, `context.md`, `plan.md`,
  `status.md`, and `research.md`.

If there is no such workspace, stop. Run `plan-feature` first. Do not improvise a plan inside
this skill. `status.md` is the source of truth for progress and stays current through every
phase below.

## The chain at a glance

```
plan-feature  ->  [ implement-feature ]  ->  write-pr-description (when you open the PR)
                        |
   Phase 0  refresh the plan (status.md is truth)
   Phase 1  implement        (implementer subagent: smallest correct change)
   Phase 2  review           (reviewer subagent: root cause, no regression)
   Phase 3  debug end to end (debug subagent, loop)   -> debug-local-deployment skill
   Phase 4  tests            (test subagent, loop)     -> agent-workflows-qa + agent-replay-test
   Phase 5  document + PR draft (docs subagent)        -> write-docs + write-pr-description (Context + Scope/risk + How to QA)
   Phase 6  stacked branch   (GitButler)               -> but (publish Phase 5 PR body on push)
```

## Keep the orchestration console current (when the effort has one)

If this work is tracked in an `orchestration-console` project (see the `orchestration-console`
skill), mirror progress to the console as you go, so the user reads status and answers decisions
from the dashboard instead of chat. The console never replaces the PR review flow; it links to
it. The hooks map onto the phases above:

- **Start of every turn:** `console pending --project <p>` and act on the user's answers and
  notes first, then `console decision lock` each one you acted on.
- **Phase 0:** `console task add` one task per slice; `console message` what this run attempts.
- **Phase 1:** `console task set <slice> --status running --owner <impl-agent>`.
- **Phase 2:** on changes requested, a `console message --ref task:<slice>`.
- **Phase 3-4:** when a debug/test loop stalls and you would escalate to the user, raise a
  `console decision add` (the stuck state + options + your rec) instead of burying it in chat.
  This is the highest-value hook: it is exactly the "route / debug" decision that gets lost today.
- **Phase 5:** `console task set <slice> --status in-review --pr <url>`.
- **Phase 6:** on push, `console message` with the PR link.

## Phase 0: Refresh the plan

Before any code changes, re-read the workspace and reconcile it with the code as it stands
now. Plans rot. The repo may have moved since the plan was written.

1. Read `context.md`, `plan.md`, `research.md`, and `status.md`.
2. Verify the plan's file and symbol citations still exist. Where the code drifted, correct
   the plan, do not code against a stale map.
3. Cut the plan into the smallest shippable slices, each one independently reviewable and
   testable. Record the slice list and the acceptance check for each in `plan.md`.
4. Update `status.md`: what is done, what this run will attempt, known blockers.

End Phase 0 with a concrete slice to build and a written acceptance check for it.

## Phase 1: Implement

Spin an implementer subagent per slice. Keep it narrow and give it everything it needs to
work cold:

- the slice goal and its acceptance check from `plan.md`,
- the exact files and symbols to touch (from the refreshed plan),
- the repo conventions that apply (the relevant `AGENTS.md`, the area skills),
- the rule: make the smallest correct change, match the surrounding code, do not refactor
  next door, do not commit.

When the slice defines or changes an interface or contract — API params, wire fields, config
schema, tool definition, event payload — apply the `design-interfaces` skill first: classify
each field by its semantic role (data, config, policy, credentials, routing, metadata,
protocol context), not the feature it touches, and fix the shape before it ships. The
reviewer in Phase 2 checks the same lens on any contract the slice moved.

When the slice spans the API or SDK, the subagent runs `ruff format` then `ruff check --fix`
before reporting done. For frontend slices it runs `pnpm lint-fix` in `web/`. The subagent
returns a short diff summary and a self-check against the acceptance criterion. You read it.
You do not trust "done" without the check.

## Phase 2: Review

Every implementation is followed by a review. Spin a reviewer subagent and hand it the diff
plus the slice goal. Its job is to confirm the change actually solves the slice, find
regressions, and catch the class of mistake a fixer working alone misses (a Dockerfile `CMD`
overridden by a compose `command:`, a default that looks right but is read from the wrong
layer, an edit that the dev stack will not hot-reload).

The reviewer reports: root cause addressed yes or no, regressions, and required changes. If it
asks for changes, loop back to Phase 1 with its notes. Do not advance with an open review.

Note on `/code-review` (ultrareview): the heavy cloud review is user-triggered and billed, and
you cannot launch it from here. When the change is large or risky, finish the subagent review,
then tell the user they can run `/code-review ultra` on the branch for a deeper pass.

## Phase 3: Debug end to end (loop until it works)

A slice