The implement-spec Skill: Building a Whole Spec in Parallel

/implement-spec is the build step in Matt Pocock's open-source skills collection. You give it a spec and the tickets that /to-tickets cut from it. It reads the tickets as a task graph, starts one implementer subagent for every ticket that is ready, each in its own git worktree, merges finished work into a single integration branch, and runs a code review once at the end. This page covers how a run works, what it needs from your spec and tickets, how it differs from Superpowers' subagent-driven development, the problems its own docs list, and the checks we add before and after a run.

This page is an independent explainer. Spec Coding is not affiliated with Matt Pocock or AI Hero. Facts were checked against the skill's source and documentation on GitHub; we have not timed or benchmarked a run. It follows our article on the to-spec skill, which covers installation and the spec itself.

What /implement-spec does

The skill's description is one line: "Implement the result of /to-spec and /to-tickets in code." Its goal, in the SKILL.md's words, is "the entire spec implemented on a single integration branch, with every ticket resolved the way the issue tracker closes work." A run goes like this:

1. Read the spec and tickets and work out the task graph from the tickets' blocking edges.
2. Explore, optionally. An exploration subagent reads the relevant code and documentation and saves markdown notes in a directory outside the repository, so every later subagent can read them and implementers can stick to implementing.
3. Create the integration branch. If your tracker closes work through pull requests, or you ask for one, a draft PR is opened after the first merge.
4. Start one fresh implementer subagent per ready ticket, each in its own worktree on its own branch, running in the background where the harness allows. Each implementer 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 into the integration branch with a merger subagent, then start implementers for any tickets that just became unblocked.
6. Review once. When every ticket has landed, run the code-review skill over the integration branch and send all of its findings to one fresh implementer subagent to fix.
7. Close out: mark the draft PR ready, or resolve each ticket the way your tracker closes work, then delete the worktrees.

Two rules shape every step. Each subagent starts with a fresh context window, and communication between them is sparse: they pass context pointers (the spec, a ticket, the exploration notes, earlier commits) rather than pasted summaries. That keeps each implementer's prompt small and leaves room in the orchestrator's window for the graph.

Like /to-spec, the skill sets disable-model-invocation: true, so it runs only when you type the command. Its Codex manifest disables implicit invocation in the same way. A version note: the latest release, v1.3.2, already starts every subagent fresh. One commit on main after the release (a496f55, 29 October) spells out that each ticket gets its own fresh implementer and that the code-review fixes also go to a fresh one.

Tickets as a task graph: the frontier

The difference from working through tickets one by one is the graph. Each ticket from /to-tickets lists the tickets that block it. At any moment, the tickets whose blockers have all landed form the frontier, and everything on the frontier runs at once. The documentation puts it as "the graph's shape sets the pace, not the tickets' order on the tracker."

Here is the coupon spec from our to-spec article, cut into four tickets. This is an illustration we wrote by hand, not output captured from the skill:

Spec: Coupon codes at checkout (AC-1 to AC-4)

01  Apply a valid code at checkout        blocked by: none   closes AC-1
02  Reject expired codes with a message   blocked by: 01     closes AC-2
03  Allow one coupon per order            blocked by: 01     closes AC-3
04  Record the coupon on paid orders      blocked by: 01     closes AC-4

Frontier during the run
  wave 1   01
  wave 2   02  03  04     three implementers in parallel worktrees
  then     code-review over the integration branch, one fix subagent

Ticket 01 is the tracer bullet: one thin path through the pricing module, the checkout form and a test. The other three depend on it and not on each other, so they run together. If every ticket instead blocked the next one, the run would be a straight line and no faster than doing it by hand. If no ticket had edges, all four would start at once and the later ones would build on code that does not exist yet.

What it needs before you type the command

Installation is the same as for the rest of the collection. In Claude Code, claude plugin install mattpocock-skills@claude-plugins-official installs a plugin that updates itself; other agents use the skills.sh installer. The to-spec article walks through both and the one-time setup.

implement-spec vs implement vs Superpowers subagent-driven development

Three ways to turn a written plan into code with subagents look similar from a distance. The differences are who dispatches, how many tasks run at once, and when review happens:

The trade is review frequency against throughput. Superpowers' rule is that the controller should "never move to the next task while the review has open Critical/Important issues" that are neither fixed nor ruled on, and it picks the cheapest model that can handle each role. /implement-spec runs every ready ticket at once and accepts, in its docs' words, that "you no longer read each ticket's work as it lands; you review the integration branch at the end." Neither is wrong. They suit different specs: many independent tickets favour the graph, and a chain of tightly coupled tasks favours review after each step. The overlap in names is a separate source of confusion, since "SDD" inside Superpowers means subagent-driven development, not spec-driven development; our OpenSpec vs Superpowers vs Spec Kit comparison covers that.

Six problems its own docs list

The skill's documentation page is candid about what goes wrong. These six change how you run it:

