14c13c5bf9
Rename the in-progress `review` skill to `code-review` and move it from `skills/in-progress/` into the promoted `skills/engineering/` bucket. - Add it to `.claude-plugin/plugin.json` and the Model-invoked sections of the top-level and Engineering READMEs; drop it from the in-progress README. - Add a docs page at `docs/engineering/code-review.md`. - Point `/implement` and its docs at `/code-review`. - Update the smell-baseline changeset reference; add a changeset for the move. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
2.5 KiB
Quickstart:
npx skills add mattpocock/skills --skill=implement
npx skills update implement
What it does
implement builds the work described in a PRD or a set of issues — driving it through test-driven development, typechecking, and the full test suite, then handing off to review and committing to the current branch.
It does not decide what to build. The spec is already settled and the seams are already agreed; implement executes that plan rather than reopening it. It is the hands, not the head — the thinking happened upstream.
When to reach for it
You invoke this by typing /implement — the agent won't reach for it on its own.
Reach for it once the work is written down as a PRD or split into issues and you're ready to turn that into code. If the spec doesn't exist yet, write it first — for that, use to-prd, or to-issues to break a PRD into tickets. If you just want to build something test-first without a full spec, drop to tdd directly.
Pre-agreed seams
The idea implement runs on is the seam — the stable interface a feature is tested at, chosen before any code is written. It doesn't invent seams mid-build; it uses the ones already picked (during to-prd) and writes tests against them via tdd. Working at pre-agreed seams is what keeps the implementation honest: the tests target something durable, so the code underneath can move without the tests moving.
Around that core it keeps the loop tight — typecheck often, run single test files as it goes, run the whole suite once at the end — then closes out with a review pass and a commit to the current branch.
Where it fits
implement is the build step at the end of the main chain:
grill-with-docs → to-prd → to-issues → implement
Reach for it after the work has been specced and sequenced, not before. Its key neighbours are to-issues, which produces the independently-grabbable tickets it works through, and tdd, which it drives internally to write the tests at each seam before running its own /code-review pass and committing. When you're unsure which skill or flow fits, ask-matt routes you.