Matt PocockandClaude Opus 4.8
386d4ff719
Executes the `unify-to-tickets` decision (personal-wiki #23), reworking this PR from "add /to-plan" into the full planning-skills unification. - Rename /to-prd → /to-spec. "spec" is now the single through-line term (the skill still opens with "you may know this document as a PRD" for discoverability). - Merge /to-plan + /to-issues into one /to-tickets skill; delete /to-issues. /to-tickets emits a set of tickets, each declaring its blocking edges — one medium-agnostic artifact that reads as a sequential plan (local `tickets.md`, edges as text) or a parallelizable DAG (real tracker, native blocking links). The edges live in the ticket either way; the medium only decides whether anything acts on them in parallel. - ask-matt now routes idea → /to-spec → /to-tickets → /implement. - Sweep every cross-reference (docs pages, chain diagrams, CONTEXT.md, ADRs, .agents, setup templates) to the new names and vocabulary. - Rewrite the changeset to describe the unification. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
2.6 KiB
Quickstart:
npx skills add mattpocock/skills --skill=implement
npx skills update implement
What it does
implement builds the work described in a spec or a set of tickets — 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 spec or split into tickets and you're ready to turn that into code. If the spec doesn't exist yet, write it first — for that, use to-spec, or to-tickets to break a spec 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-spec) 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 near the end of the main chain, just before the review:
grill-with-docs → to-spec → to-tickets → implement → code-review
Reach for it after the work has been specced and sequenced, not before. Its key neighbours are to-tickets, which produces the tickets — each declaring its blocking edges — that 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.