# Implement

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

- Skill: `y3owk1n/implement` (Agent Skill)
- Install (CLI): `npx skillmds@latest add y3owk1n/implement`
- Raw SKILL.md: https://api.skillmd.com/api/skills/y3owk1n/implement/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: y3owk1n (https://skillmd.com/u/y3owk1n)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/y3owk1n/implement

---


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