Use implement-spec when a decided specification has been split into multiple tickets with real dependencies. You invoke it explicitly; one agent then coordinates implementer subagents, each working in its own Git worktree, and collects the result on one integration branch. For a small change that fits one session, implement is easier to supervise.
Our to-spec guide covers the earlier step: recording decisions already made. to-tickets then creates independently demonstrable tickets and their blocking relationships. implement-spec starts from those artifacts. It does not interview you about requirements or turn an unstructured idea into tickets.
Install and prepare
Run the installer from the project terminal. In its interactive selection, include implement-spec, setup-matt-pocock-skills, to-tickets, tdd and code-review; add to-spec if you still need to write the spec. Choose the agent you actually use, such as Claude Code or Codex. Run the installer:
npx skills@latest add mattpocock/skills
If you already use the complete Claude Code plugin, use its copy instead of installing duplicate files. Run setup-matt-pocock-skills once in the project and choose the real tracker: GitHub, GitLab, local Markdown, or a custom workflow. It records where tickets live and how they close. Without this setup, implement-spec stops rather than assuming GitHub.
Before starting, verify three things. The spec records the agreed scope and test boundaries. to-tickets has published tickets that each demonstrate one behavior and state what blocks them. Your agent environment can run subagents in parallel with separate Git worktrees. Tickets without blocking edges all become ready together; settle shared-file or naming dependencies before launching.
Your first run
For example, imagine an account activity log spec with tickets to record events, query them and show a list. Replace the sample issue number with your real spec issue or local file path. In a fresh Claude Code session, enter:
/implement-spec #42
Implement the agreed spec and its linked tickets. Read the blocking relationships and testing decisions first, then create an integration branch. Work on independent ready tickets in separate worktrees. After every merge, recalculate which tickets are ready. Finally review the whole implementation and report the branch, ticket states and verification results.
For a local tracker, replace #42 with the actual spec path. In Codex, invoke the installed implement-spec skill according to that client, for example: “Use the implement-spec skill for this spec: .” Do not treat the example number as a fixed command. This skill creates branches, changes code and updates tickets, so check the repository state and preserve unrelated work first.
Follow the run
The orchestrator should create an integration branch and dispatch only tickets whose blockers have landed. Each implementer changes code and runs tdd in its own worktree, merges the current integration tip into its branch, and returns its result for merging onto the integration branch. That merge may free the next tickets. If everything starts immediately, inspect the blocking edges. If two parallel tickets touch the same registry, type or message file, agree on names up front or add a dependency so they do not collide.
Run the whole-spec code-review only after every ticket has landed. Check that the integration branch contains each ticket's work, that relevant tests actually ran, and that review findings were fixed. A tracker that closes through PRs may need a PR. With local Markdown tickets, the current engineering version can finish at the integration branch; an older user's request for offline support does not describe the current behavior. A green subagent report alone is insufficient: gitignored fixtures and local databases do not follow the worktree, so their tests may silently skip and need verification in the main checkout.
When it gets stuck
- Tickets are missing: Run setup-matt-pocock-skills and confirm the tracker and ticket locations. If you only have a spec, run to-tickets first.
- A ticket stays blocked: Compare blockers with work already merged into the integration branch, not only the tracker's status; GitHub may keep a blocker open until the final PR merges.
- Parallel work conflicts: Worktrees postpone shared-file conflicts. Add a blocking edge or specify shared field and component names before dispatch.
- Review repeats for hours: Review the entire spec after all tickets land. After fixing findings, ask for focused checks of those fixes instead of another broad review loop.