Implement spec skill: what it does and how to install it

Source: mattpocock/skills · Maintainer: community: Matt Pocock · License: MIT · Checked: 24 October 2026

What is the implement spec skill?

The implement spec skill takes a spec that has already been split into tickets and builds all of it in one run: each ticket goes to its own subagent in a separate git worktree, and the finished work is merged onto a single integration branch. It is for developers who plan with specs and tickets and don't want to open one agent session per ticket.

It comes from mattpocock/skills, which Matt Pocock describes in the README as "My agent skills that I use every day to do real engineering - not vibe coding." The skill's description reads: "Implement the result of /to-spec and /to-tickets in code."

The repo's changelog for version 1.3.0 records it graduating into the Engineering set, which means it now ships in the Claude Code plugin. As of 24 October 2026, its skills.sh page listed about 282,400 installs (snapshot, 24 October 2026).

What does it do?

The key idea in the SKILL.md: "The tickets are not a list of steps. They are a task graph with blocking relationships between them." At any moment there is a frontier of tickets whose blockers have all landed, and every ticket on the frontier runs at once.

The steps, in order:

1. Read the spec and tickets to build the task graph.
2. Optionally run an exploration subagent that saves Markdown notes in a folder outside the repo, so implementers can skip exploring.
3. Create the integration branch.
4. Start an implementer subagent per ready ticket, each in its own worktree on its own branch. Each one confirms its worktree is based on the integration branch, builds the ticket with the tdd skill, and merges the integration branch tip into its own branch before reporting done.
5. Merge each finished ticket onto the integration branch with a merger subagent.
6. Start new implementers whenever a merge opens up more of the frontier.
7. When every ticket is done, run the code-review skill on the integration branch and fix all findings in one implementer subagent.
8. Mark the draft PR ready if one exists, or resolve each ticket the way your tracker closes work.
9. Clean up the worktrees.

Subagents talk through context pointers (the spec, the ticket, shared notes, earlier commits) rather than pasted summaries, which keeps their prompts small. The folder holds only SKILL.md and agents/openai.yaml (Codex metadata, "Implement Spec").

It is user-invoked. The frontmatter sets disable-model-invocation: true, so you start it by typing /implement-spec.

How do you install it?

The README gives a plugin route and an editable-files route, and says to pick one per agent so you don't get every skill twice.

Claude Code plugin (whole set, updates itself). The collection is in Anthropic's official plugin marketplace:

claude plugin install mattpocock-skills@claude-plugins-official

It then appears as /mattpocock-skills:implement-spec. The plugin route is the simplest here because the skill depends on several others.

Codex plugin. From the README:

codex plugin marketplace add mattpocock/skills
codex plugin add mattpocock-skills@mattpocock

Editable files with the skills CLI. The command on skills.sh:

npx skills add https://github.com/mattpocock/skills --skill implement-spec

The SKILL.md calls the tdd and code-review skills and tells you to run /setup-matt-pocock-skills if no tracker is set. The tdd docs also require codebase-design. The skills CLI takes --skill more than once, so a working set is:

npx skills add https://github.com/mattpocock/skills --skill implement-spec --skill tdd --skill codebase-design --skill code-review --skill setup-matt-pocock-skills

Add -g for all projects. In Claude Code the folders land in .claude/skills/, or ~/.claude/skills/implement-spec/ and its siblings with -g, per the Claude Code skills docs. Codex and Cursor read the same SKILL.md format; see Codex skills and Cursor skills. You'll likely want to-spec and to-tickets too, since they produce its input.

How do you use it?

The docs say to clear the context, then type /implement-spec with a pointer to the spec: an issue number or a file path.

Example prompts (suggestions, not quotes from the repo):

• /implement-spec #142
• /implement-spec docs/specs/team-billing.md. Track merged tickets yourself to compute the frontier.
• /implement-spec #87. Tickets 3 and 4 both edit the message catalogue, so run them one after the other.
• /implement-spec #203. Open a draft PR after the first merge.

Requirements, from the docs:

• An issue tracker set with /setup-matt-pocock-skills. Without one, it stops and tells you to run setup.
• Tickets with blocking edges. Without edges, every ticket starts at once.
• Background subagents with worktrees. In Claude Code, subagents can run with isolation: worktree for an isolated copy of the repo. On an agent that runs subagents one at a time, the docs say it is "only a slower implement." See our Claude Code subagents guide.

The repo's chain with this skill is:

grill-with-docs → to-spec → to-tickets → implement-spec → retro

Tips and limits

From the repo's docs, not from testing:

• Review runs once, at the end. Code review compares the code to the whole spec, so run mid-run it flags every unbuilt ticket. One user reported a five-ticket feature where "the review and fix loop took roughly four hours". If a second broad review starts, tell it to check only the fixed findings and stop.
• Treat the output as a draft. The docs expect the final review to find real problems.
• Parallel tickets can collide. Worktrees push conflicts to merge time, and two implementers can pick different names for the same thing. Add a blocking edge between tickets that touch one shared file, or fix the names in the exploration notes.
• Blocked tickets may not start on GitHub. The blocked-by count only drops when a blocker closes, often at the end of the run. Ask the orchestrator to track merges itself.
• Worktrees hold only tracked files. Tests that need gitignored fixtures or credentials can silently skip; run those tickets in the main checkout.
• No interactive seam step. Unlike implement, you don't agree test seams live, so name them in the spec or tickets.

As of 24 October 2026, skills.sh showed Pass from Gen Agent Trust Hub and Socket, and Warn from Snyk (medium risk, audited 30 September 2026). Snyk's note is about indirect prompt injection: the workflow reads specs and tickets that may come from outside authors. If people outside your team can write tickets, read them before a run. The skill runs no scripts of its own but drives git, branches and merges through subagents. It is MIT licensed.

Save it in your Kipt library

In Kipt, open Skills and paste the skill's GitHub folder link into the import box. Import tdd, codebase-design and code-review the same way, one folder link each, since the skill depends on them. Your copies live in your own private GitHub repo and install into Claude Code or Codex with one command:

npx skills add https://github.com/<you>/<repo>.git --all -g

Kipt is not affiliated with Matt Pocock or mattpocock/skills.

Similar skills

• TDD skill: the red-green loop every implementer subagent runs on its ticket.
• Code review skill: the two-axis review that closes out the run.
• Grill with docs skill: the head of the same chain, where the plan gets settled.
• Superpowers skills: a different workflow collection that also has skills for running plans with subagents.