/implement 技能

它的作用

implement 构建已经决定了的工作。你把它指向一个 ticket，一个 spec，或你在对话中刚敲定的计划，它编写代码、驱动 tdd 在接缝处，边进行边做类型检查，运行 code-review 在最后，并提交到当前分支。

它从不重开计划。没有审问、没有澄清轮、没有提出不同方案。上游敲定的一切就是输入，技能的全部工作就是把它变成一次提交。这正是它区别于在全新 agent, which often redesigns the work while it builds it.

何时使用

你通过输入 /implement yourself, and the agent won't reach for it on its own. It ships with disable-model-invocation: true，所以其他技能也无法调用它。凡是 ask-matt or to-tickets 说「然后 /implement 每个任务」，那是给你的指令，不是智能体会主动做的事。

工作当前住在哪里，决定这是否是正确的技能：

同会话的情况值得点名，因为技能自己的第一行没有覆盖它。 SKILL.md says "the spec or tickets", which pushes the model to look for a file that doesn't exist. If the plan lives only in the thread, say so when you invoke it.

前置条件

implement 提交到你当前所在的分支。它不会创建分支，也不会问你。开始前请确认你正位于你想要工作所在的分支上。

如果任务来自 to-tickets, setup-matt-pocock-skills configured the tracker they live on. code-review 读取同一份配置，在收尾时找到源头的规格说明。

一次运行做什么

A run has five steps, in order:

1. 读任务或规格说明，找出接缝。
2. 驱动 tdd 在预先约定的接缝处，一次一个红-绿切片。
3. 经常做类型检查，边进行边运行单个测试文件。
4. 最后运行一次完整测试套件。
5. 运行 code-review，然后提交到当前分支。

一次运行覆盖一个任务。任务 to-tickets 产出的是按单个全新 上下文窗口, so the intended rhythm is: clear context, implement one ticket, commit, clear again. Each ticket is self-contained, so you can discard the previous ticket's context.

预先约定的接缝

The skill's central idea is the seam, 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.

The "pre-agreed" part matters, and it is also the skill's weakest point. Nothing inside implement 约定接缝。 tdd is the skill that asks, and it refuses to write a test at an unconfirmed seam. 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.

常见问题

它完成了，但我的任务仍然开放，验收标准仍未勾选。

正确，且符合预期。 implement has no completion step. It ends at the commit and never touches the work item. This is the same on GitHub Issues and on the local markdown tracker, so it is not a tracker integration problem. It also does not act on the findings code-review 产出，也不会勾选 - [ ] boxes on the originating issue. Close the ticket and reconcile the criteria yourself. This matters most on a dependency chain, because to-tickets 把前沿定义为所有阻塞项都已关闭的任务。如果什么也不关闭，就永远不会有什么变得可见地解除阻塞。

我能一次指向我所有的任务，或者并行运行几个吗？

Not with /implement: one invocation, one ticket. For a whole spec in one run, use implement-spec, which gives each ticket on the ready frontier to a 子智能体 in its own worktree, then merges the results onto one integration branch. Running several /implement sessions side by side in one checkout is worse than unsupported. One field report describes a git commit --amend 在一个会话中落在另一个会话的提交上，一个 stash 从 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. Users work around this with git worktrees, but refs/stash is shared across worktrees too, so worktrees alone do not fix the stash case.

它能打开 pull request 而不是直接提交吗？

Not built in. It commits straight to the current branch. Several people find this too eager, because the code lands before they can verify it works. There is no configuration flag and no PR mode. People override it in the invocation ("commit to a branch and open a PR") or by editing their local copy of the skill. When the agent does write the PR, pr shapes its body.

code-review 说它看不到我的改动。

code-review reviews git diff <fixed-point>...HEAD，它排除暂存区和工作区改动。 implement 在提交前运行它，所以除非已存在中间提交，否则那个 diff 里没有什么可审查。多人报告了这一点，双方都未修复。先提交，然后对照你分支出去的点审查。

Separately, some people do not want the review inside the run at all, because an agent reviewing the code it just wrote is biased toward its own solution. Running code-review in a fresh session against a fixed point is a valid alternative. The same bias is why that skill runs its two axes in separate sub-agents.

一个任务烧掉了 15 万 Token。我是不是用错了？

Probably not. The ticket is more likely too big. A run does codebase exploration, a red-green loop per seam, a full suite, and a review, so a non-trivial ticket exceeding 100k tokens is normal rather than a sign something broke. The fix is upstream. Right-size the tickets in to-tickets so each fits one fresh window. If a single ticket keeps going over, split it rather than raising the 推理投入 层面。

/implement #2 在一个全新会话中做了完全不相关的事。

The agent resolved #2 against another numbered list in context, such as a todo file or checklist, rather than the configured tracker. implement now fetches a passed reference from the issue tracker and states its title before starting, and asks when the reference is ambiguous. Check that title matches the ticket you meant; passing the issue URL or owner/repo#2 removes the ambiguity entirely.

做到以下就算成功

• 会话以读取任务或规格说明并重述将构建什么开场，而不是问你构建什么。
• 你能看到实际的 tdd 技能 工具调用 in the trace, not just tests appearing in the diff.
• 类型检查和单个测试文件在运行期间反复执行，完整套件在接近尾声时运行一次。
• 运行在你当前分支上到达一次提交，无需你提示它继续。
• diff 是一个任务量的改动：穿过每一层的垂直切片，而不是几个任务扫在一起。

在流程中的位置

implement is the build step of the main chain:

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

它的邻居是 to-tickets，它产出该技能消费的任务，并声明决定其顺序的阻塞边界； tdd，它在每个接缝处内部驱动；而 code-review，它在提交前运行。它位于规划技能的下游并信任它们。它不会重新校验交给它的东西的形状，所以结构糟糕的地图或横向分层的任务会被按原样实现。

那种信任正是 wayfinder 在 to-spec 而不是把它的地图直接循环进 implement。直接使用 implement from a map only when the effort turned out small.

ask-matt 是整套技能的路由器，当你不知道自己在哪个流程中时。