/implement 技能

它的作用

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

它从不重开计划。没有审问、没有澄清轮、没有提出不同方案。上游敲定的一切就是输入，技能的全部工作就是把它变成一次提交。这正是它区别于在全新 agent，它会在构建的同时乐此不疲地重新设计工作。

何时使用

你通过输入 /implement ——智能体不会自行调用它。它随 disable-model-invocation: true，所以其他技能也无法调用它。凡是 ask-matt or to-tickets 说「然后 /implement 每个任务」，那是给你的指令，不是智能体会主动做的事。

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

同会话的情况值得点名，因为技能自己的第一行没有覆盖它。 SKILL.md 说「规格说明或任务」，这推动 model 去找一个不存在的文件。如果计划只活在线索里，调用时说清楚。

前置条件

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

如果任务来自 to-tickets，它们所在的追踪器是由 setup-matt-pocock-skills. code-review 读取同一份配置，在收尾时找到源头的规格说明。

一次运行做什么

一次运行有五个节拍，依次是：

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

一次运行覆盖一个任务。任务 to-tickets 产出的是按单个全新 上下文窗口，所以预期的节奏是：清空上下文、实现一个任务、提交、再清空。每个任务自包含，这正是上一个任务的上下文可以丢弃的原因。

预先约定的接缝

技能运转所依据的想法是 seam：你在不深入内部的情况下观察行为的公共边界。测试住在接缝处。在任何代码写出之前就约定接缝，是测试持久耐用的原因，因为底下的实现可以重写，而测试无需移动。

「预先约定」这个词在干真实的活，它也是技能最薄弱的接点。 implement 约定接缝。 tdd 是提问的那个技能，它拒绝在未确认的接缝处写测试。所以实际上，约定要么发生在规格说明的上游，要么发生在运行的第一轮对话中。如果哪里都没发生，前置条件永远不会触发，运行就悄悄变成「直接写代码」。在规格说明中点名接缝，正是阻止这种情况的方法。

常见问题

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

正确，且符合预期。 implement 没有完成步骤。它以提交告终，从不触碰工作项，这一点在 GitHub Issues 和本地 markdown 追踪器上都得到了确认，所以这不是追踪器集成问题。它也不会对发现采取行动 code-review 产出，也不会勾选 - [ ] 框填在原始 issue 上。关闭任务并自己核对标准。这在依赖链上咬得最狠，因为 to-tickets 把前沿定义为所有阻塞项都已关闭的任务。如果什么也不关闭，就永远不会有什么变得可见地解除阻塞。

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

不。一次调用，一个任务。跨任务队列的批量派发和 子智能体 扇出都被反复要求，但两者都不存在。并行运行几个 /implement 在一个 checkout 中并排运行会话比不支持更糟：一份实地报告描述 git commit --amend 在一个会话中落在另一个会话的提交上，一个 stash 从 refs/stash，以及提交落到错误分支，全在同一个下午、横跨三个 issue。这些会话共享一个工作目录、一个索引和一个 HEAD。Git worktree 是社区的变通方案，注意 refs/stash 在 worktree 之间也是共享的，所以光靠 worktree 无法解决 stash 的情况。如果你今天就要并行，你得自己组装它。

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

没有内置。它直接提交到当前分支，这让一些人觉得太急切：代码在他们有机会验证它工作之前就落地了。没有配置开关，也没有 PR 模式。人们在调用时覆盖它（「提交到分支并打开 PR」），或通过编辑本地技能副本。

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

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

另外，有些人刻意完全不想让审查出现在运行内部，因为审查自己刚写代码的智能体偏向自己的方案。运行 code-review 在全新会话中对照一个固定点是合理的替代方案，也是那个技能在两个独立子智能体中运行两条轴的原因。

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

很可能是任务太大，而不是技能被误用。一次运行要做代码库探索、每个接缝的红-绿循环、完整测试套件和审查，所以一个超过 10 万 tokens 是正常的，而不是出问题的迹象。杠杆在上游：把任务切成合适大小 to-tickets 所以每个都能装进一个全新窗口。如果单个任务不断撑爆，拆分它，而不是调高 推理投入 层面。

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

#2 是按智能体能看到的那份编号列表解析的，在全新会话中可能是 todo 文件、检查清单或另一个工作清单，而不是配置的追踪器。解析是自信的而不是失败即关闭的，所以错误在开始之后才明显。请传入完整引用、issue URL 或 owner/repo#2，并在开始前让它确认标题。

做到以下就算成功

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

在流程中的位置

implement 是主链的构建步骤，倒数第二个：

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

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

那种信任正是 wayfinder 在 to-spec 而不是把它的地图直接循环进 implement。直接使用 implement 只有当任务结果确实很小的时候，才从地图来。

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