The /implement-spec Skill

Developer Matt Pocock released the /implement-spec skill, installable via `npx skills@latest add mattpocock/skills --skill=implement-spec`, which takes a spec and its tickets and lands the entire spec in one run. The orchestrating agent reads tickets as a task graph with blocking edges, dispatches each frontier ticket to an implementer subagent in its own git worktree, merges finished branches into a single integration branch, runs code-review over the result, and resolves the tickets. The skill requires an issue tracker, tickets with blocking edges as written by to-tickets, and a harness that runs subagents in the background with per-subagent git worktrees.

The /implement-spec Skill Build a whole spec at once, with parallel subagents. Install this skill npx skills@latest add mattpocock/skills --skill=implement-spec Then type /implement-spec in your coding agent. - Source - mattpocock/skills https://github.com/mattpocock/skills On this page What it does what-it-does implement-spec takes a spec https://www.aihero.dev/ai-coding-dictionary/spec and its tickets https://www.aihero.dev/ai-coding-dictionary/ticket and lands the whole thing in one run. The orchestrating agent https://www.aihero.dev/ai-coding-dictionary/agent hands each ticket to an implementer subagent https://www.aihero.dev/ai-coding-dictionary/subagent working in its own git worktree, merges each finished branch into a single integration branch , runs code-review https://www.aihero.dev/skills-code-review over the result, and resolves the tickets. It reads the tickets as a task graph , not a list. Blocking edges decide what can start, so at any moment there is a frontier of tickets whose blockers have all landed, and every ticket on the frontier runs at once. That is the difference from working the tickets one by one: the graph's shape, not its order on the tracker, sets the pace. When to reach for it when-to-reach-for-it You invoke this by typing /implement-spec , and the agent won't reach for it on its own. | Your situation | Reach for | |---|---| | A spec, split into tickets with blocking edges, that you want landed in one run | /implement-spec | | One ticket at a time, in your own context window https://www.aihero.dev/ai-coding-dictionary/context-window , clearing https://www.aihero.dev/ai-coding-dictionary/clearing between tickets | implement https://www.aihero.dev/skills-implement | | A spec that isn't split into tickets yet | to-tickets https://www.aihero.dev/skills-to-tickets first | | A small piece of work with no real graph to it | implement https://www.aihero.dev/skills-implement directly | Prerequisites prerequisites - An issue tracker. The skill reads the tickets from, and resolves them on, the tracker setup-matt-pocock-skills https://www.aihero.dev/skills-setup-matt-pocock-skills configured. If none has been configured, it stops and tells you to run that first rather than guessing. - Tickets with blocking edges , as to-tickets https://www.aihero.dev/skills-to-tickets writes them. Without edges the graph is flat and every ticket starts at once. - A harness https://www.aihero.dev/ai-coding-dictionary/harness that runs subagents in the background and gives each one a git worktree. The concurrency is the point; a harness that runs subagents one at a time gets a slower implement . The integration branch the-integration-branch Everything lands on one branch. Each implementer: 1. confirms its worktree is based on the integration branch before it starts, 2. builds its ticket with tdd https://www.aihero.dev/skills-tdd , red-green one slice at a time, 3. merges the integration branch tip into its own branch before reporting done, so landing it is a fast-forward. Whether a pull request exists at all is the tracker's call. If your tracker closes work through PRs, or you ask for one, a draft PR opens after the first merge and is marked ready at the end. Otherwise the run stops on the integration branch with every ticket resolved the way your tracker closes work, which works fully offline against a local markdown tracker. Implementers talk to the orchestrator through context pointers https://www.aihero.dev/ai-coding-dictionary/context-pointer the spec, the ticket, shared exploration notes, earlier commits rather than pasted summaries, which keeps each subagent https://www.aihero.dev/ai-coding-dictionary/subagent 's prompt small and the orchestrator's window free for the graph. Common questions common-questions How is this different from running /implement on each ticket myself? This is the question the skill exists to answer. Before it shipped, people kept building their own versions, and one user described the itch exactly: they wanted "subagents implement the tickets" instead of having "to individually create new session and tell them to implement a ticket one by one, when a spec may contain over 5 tickets." With implement you are the dispatcher: one session https://www.aihero.dev/ai-coding-dictionary/session per ticket, clearing in between, and keeping track yourself of which tickets are unblocked. implement-spec hands that job to one orchestrating session. The price is that you no longer read each ticket's work as it lands; you review the integration branch at the end. To start a run, clear the context and type /implement-spec with a pointer to the spec an issue number or a file path . For a small change with no real graph, skip it and use implement directly. Does it need GitHub? I want it to stop at the branch. No, not any more. One user who liked the in-progress version had exactly this complaint: "it creates a PR at the end, which requires an online repository like GitHub. I wish it could do the same work offline and stop at the branch where all the work is merged." The goal is now the integration branch. A PR opens only when the configured tracker closes work through PRs or you ask for one, so on a local markdown tracker the run ends with every ticket resolved and the work merged on the branch. Its review and fix loop ran for hours, or kept "fixing" tickets that hadn't been built yet. Both come from code-review running outside the one slot the skill gives it. It compares the code against the whole spec, so it only makes sense once every ticket has landed; run it mid-run and every unbuilt ticket reads as a failure, the agent sets about building it, and that triggers another review. At the end, the skill runs code-review once and sends every finding to one fix subagent, but it doesn't yet say when to stop after that fix. One user reported a five-ticket feature where "the review and fix loop took roughly four hours". If you see a second broad review start, tell it to run focused checks for the fixed findings and stop. Expect that first review to find real problems: the run's output is a draft that the review finishes, not something to ship on its own. Does it drive tdd like implement does? It does now, though it didn't at first. Users running the in-progress version noticed that "the implementer subagents don't inherit the /tdd directive", so red-green dropped out the moment they scaled up from one ticket to a whole spec. Each implementer now builds its ticket with tdd . There is still no step where seams get agreed interactively, as there is in an implement session, so name the seams in the spec or the tickets if you want them pinned. Two implementers running in parallel collided on the same file, or picked different names for the same thing. Worktrees don't remove collisions; they postpone them to merge time. A blocking edge written from ticket text is a guess about which files each ticket will touch, and two tickets on "different parts of the codebase" still share a message catalogue, a config registry, or a type. Each implementer sees only its own ticket and the shared notes, never the other's work in progress, so one user's web and mobile tickets added the same string as blockedSince and blockedOn . When two frontier tickets touch one shared surface, either add a blocking edge between them so they run one after the other, or have the exploration notes fix the exact names each ticket adds. Blocked tickets never start, even after their blocker has merged. A known rough edge on GitHub. The tracker's blocked-by count only drops when a blocker closes , and tickets typically close when the PR merges, which is the end of the run. The tracker is the right source for the starting graph but a stale one mid-run. Tell the orchestrator to track which tickets have merged into the integration branch itself and compute the frontier from that. Does this replace Sandcastle or an AFK script? No. People ask because the skills now reach into implementation: "is Sandcastle still relevant? Your skills now seem to be able to handle implementation as well." implement-spec puts an agent in charge of orchestration inside one harness session, which needs no infrastructure and lets you watch and steer. For work that is truly AFK https://www.aihero.dev/ai-coding-dictionary/afk , a deterministic loop Sandcastle https://github.com/mattpocock/sandcastle , a shell script, a CI job is faster, cheaper, and more reliable, because no part of the orchestration can wander off. A ticket's key test was skipped inside its worktree, and it reported green. A worktree holds only what git tracks. Tests that read gitignored fixtures, local databases, or credentials can skip themselves there silently. For a ticket whose verification depends on untracked material, tell the orchestrator to run it in the main checkout instead. It's working if its-working-if - Several implementers are running at once whenever the graph allows, not one after another. - A ticket starts as soon as its last blocker lands on the integration branch, not when the whole run ends. - Every ticket's trace shows tdd running, with a failing test before the code. - Merges into the integration branch are fast-forwards, not conflict resolutions. - The run ends on one branch with every ticket resolved, and a PR only if your tracker wanted one. Where it fits where-it-fits implement-spec is the build step of the main chain, as the parallel alternative to running implement https://www.aihero.dev/skills-implement once per ticket: grill-with-docs → to-spec → to-tickets → implement-spec → retro Its neighbours are to-tickets https://www.aihero.dev/skills-to-tickets , which declares the blocking edges it reads as a task graph, and code-review https://www.aihero.dev/skills-code-review , which it runs over the integration branch before closing out. ask-matt https://www.aihero.dev/skills-ask-matt is the router over the whole set when you are not sure which flow you are in. Skill actions npx skills@latest add mattpocock/skills Installs the whole set. Then type /implement-spec in your coding agent. Skills.sh https://www.skills.sh/mattpocock/skills