实现

它的作用¶

implement 构建已经决定好的工作。你让它指向一个工单、一个规格说明，或你刚刚在对话中同意的计划，然后它会编写代码，在接缝处驱动 tdd，边做边进行类型检查，最后运行 code-review，并提交到当前分支。

它从不重新打开计划。没有访谈，没有澄清环节，也不会提出另一种方案。上游已经确定的内容就是输入，而这个技能的全部工作就是将其转化为一次提交。这正是它与对一个新的代理输入“构建这个”的区别，后者常常在构建过程中重新设计工作。

何时使用它¶

你需要自己输入 /implement 来调用它，代理不会主动使用它。它带有 disable-model-invocation: true，因此其他技能也无法调用它。每当 ask-matt 或 to-tickets 说“然后每个工单 /implement”时，那是给你的指令，而不是代理会主动执行的事情。

工作当前所在的位置决定了这是否是合适的技能：

同一会话的情况值得单独说明，因为该技能自身的第一行并未覆盖它。SKILL.md 说“规格说明或工单”，这会促使模型去寻找一个不存在的文件。如果计划只存在于线程中，调用时请说明这一点。

前提条件¶

implement 会提交到你当前所在的分支。它不会创建分支，也不会询问。开始之前，请确认你位于希望承载该工作的分支上。

如果工单来自 to-tickets，setup-matt-pocock-skills 已配置了它们所在的跟踪器。code-review 会读取相同配置，以便在收尾时找到原始规格说明。

单次运行做什么¶

一次运行按顺序包含五个步骤：

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

一次运行覆盖一个工单。to-tickets 生成的工单是曳光弹式垂直切片，尺寸适合单个全新的上下文窗口，因此预期的节奏是：清空上下文，实现一个工单，提交，再次清空。每个工单都是自包含的，因此你可以丢弃上一个工单的上下文。

预先约定的接缝¶

该技能的核心概念是接缝，即你无需深入内部即可观察行为的公共边界。测试位于接缝处。当接缝在任何代码存在之前就已约定，测试就能持久存在，你可以重写其下的实现而不改变测试。

“预先约定”这一点很重要，它也是该技能最薄弱的环节。implement 内部没有任何内容会约定接缝。tdd 是负责询问的技能，它拒绝在未确认的接缝处编写测试。因此，在实践中，约定要么发生在上游的规格说明中，要么发生在运行的第一次交互中。如果哪里都没有发生，运行就会变成“只写代码”，而且没有任何警告。在规格说明中命名接缝可以阻止这种情况。

常见问题¶

它完成了，但我的工单仍然打开，验收标准仍未勾选。

正确，并且符合预期。implement 没有完成步骤。它结束于提交，并且从不触碰工作项。这在 GitHub Issues 和本地 markdown 跟踪器上是一样的，因此不是跟踪器集成问题。它也不会处理 code-review 产生的发现，并且不会勾选原始 issue 上的 - [ ] 复选框。请自行关闭工单并核对标准。这在依赖链上最为重要，因为 to-tickets 将前沿定义为所有阻塞项均已关闭的工单。如果没有任何工单被关闭，就没有任何工单会明显变为已解除阻塞。

我可以一次性让它处理所有工单，或者并行运行多个吗？

不能通过 /implement 做到：一次调用，一个工单。如果要一次运行整个规格说明，请使用 implement-spec，它会将前沿上每个就绪工单交给一个子代理，在各自的 worktree 中处理，然后将结果合并到一个集成分支上。在一个检出中并排运行多个 /implement 会话比不受支持更糟。一份现场报告描述了一个会话中的 git commit --amend 落在另一个会话的提交上，一个 stash 从 refs/stash 中消失，以及提交落在错误分支上，所有这些都在一个下午跨越三个 issue 发生。这些会话共享一个工作目录、一个索引和一个 HEAD。用户使用 git worktrees 来规避这个问题，但 refs/stash 也在 worktrees 之间共享，因此仅靠 worktrees 无法解决 stash 情况。

它能打开一个拉取请求（PR）而不是提交吗？

未内置。它会直接提交到当前分支。不少人觉得这过于急切，因为代码在他们验证其是否可用之前就已落地。没有配置标志，也没有 PR 模式。人们会在调用中覆盖它（“提交到一个分支并打开一个 PR”），或编辑该 skill 的本地副本。当 agent 确实撰写 PR 时，pr 会塑造其正文。

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

code-review 审查的是 git diff <fixed-point>...HEAD，其中不包含已暂存和工作树中的更改。implement 在提交前运行它，因此除非已经存在一个中间提交，否则该 diff 中没有可审查的内容。多人报告过此问题，且双方都尚未修复。先提交，然后针对你分支出去的基点进行审查。

另外，有些人完全不想在运行过程中进行审查，因为 agent 审查自己刚刚编写的代码时，会偏向于自己的方案。在全新会话中针对某个固定点运行 code-review 是一种可行的替代方案。同样的偏差也是该 skill 将两个维度放在独立子 agent 中运行的原因。

一张工单消耗了 150k tokens。我用错了吗？

可能不是。工单更可能太大了。一次运行会进行代码库探索、每个接缝处的红绿循环、完整测试套件和审查，因此一个非平凡工单超过 100k tokens 是正常的，而不是某处出错的迹象。解决办法在上游。在 to-tickets 中把工单调整到合适大小，使每个工单都能适配一个全新窗口。如果单个工单持续超出，应拆分它，而不是提高 effort 级别。

在全新会话中，/implement #2 处理了完全不相关的内容。

agent 将 #2 解析为上下文中的另一个编号列表，例如 todo 文件或检查清单，而不是已配置的 tracker。implement 现在会从 issue tracker 获取传入的引用，并在开始前说明其标题；当引用含糊时，它会询问。检查该标题是否对应目标工单；传入 issue URL 或 owner/repo#2 可完全消除歧义。

如果它正在工作¶

• 会话开始时，它会读取工单或 spec，并复述它将构建什么，而不是问你构建什么。
• 你能在 trace 中看到实际的 tdd Skill 工具调用，而不仅仅是 diff 中出现测试。
• 在运行过程中，类型检查和单个测试文件会反复运行，完整测试套件在接近尾声时运行一次。
• 运行会在你当前分支上达到一次提交，而无需你提示它继续。
• diff 只包含一张工单量的更改：贯穿每一层的垂直切片，而不是把多张工单混在一起。

它在哪里适用¶

implement 是主链中的构建步骤：

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

它的相邻技能是 to-tickets，该技能产生 implement 消费的工单，并声明决定工单顺序的阻塞边；tdd，它在每个接缝处内部驱动 tdd；以及 code-review，它在提交前运行 code-review。它位于规划技能下游，并信任它们。它不会重新验证所接收内容的结构，因此结构不佳的 map 或按水平分层的工单会按原样被构建。

正是这种信任，使得 wayfinder 在 to-spec 处并入该链，而不是将其 map 直接循环进 implement。只有当工作量确实很小时，才从 map 直接进入 implement。

ask-matt 是当你不确定自己处于哪个流程时，覆盖整个集合的路由器。