/implement 技能

它做什么

implement 构建已经决定好的工作。你把它对准一个工单（ticket）、一份规范文档（spec），或者你们刚在对话里商定的计划，它就会写出代码，在接缝处驱动 tdd，边做边跑类型检查，最后运行 code-review，并提交到当前分支。

它从不重新打开计划。没有访谈，没有澄清轮，也不会提议另一种做法。上游定下来的东西就是输入，这个技能的全部工作就是把它变成一个提交。这正是它与对一个全新 agent 输入「构建这个」的区别——后者常常一边构建一边重新设计这件工作。

什么时候用它

你要自己输入 /implement 来调用它，agent 不会主动去拿它。它带有 disable-model-invocation: true，所以别的技能也调不动它。无论 ask-matt 或 to-tickets 在哪里说「然后每个工单跑一次 /implement」，那都是给你的指示，而不是 agent 会在无人提示时自己去做的事。

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

同场会话这种情况值得点名，因为技能自己的第一行没有覆盖它。SKILL.md 说的是「规范文档或工单」，这会把模型（model）推向去找一个并不存在的文件。如果计划只活在讨论串里，调用它的时候就说清楚。

前提条件

implement 提交到你当前所在的分支。它不会创建分支，也不会问。开始之前，确认你在你想让工作落地的那个分支上。

如果工单来自 to-tickets，那么 setup-matt-pocock-skills 已经配置好了它们所在的追踪器。code-review 在收尾时读取同一份配置，找出最初的规范文档。

一次运行做什么

一次运行有五个步骤，按顺序：

1. 读工单或规范文档，弄清楚接缝。
2. 在预先商定的接缝上驱动 tdd，一次一个红—绿切片。
3. 频繁做类型检查，边做边跑单个测试文件。
4. 最后完整跑一次全套测试。
5. 运行 code-review，然后提交到当前分支。

一次运行覆盖一个工单。to-tickets 产出的工单是按单个全新上下文窗口（context window）来定大小的曳光弹式垂直切片，所以预期的节奏是：清除上下文，实现一个工单，提交，再清除。每个工单都是自包含的，所以你可以丢掉上一个工单的上下文。

预先约定的接缝

这个技能的核心概念是接缝（seam），也就是你在不深入内部的情况下观察行为的公共边界。测试住在接缝上。当接缝在任何代码存在之前就商定好时，测试就能长久，你可以在底下重写实现而不改动它们。

「预先商定」这部分很重要，它也是这个技能最弱的地方。implement 内部没有任何东西去商定接缝。负责问的是 tdd 这个技能，它拒绝在一道未确认的接缝上写测试。所以在实践中，商定要么发生在上游的规范文档里，要么发生在这次运行的第一次交流中。如果哪里都没有发生，这次运行就变成「只管写代码」，而没有任何东西提醒你。在规范文档里点名接缝，才能阻止这种情况。

常见问题

它结束了，但我的工单还开着，验收标准也还没勾。

没错，而且是预期行为。implement 没有完成步骤。它止于提交，从不碰工作项。在 GitHub Issues 和本地 Markdown 追踪器上都是这样，所以这不是追踪器集成的问题。它也不会处理 code-review 产出的发现，也不会勾掉最初那个 issue 上的 - [ ] 方框。工单要你自己关闭，验收标准要你自己核对。这在依赖链上最要紧，因为 to-tickets 把前沿定义为阻塞者全部关闭的那些工单。如果没有任何东西被关闭，就永远不会有东西在表面上变成解除阻塞。

我能让它一次对准我所有的工单，或者并行跑好几个吗？

/implement 做不到：一次调用，一个工单。想在一次运行里完成整份规范文档，用 implement-spec，它把就绪前沿上的每个工单交给一个在自己的 worktree 里工作的子代理（subagent），然后把结果合并到一个集成分支上。在同一个检出目录里并排跑好几个 /implement 会话，比「不受支持」还要糟。有一份现场报告描述道：一个会话里的 git commit --amend 落到了另一个会话的提交上，一个 stash 从 refs/stash 里消失，提交落到了错误的分支上——全发生在同一个下午，横跨三个 issue。这些会话共享同一个工作目录、同一个索引和同一个 HEAD。用户用 git worktree 来绕开这个问题，但 refs/stash 在 worktree 之间也是共享的，所以光靠 worktree 并不能解决 stash 那种情况。

它能不提交，改为开一个 PR（pull request）吗？

没有内置。它直接提交到当前分支。有几个人觉得这太急了，因为代码在他们能验证它可用之前就落地了。没有配置开关，也没有 PR 模式。人们在调用时覆盖它（「提交到一个分支并开一个 PR」），或者编辑自己本地的技能副本。当 agent 确实要写 PR 时，pr 会塑造它的正文。

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

code-review 审查的是 git diff <fixed-point>...HEAD，这排除了已暂存和工作区里的改动。implement 在提交之前运行它，所以除非已经有一个中间提交存在，那个 diff 里根本没有东西可审。多个人报告过这一点，两边都没有修。先提交，再对着你分叉出来的那个点审查。

另外，有些人根本不想要运行内部的这次审查，因为 agent 审查自己刚写的代码时，会偏向自己的方案。在一场全新的会话里对着一个固定点（fixed point）运行 code-review，是一个有效的替代方案。同样的偏向，也是那个技能把它的两个维度放在各自独立的子代理里运行的原因。

一个工单烧掉了 150k token。我用错了吗？

大概没有。更可能是这个工单太大了。一次运行要做代码库探索、每个接缝一轮红—绿循环、一次全套测试，再加一次审查，所以一个不简单的工单超过 100k 个 token 是正常的，而不是出问题的信号。修法在上游。在 to-tickets 里把工单的大小调对，让每个都装得下一个全新窗口。如果单个工单持续超标，就拆分它，而不是提高投入级别（effort）。

在一场全新的会话里，/implement #2 跑去做了一件完全无关的事。

agent 把 #2 解析成了上下文里另一个编号列表——比如一个 todo 文件或检查清单——而不是配置好的追踪器。implement 现在会从 issue 追踪器取来传入的引用，并在开始前说出它的标题；当引用有歧义时会发问。检查那个标题是不是你想指的那个工单；传入 issue URL 或 owner/repo#2 能彻底消除歧义。

它生效的标志

• 会话一开始，它读工单或规范文档，并复述自己将要构建什么，而不是问你要构建什么。
• 你能在轨迹里看到一次真正的 tdd 技能工具调用，而不只是 diff 里冒出来的测试。
• 类型检查和单个测试文件在运行期间反复执行，全套测试在接近结尾时完整跑一次。
• 这次运行在你的当前分支上走到一个提交，而不需要你催促它继续。
• diff 是一个工单分量的改动：一条穿过每一层的垂直切片，而不是几个工单被扫到一起。

它在体系中的位置

implement 是主链上的构建步骤：

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

它的邻居是 to-tickets——它产出这个技能所消费的工单，并声明决定这些工单顺序的阻塞边；tdd——它在每一道接缝上内部驱动它；以及 code-review——它在提交前运行它。它位于规划类技能的下游，并且信任它们。它不会重新验证交给它的东西的形状，所以一张结构糟糕的地图或一个按层切分的工单会被原样构建出来。

正是这种信任，让 wayfinder 在 to-spec 处接入链条，而不是把它的地图直接灌进 implement。只有当那件工作最终证明很小时，才从地图直接走到 implement。

当你不确定自己身处哪条流程时，ask-matt 是覆盖整套技能的路由器（router）。

原文：aihero.dev/skills-implement