1. The review and fix loop can run for hours. code-review compares the code against the whole spec, so it only makes sense after every ticket has landed; run mid-way, every unbuilt ticket reads as a failure. Even at the right point, the skill does not yet say when to stop after the fix. One user reported that on a five-ticket feature "the review and fix loop took roughly four hours." If a second broad review starts, tell the agent to run focused checks on the fixed findings and stop.
2. Parallel implementers collide. "Worktrees don't remove collisions; they postpone them to merge time." Two tickets that touch different features can still share a message catalogue, a config registry or a type, and each implementer sees only its own ticket. In one reported run, a web ticket and a mobile ticket added the same string as blockedSince and blockedOn. Either add a blocking edge between such tickets or fix the exact names in the exploration notes.
3. Blocked tickets never start on GitHub. A blocked-by count only drops when the blocker closes, and tickets usually close when the PR merges at the end of the run. Tell the orchestrator to track which tickets have merged into the integration branch and compute the frontier from that.
4. Tests skip silently in worktrees. A worktree holds only what git tracks. A test that reads a gitignored fixture, a local database or credentials can skip there while the ticket reports green. Run such tickets in the main checkout.
5. Seams are not agreed with you. Each implementer runs tdd, but unlike an /implement session there is no step where you confirm the seams. Name them in the spec or tickets if you want them fixed.
6. The output is a draft. The docs are explicit: "The run's output is a draft that the review completes, not something to ship on its own." Expect the first review to find real problems.

What we check before a run

Most of those problems trace back to the spec and the tickets, which are cheap to fix before anything runs in parallel. The checks below build on the numbered acceptance criteria we add to every /to-spec spec:

• Every criterion has exactly one owner. Each ticket lists the AC-n it closes, and each criterion appears in exactly one ticket. An orphaned criterion is work no implementer will do; a shared one is a collision waiting to happen.
• Every criterion fails at the start. The /to-tickets docs give the test: "For each criterion, name the observation that would show it false, and confirm it fails at the commit the implementer starts from." A criterion that already passes grades nothing.
• Shared files are settled up front. Look along each frontier wave for tickets that touch the same file. In the coupon example, tickets 02 and 03 both add an error code to the same error list, so we write COUPON_EXPIRED and COUPON_LIMIT into the exploration notes before the run.
• Seams are named. The spec's Testing Decisions name the seam, ideally one, so every implementer tests at the same boundary.
• Untracked dependencies are flagged. Any ticket whose tests need gitignored material is marked to run in the main checkout.

With the local markdown tracker, a ticket that passes those checks looks like this (hand-written, following the skill's local ticket template):

.scratch/coupon-codes/issues/02-reject-expired-codes.md

# 02: Reject expired codes with a clear message

**What to build:** a customer who enters an expired code sees
"This code has expired", and the order total does not change.

**Blocked by:** 01

**Status:** ready-for-agent

- [ ] AC-2: an expired code returns COUPON_EXPIRED; the total is unchanged
- [ ] Fails at start: on 01's merge commit, price(cart, "EXPIRED10")
      returns no COUPON_EXPIRED error
- [ ] Error code name fixed in the exploration notes: COUPON_EXPIRED

What we review on the integration branch

Because you do not read tickets as they land, the end-of-run review carries more weight than usual. We review it against the spec, one criterion at a time, and want evidence for each row before the branch merges:

AC     Ticket  Test at seam price(cart, code)          Start   End
AC-1   01      applies a valid code                     fail    pass
AC-2   02      rejects an expired code                  fail    pass
AC-3   03      rejects a second code on one order       fail    pass
AC-4   04      stores coupon_code and discount_cents    fail    pass

Also check
- each ticket landed as a fast-forward merge, not a conflict resolution
- nothing from Out of Scope was built (stacking, usage limits, admin UI)
- code-review findings are fixed, or recorded with a reason

The "Start" column is what turns a green test suite into evidence: a test that never failed proves nothing about the ticket that added it. Our test-evidence gates article covers how to make this check part of CI rather than a manual step.

When to reach for it

Our rule of thumb on top of that table: look at the widest frontier wave. If no wave has more than two tickets, the parallel gain is small and you give up per-ticket review for little, so /implement one ticket at a time is the better trade.

FAQ

What is the implement-spec skill?

A user-invoked skill in Matt Pocock's open-source skills collection. Given a spec and the tickets /to-tickets cut from it, it reads the tickets as a task graph, runs one implementer subagent per ready ticket in its own git worktree, merges each finished branch into one integration branch, and runs code-review once over the result.

How is /implement-spec different from /implement?

With /implement you are the dispatcher: one session per ticket, clearing in between, and you keep track of which tickets are unblocked. /implement-spec hands that job to one orchestrating agent that runs every unblocked ticket at once. The cost is that you review the integration branch at the end instead of each ticket as it lands.

Does /implement-spec need GitHub?

No. The run ends on the integration branch and opens a draft pull request only when your tracker closes work through PRs or you ask for one, so it works offline with the local markdown tracker.

Is it the same as Superpowers subagent-driven development?

No, though both give each task a fresh subagent. Superpowers works through a plan one task at a time and reviews every task before moving on. /implement-spec runs all ready tickets in parallel and reviews once, over the whole branch.

References

• implement-spec SKILL.md
• implement-spec documentation (when to use it, common questions)
• to-tickets SKILL.md and documentation
• mattpocock/skills on GitHub (README: installation, skill list)
• Superpowers subagent-driven-development SKILL.md
• Claude Code docs: Subagents

Checked on 2026-11-10 against mattpocock/skills main at commit a496f55 (2026-10-29, one commit after release v1.3.2) and obra/superpowers v7.0.2. Quotes are from the linked files.