The /implement-spec Skill

作用

implement-spec 取一个 规格说明 and its 任务 and lands the whole thing in one run. The orchestrating 智能体 hands each ticket to an implementer 子智能体 working in its own git worktree, merges each finished branch into a single integration branch, runs 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 前沿 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 sets the pace, not the tickets' order on the tracker.

何时使用

你通过输入 /implement-spec, and the agent won't reach for it on its own.

前置条件

• An issue tracker. The skill reads the tickets from, and resolves them on, the tracker 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 writes them. Without edges the graph is flat and every ticket starts at once.
• A 运行框架 that runs subagents in the background and gives each one a git worktree. The skill exists to run tickets at the same time, so on a harness that runs subagents one at a time, it is only a slower implement.

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, 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.

The tracker decides whether a pull request exists at all. If your tracker closes work through PRs, or you ask for one, the skill opens a draft PR after the first merge and marks it 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 上下文指针 (the spec, the ticket, shared exploration notes, earlier commits) rather than pasted summaries. This keeps each 子智能体's prompt small and leaves room in the orchestrator's window for the graph.

常见问题

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 need: 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 会话 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 run now ends on 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 happen when code-review runs anywhere other than the one point the skill gives it. It compares the code against the whole spec, so it only makes sense once every ticket has landed. If it runs mid-run, every unbuilt ticket reads as a failure. The agent then builds that ticket, 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 completes, 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 stopped as soon as they scaled up from one ticket to a whole spec. Each implementer now builds its ticket with tdd. There is still no step where you agree seams 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 和 blockedOn. When two frontier tickets touch one shared file, 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.

This is a known problem 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, a deterministic loop (Sandcastle, a shell script, a CI job) is faster, cheaper, and more reliable, because no agent makes the orchestration decisions.

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 silently skip there. For a ticket whose verification depends on untracked material, tell the orchestrator to run it in the main checkout instead.

做到以下就算成功

• 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.

在流程中的位置

implement-spec is the build step of the main chain, as the parallel alternative to running implement once per ticket:

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

它的邻居是 to-tickets, which declares the blocking edges it reads as a task graph, and code-review, which it runs over the integration branch before closing out. ask-matt 是整套技能的路由器，当你不知道自己在哪个流程中时。