implement

name	implement
description	Build one unit of a ticket: code, the tests its behaviours actually earn, and an inline review of the diff.

Implement

The coding phase. One or more units. Each unit is: implement → review inline → fix.

When called from /ship

You receive a brief: goal, files, constraints, done criteria, and the ticket's behaviours touched. Work within it. Do not widen the scope because you noticed something adjacent — report it instead.

When called directly

The argument is what to build. With no argument, list open work: gh issue list --label type:ticket --state open. Without a ticket there is no behaviours list, so the test budget falls back to public boundaries in prd/architecture.md only.

Process

1. Scope

Decide the goal, the files to read, the tests to run, the constraints. Read only the files at the seams the spec names.

Read prd/glossary.md if it exists. It names things, and you are writing the identifiers — a module the glossary calls a Builder should not enter the code as SystemFactory.

Independent units run in parallel. A dependent unit waits for what it depends on.

2. Implement

Code first. The test comes after the code works, not before.

The test budget is the ticket's ## Behaviours touched list. Nothing else earns a test.

• A behaviour listed there → one test, at the highest seam the spec names, named after the behaviour.
• A public boundary in prd/architecture.md — CLI command, exported API, route, persisted schema — where no behaviour is listed but a stranger can invoke it → a test is allowed.
• Everything else → no test. A ticket claiming no behaviours ships with no new test file. That is the design, not a gap to fill.

Never write a test that asserts the toolchain works: no install, build, compile, lint, file-exists, or config-parses assertions. They pass forever, fail only when something unrelated breaks, and cost a file each. Never write a test that mirrors implementation — test through public interfaces, mock at system boundaries only.

If you believe something needs a test and no behaviour covers it, propose a behaviours.md entry in your report. Do not write the test, and do not edit behaviours.md.

3. Review inline

Read the diff — git diff or git diff --cached — and apply the review rules already in your context:

• Standards: conventions, naming, structure, types, error handling, security. Cite the repo rule, not a general preference.
• Spec: does the diff do what the ticket says, and no more. Missing criteria, wrong behaviour, scope creep.

Fix what is legitimate. This is the review — there is no separate dispatch afterwards.

4. Report

Return what you built, any deliberate limitation, proposed PRD deltas, and adjacent findings you left alone. File nothing.

Completion

Done when: every unit's done criteria is met, the diff contains only intended changes, typecheck passes, and the tests that exist pass. Checkable: run the test command and report the exit code.