Source: mattpocock/skills · Maintainer: community: Matt Pocock · License: MIT · Checked: 24 October 2026
What is the implement skill?
The implement skill builds work that has already been decided: one ticket, a small spec, or the plan you just agreed in the conversation. It writes the code test-first, typechecks as it goes, reviews the result and commits to your current branch, without reopening the plan.
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 a piece of work based on a spec or set of tickets."
It is the build step of the repo's main chain, after planning and before review. As of 24 October 2026, its skills.sh page listed about 774,000 installs (snapshot, 24 October 2026).
What does it do?
The SKILL.md is short. It tells the agent to:
- Implement the work described in the spec or tickets.
- If you pass a ticket reference, fetch it from the issue tracker and state its title before starting, and ask if the reference is ambiguous.
- Call the
tddskill "where possible, at pre-agreed seams." - Run typechecking and single test files regularly, and the full test suite once at the end.
- Call the
code-reviewskill to review the work. - Commit to the current branch.
The repo's docs for implement stress one rule: "It never reopens the plan." There is no interview and no counter-proposal. Whatever was settled upstream is the input, and the job is to turn it into a commit.
The central idea is the seam, the public boundary where behavior is observed. Tests live at seams, and if the seam was agreed before any code existed, the tests survive a rewrite underneath. The docs admit this is also the weak point: nothing inside implement agrees the seams. The tdd skill asks, so the agreement happens in the spec or in the first exchange of the run. If it happens nowhere, the run becomes "just write the code" and nothing warns you.
It is user-invoked. The frontmatter sets disable-model-invocation: true, which per the Claude Code skills docs means "Claude can't invoke the skill on its own." The folder holds only SKILL.md and agents/openai.yaml (Codex display name "Implement", implicit invocation off).
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 listed in Anthropic's official plugin marketplace:
claude plugin install mattpocock-skills@claude-plugins-official
Plugin skills are namespaced, so it appears as /mattpocock-skills:implement. This route is the simplest because implement calls other skills.
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
The SKILL.md calls tdd and code-review, and the tdd docs require codebase-design. The skills CLI accepts --skill more than once, so a working set is:
npx skills add https://github.com/mattpocock/skills --skill implement --skill tdd --skill codebase-design --skill code-review --skill setup-matt-pocock-skills
Add -g to install for all projects. Codex and Cursor read the same SKILL.md format; see Codex skills and Cursor skills. If your tickets live on a tracker, run /setup-matt-pocock-skills once per repo so the agent knows where to fetch them; see the setup skill page.
How do you use it?
Check that you are on the branch you want the work on first. The docs say implement "does not create one, and it does not ask."
The docs map where the work lives to the right move:
| The work is | Reach for |
|---|---|
| A ticket on the tracker | /implement #42, one ticket per session, clearing context between tickets |
| A spec, and the build spans sessions | to-tickets first, then /implement per ticket |
| A spec, and the build is small | /implement against the spec |
| Only in the conversation, and small | /implement in the same window |
| Not decided yet | grill-with-docs first |
| A whole spec, built in parallel | implement-spec |
Example prompts (suggestions, not quotes from the repo):
/implement #42/implement owner/repo#118. The plan is in the ticket; the seams are the public API of the billing module./implement the plan we just agreed in this conversation. There is no spec file./implement docs/specs/export-csv.md. Commit to a new branch called export-csv and open a draft PR.
The third prompt matters: the docs note that the skill's wording pushes the model to look for a spec file, so say so when the plan only lives in the thread. Passing a full issue URL or owner/repo#2 removes any doubt about which ticket a bare number means.
The docs list what a healthy run looks like: it restates the ticket instead of asking what to build, you see a real tdd Skill call in the trace, typechecks run repeatedly, and the diff is one ticket's worth of change.
How does it compare with implement-spec?
The same repo ships implement-spec for building a whole spec in one run.
implement |
implement-spec |
|
|---|---|---|
| Scope per run | One ticket, or a small spec or plan | Every ticket of a spec |
| Parallelism | None, you drive each ticket | Subagents across the ready frontier, each in its own worktree |
| Where code lands | A commit on your current branch | One integration branch |
| Seams | Agreed live through tdd |
Must be named in the spec or tickets |
| Review | code-review inside each run |
One code-review over the integration branch |
Pick implement when you want to stay close to each ticket. Pick implement-spec when you'd rather orchestrate the build.
Tips and limits
From the repo's docs, not from testing:
- It never closes the ticket. It ends at the commit, does not tick the
- [ ]boxes and does not act on review findings. Close tickets yourself, especially on a dependency chain. - Review may see an empty diff.
code-reviewreviewsgit diff <fixed-point>...HEAD, which excludes uncommitted changes, andimplementruns it before committing. The docs call this reported and unfixed; commit first, then review against your branch point. Some people prefer review in a fresh session anyway, to avoid an agent judging its own code. - Don't run parallel sessions in one checkout. The docs cite a report of an amend landing on another session's commit and a stash vanishing. Worktrees help, but
refs/stashis shared across worktrees. - Big tickets cost big tokens. A non-trivial ticket over 100k tokens is normal, per the docs. If one keeps going over, split the ticket.
- It trusts its input. It does not re-check what it was handed, so a badly shaped ticket gets built as written.
As of 24 October 2026, skills.sh showed Pass from Gen Agent Trust Hub, Socket and Snyk. The skill runs no scripts of its own, but it commits to your repo. It is MIT licensed, so you can copy and change it as long as you keep the copyright notice.
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, since implement calls them. That also gives you a place for your own edited copy, for example one that opens a pull request instead of committing. Your skills 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
- Implement spec skill: builds every ticket of a spec in parallel worktrees.
- TDD skill: the red-green loop
implementdrives at each seam. - Code review skill: the two-axis review that closes each run.
- To-spec skill: writes the spec that feeds the ticket flow.
- Ask Matt skill: tells you whether
implementis the right next step.