skills/docs/engineering/implement.md
Matt Pocock ade35dc0d8 docs: drop the formulaic "load-bearing constraint:" label
The repeated "The load-bearing constraint:" opener on every page read
as an agent tell. Strip the label across all skill pages and let the
constraint stand as a plain declarative sentence; update the
writing-docs template so it isn't regenerated.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-01 11:27:36 +01:00

2.5 KiB

Quickstart:

npx skills add mattpocock/skills --skill=implement
npx skills update implement

Source

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 /review pass and committing. When you're unsure which skill or flow fits, ask-matt routes you.