implement builds the work that a Spec or a Ticket describes. Give it a Ticket reference and it fetches the Ticket from the Issue tracker and states its title before it starts. If the reference is unclear, it asks.
It works in a fixed order:
Where it can, it builds test-first with tdd, at seams agreed up front.
It runs the type checker and single test files often, and the full test suite once at the end.
It commits to the current branch.It opens no pull request and closes nothing.
It works in a fixed order
When to use it
One Ticket at a time, from Tickets made by to-tickets. Clear the context window between Tickets. Each Ticket is self-contained, so the last one's context is no longer needed.
Straight after grilling, when the work is small enough for one session. Then build it right there, in the same context window, with no Spec or Tickets.
When not to use it
You want the whole Spec built in one run, with several agents working in parallel. That's implement-spec: reach for it when you'd rather orchestrate the build than drive each Ticket yourself.
The work isn't agent-ready yet. Raw bug reports and requests go through triage first.
What it needs to start
A Spec or a Ticket (ideally one whose blockers are all done), or, for small work, the settled conversation itself.
Seams agreed up front, so the test-first work knows where tests go.
The right branch checked out. implement commits to whatever branch it's on.
What it creates
Code and tests, as commits on the current branch, plus a code review of that work.
That's all. It opens no pull request and closes nothing. Closing is up to the way your Issue tracker closes work (see pull requests and merging). If it closes work through pull requests, you open one marked as closing the Ticket, and pr shapes its body.
Going deeper
6 min read · Going deeper not read
Why it exists
Matt's page on the Skill is marked "Updated Aug 24, 2026", but it already describes the change merged on 7 October 2026 (see below), so read it as current to at least that date. It puts the Skill's job in one line: implement "builds work that has already been decided." The plan is settled before it starts.
"It never reopens the plan." There's no interview and no clarifying round, and it never proposes a different approach. Matt sets that against typing "build this" at a fresh agent, "which often redesigns the work while it builds it." In his words, "Whatever was settled upstream is the input." So implement is the step where talking stops and building starts.
How it works underneath
Two ideas carry it.
Seams agreed before the code. A seam is "the public boundary you observe behaviour at without reaching inside." Tests live there. Matt's reason for agreeing them early: "When the seam is agreed before any code exists, the tests last." You can then rewrite the code underneath without touching the tests.
Matt also calls this "the skill's weakest point." "Nothing inside implement agrees the seams." The asking happens in tdd, whose own rule is "No test is written at an unconfirmed seam." So the agreement has to happen upstream in the Spec, or in the first exchange of the run. If it happens nowhere, Matt says, the run becomes "just write the code" and nothing warns you. His fix: "Naming the seams in the spec is what stops that."
From snapshot/skills/implement/SKILL.md, line 9: “If the user passes a ticket reference, fetch it from the issue tracker and state its title before starting. If the reference is ambiguous, ask.”
A check the agent can run. Anthropic's Claude Code guide states the same idea in general terms: "Give Claude something it can run that comes back pass or fail." With that, the agent can fix its own mistakes without you watching. The same guide says to build from a written spec in a fresh session, "so the build begins with a clean context and a written definition of done." That is the one-Ticket-per-fresh-session rhythm implement is built for.
A real example
The first line of the Skill, fetch the Ticket and state its title, has a real story behind it.
In pull request #1196 (opened 6 October 2026), Matt sums up a report from issue #700: "/implement #2 in a fresh Codex session resolved #2 against another numbered list in context, not the configured issue tracker, and started on the wrong work without saying so." The agent had matched "#2" to a list it could see, not to the Ticket. His fix was one rule: "fetch it from the issue tracker and state its title before starting." It merged on 7 October 2026. A wrong match now shows up in the agent's first line, where you can catch it. Matt's page adds a tip: "passing the issue URL or owner/repo#2 removes the ambiguity entirely."
On 6 October 2026, the day #1196 was opened, a commit changed how implement calls tdd and code-review. The old line read "Use /tdd where possible, at pre-agreed seams." The commit's reason: "A /skill mention in prose does not reliably load the skill." Since then the Skill tells the agent to call the Skill tool by name.
Where it goes wrong
tdd never runs. Issue #479 (opened 9 July 2026) reports that "TDD and code-review almost never run." On 18 July 2026 one user found the agent wrote the code first and the tests after. "The resulting green suite did not demonstrate that the tests could detect the pre-fix behaviour." On 13 September 2026 another user searched 1,125 of their own session transcripts for implement's own success check, a tdd call in the trace, and reported "0 of 17 runs met it." These reports all came before the 6 October 2026 wording change, and the issue is still open. The reply on Matt's account there is marked as written by AI during triage, so it isn't Matt's own words. The current Skill file is newer and decides what implement does: "Call the Skill tool with "tdd" where possible, at pre-agreed seams." Still, check the trace. Matt's page says it's working if you see "an actual tdd Skill" tool call "in the trace, not just tests appearing in the diff."
The review sees nothing. code-review looks at git diff <fixed-point>...HEAD, which "excludes staged and working-tree changes." implement runs it before committing, "so unless an interim commit already exists there is nothing in that diff to review." Matt's advice: "Commit first, then review against the point you branched from." Some people also move the review out of the run, because "an agent reviewing the code it just wrote is biased toward its own solution."
Nothing looks unblocked. implement "has no completion step." On a chain of Tickets that matters, because the next ones count as ready only when their blockers close. "If nothing gets closed, nothing ever becomes visibly unblocked."
Two runs in one checkout. One report describes "a stash vanishing from refs/stash, and commits landing on the wrong branch" in a single afternoon. The reason: "The sessions share one working directory, one index, and one HEAD." For several Tickets at once, Matt points to implement-spec, which gives each one its own worktree. Some people instead run separate implement sessions in their own worktrees, but refs/stash is shared across worktrees too, so worktrees alone don't fix the stash case.
A Ticket that eats the window. Matt says "a non-trivial ticket exceeding 100k" tokens "is normal rather than a sign something broke." If one keeps going over, "split it rather than raising the" effort level, back in to-tickets.
Try it
In your practice project (set it up first with keeping track's Try it step if you haven't), build one small Ticket, such as the booking endpoint for the yoga-studio API.
Open the Ticket and add one line naming its seam, for example "test through POST /bookings", so tdd has an agreed seam to work at.
Make a new branch from main and check it out. implement commits to whatever branch it's on.
In a fresh session, run /implement owner/yoga-studio#N, using the full reference.
Watch the first line: it should state the Ticket's title. Then look for a tdd Skill tool call before any code changes.
When it commits, open a pull request with Closes #N, so the Ticket closes when it merges.
Read more
The /implement Skill, Matt Pocock, marked updated 24 August 2026 but current to at least 7 October 2026
From snapshot/web/aihero.dev/skills-implement.md, line 91: “It never reopens the plan. There is no interview, no clarifying round, no proposal of a different approach. Whatever was settled upstream is the input,”
From snapshot/web/aihero.dev/skills-implement.md, line 133: “the public boundary you observe behaviour at without reaching inside. Tests live at seams. When the seam is agreed before any code exists, the tests last, and you can rewrite the implementation underneath without changing them.”
From snapshot/web/aihero.dev/skills-implement.md, line 135: “So in practice the agreement happens either upstream 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. Naming the seams in the spec is what stops that.”
From snapshot/web/github.com/mattpocock-skills-pull-1196.md, line 31: “/implement #2 in a fresh Codex session resolved #2 against another numbered list in context, not the configured issue tracker, and started on the wrong work without saying so. 3 files, one rule.”
From snapshot/web/aihero.dev/skills-implement.md, line 153: “code-review reviews git diff <fixed-point>...HEAD, which excludes staged and working-tree changes. implement runs it before committing, so unless an interim commit already exists there is nothing in that diff to review.”
From snapshot/web/aihero.dev/skills-implement.md, line 141: “This matters most on a dependency chain, because to-tickets defines the frontier as tickets whose blockers are all closed. If nothing gets closed, nothing ever becomes visibly unblocked.”
From snapshot/web/aihero.dev/skills-implement.md, line 145: “One field report describes a git commit --amend in one session landing on another session's commit, a stash vanishing from refs/stash, and commits landing on the wrong branch, all in a single afternoon across three issues. The sessions share one working directory, one index, and one HEAD.”