快记快用
把已经定好的工作变成代码：指向一张 ticket、一份 Spec，或刚谈妥的计划，按约定 seam 做 TDD，边写边 typecheck，最后跑 code-review 并提交到当前分支。不再访谈、不再改方案，只负责落地。一次跑一张 ticket（建议清干净 context 再开下一张）。输入 /implement 或 /implement #票号（GitHub 这类 tracker 用票号；本地 tracker 传票文件名）即可。
implement 的核心作用
/implement 把已经定好的工作（spec 或 tickets）真正落地成代码，并按工程纪律执行完整个构建闭环。
解决的是 AI 写代码时最常见、也最危险的一类失败模式：边写边重新设计/ vibe coding 式实现
直接对一个 agent 说 “build this” 时，agent 经常会：
- 在实现过程中偷偷改设计
- 忽略之前谈好的约束和验收标准
- 在同一个已经“疲惫”的上下文里自己审查自己的代码
- 写出半成品或偏离原始意图的代码
/implement 通过以下设计把这些问题解决：
- 输入必须是已经冻结的决策（spec/tickets），而不是模糊想法
- 强制走 TDD + 定期验证，而不是一口气写完再祈祷
- 最后用独立子 agent 做 code-review，避免“自己写的自己审”
- 每个 ticket 建议单独会话 + 清上下文，保持模型处于“smart zone”
使用方法和运行流程
输入
一个 ticket / 一份 spec / 对话里刚定下的计划+ 预定接缝（在 spec 里，或在 run 开场的第一次交流里）+ 当前分支（它不建分支、不询问，直接提交）处理
一次 run 是五步，按顺序：
- 读 ticket 或 spec，算出接缝。
- 在预定的接缝上驱动 tdd，一次一个红绿切片。
- 经常 typecheck，经常跑单个测试文件。
- 结尾跑一次全量测试套件。
- 跑 code-review，然后提交到当前分支。
一次 run 只覆盖一张票。to-tickets 产出的票是 tracer-bullet 垂直切片，尺寸按“装进一个全新的上下文窗口”来定，所以预期节奏是：清空上下文 → 实现一张票 → commit → 再清空一次。每张票自包含，上一张票的上下文因此变得可以丢弃。ask-matt 的上下文卫生写了配套的另一半：步骤 1 到 3 在一个不中断的上下文窗口里跑完，之后每个 implement 都从头开始，只看 ticket。
输出
输出是当前分支上的一次 commit。一条穿透每一个实现层的垂直切片。去向是当前分支，不建分支，没有 PR 模式。
概念总结
implement 把已经决定好的工作变成一次 commit：你把它指向一张 ticket、一份 spec，或对话里刚谈定的计划，它写代码、在接缝上驱动 tdd、边写边 typecheck、结尾跑 code-review，然后提交到当前分支。
它在主链上的位置是倒数第二步：grill-with-docs → to-spec → to-tickets → implement → code-review。上游 to-tickets 产出它消费的票，并在票上声明阻塞边决定顺序；内部由它驱动 tdd；下游 code-review 在它提交之前审查 diff。
源码解读
frontmatter：只有人能调用它
---name: implementdescription: "Implement a piece of work based on a spec or set of tickets."disable-model-invocation: true---译文
名字：implement。介绍：基于一份 spec 或一组 tickets 实现一份工作。disable-model-invocation：true（只能由人叫）。
It ships with
disable-model-invocation: true, so no other skill can call it either.
译文
它自带 disable-model-invocation: true，所以别的技能也调用不了它。
第一行：执行者不重新打开计划
Implement the work described by the user in the spec or tickets.
译文
实现用户在 spec 或 tickets 里描述的工作。
It never reopens the plan. There is no interview, no clarifying round, no proposal of a different approach. Whatever was settled upstream is the input, and the skill’s whole job is to turn that into a commit.
译文
它从不重新打开计划。没有访谈，没有澄清轮，没有换方案的提议。上游定下的一切就是输入，这个技能的全部工作就是把它变成一次 commit。
第二行：预定接缝，以及这个技能最弱的关节
Use /tdd where possible, at pre-agreed seams.
译文
尽可能在预先约定的接缝上使用 /tdd。
- “Use /tdd”：它自己不发明测试风格，内部驱动 tdd（tdd 是红 → 绿循环，加一套什么算好测试的参考）。
- “where possible”：不是所有活都值得 TDD，这里留了余地。
- “at pre-agreed seams”：接缝要在任何代码写出来之前就被同意。
这一段是 SKILL.md 里的原话，下面附译文：
The word “pre-agreed” is doing real work, and it is also the skill’s weakest joint. Nothing inside
implementagrees the seams.tddis the skill that asks, and it refuses to write a test at an unconfirmed seam.
译文
“pre-agreed” 这个词在做实事，它同时也是这个技能最弱的关节。implement 内部没有任何东西去达成接缝的同意。负责发问的是 tdd，而它拒绝在未确认的接缝上写测试。
第三行：一种频率，三种速度
Run typechecking regularly, single test files regularly, and the full test suite once at the end.
译文
经常跑类型检查，经常跑单个测试文件，结尾跑一次全量测试套件。
第四行：提交前跑 code-review
Once done, use /code-review to review the work.
译文
完成后，用 /code-review 审查这份工作。
code-reviewreviewsgit diff <fixed-point>...HEAD, which excludes staged and working-tree changes.implementruns it before committing, so unless an interim commit already exists there is nothing in that diff to review.
译文
code-review 审的是 git diff <fixed-point>...HEAD，它排除暂存区和工作区的改动。implement 在提交之前跑它，所以除非已经有一个中间的 commit，这个 diff 里没有任何东西可审。
Separately, some people deliberately 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.
译文
另外，有些人有意不在 run 里做这次审查，因为 agent 审查自己刚写的代码时，会偏向自己的方案。
第五行：提交到当前分支
Commit your work to the current branch.
译文
把你的工作提交到当前分支。
Not built in. It commits straight to the current branch, which several people find too eager: the code lands before they have had a chance to verify it works. There is no configuration flag and no PR mode.
译文
不内置 PR 模式。它直接提交到当前分支，有几个人觉得这太快：代码在他们有机会验证它能不能跑之前就已经落地。没有配置开关，也没有 PR 模式。
分享文章
生成精美分享图或复制链接，与更多人分享本文。
继续阅读
换条路线
从其他文章中稳定抽取
最后更新于 ，距今已过 43 天
部分内容可能已过时