implement

1. Bilingual SKILL.md

左右滑动可直接切换英文版与中文版；两种语言按段落自动对齐。英文中的蓝色虚线词语可点击查看解释。共标记 8 处。

Entry SHA-256: 6d3fd9e83b8f36e5213854779db49b256a457a7ebb4a503e53fa7dcff696adc3

2. Why This Skill Is Clever

一句话核心机制

把已经写进规格或工单的工作，压缩成一条有明确收尾的实施流水线：在约定接缝处做 TDD，以分层测试节奏持续校验，再进行代码审查并提交到当前分支。

触发与边界

直接来源： frontmatter 中的 disable-model-invocation: true 表明它是由用户显式触发的 skill；描述把输入限定为 “a spec or set of tickets”。它负责实施已经描述好的工作，不负责生成规格或拆分工单。

支撑上下文： 仓库的 ask-matt 路由把它放在 to-tickets → implement → code-review 的主流程中，并说明小型工作也可以在同一上下文直接进入 /implement。配套 tdd skill 把 seam 定义为从公开接口观察行为的位置，并要求测试前先确认 seam。

解读： 当需求仍模糊、接缝尚未约定，或当前分支不确定时，直接运行它风险较高。入口文件本身不会补做这些前置检查。

信息架构 / 执行顺序

1. 接收用户给出的 spec 或 tickets，确定实施对象。
2. 在条件允许时，把 /tdd 放到预先约定的 seams 上。
3. 实施过程中经常跑类型检查和单个测试文件，保持短反馈循环。
4. 只在末尾运行一次完整测试集，控制高成本验证的次数。
5. 完成后调用 /code-review，再把结果提交到当前分支。

这段源文件虽然很短，却把输入、内循环、验证节奏、质量门和持久化结果按时间顺序排成了一条完整路径。

最巧妙的设计点

1. “based on a spec or set of tickets” — 把规划与执行解耦。
   直接来源： skill 只接收已经成形的工作描述。
   解读： 这减少了实施阶段重新设计需求的机会，让上下游有清晰契约。

2. “where possible, at pre-agreed seams” — 给 TDD 加上两层边界。
   直接来源： where possible 保留现实弹性，pre-agreed 则要求测试位置已有共识。
   支撑上下文： tdd 明确说测试应观察公开接口，而不是内部实现。
   解读： 组合起来既避免把 TDD 变成教条，也降低测试绑定内部结构的概率。

3. “single test files regularly” 与 “the full test suite once at the end” — 用成本分层设计反馈回路。
   直接来源： 局部检查频繁，完整检查延后。
   解读： 快测试负责开发时的方向修正，慢测试负责最终回归覆盖；两者不是互相替代。

4. “Once done, use /code-review” — 把审查设为完成后的质量门。
   直接来源： review 明确位于实施与测试之后、commit 之前。
   支撑上下文： code-review 会把 Standards 与 Spec 两个审查轴分开。
   解读： 先产出、再独立检查，可以防止“代码能跑”被误当成“代码符合规格和仓库标准”。

5. “Commit your work to the current branch” — 用可持久化结果定义终点。
   直接来源： 终点不是一段聊天总结，而是 Git commit。
   解读： 明确产物使任务不容易停在半成品状态，但也把“当前分支正确”变成了外部前提。

防失败机制与 trade-off

原文明确的不变量： TDD 只在预先约定的 seams 进行；类型检查与单文件测试要反复运行；完整测试集在结尾运行；代码审查发生在提交之前；最终提交到当前分支。

防失败价值： 这套顺序同时覆盖规格偏差、类型错误、局部行为回归、全局回归与代码质量。每个检查点处理不同失败面，避免把所有风险都押在末尾一次大测试上。

权衡与可移植性风险：

• disable-model-invocation 和 /tdd、/code-review 的调用方式依赖具体 agent harness；迁移到其他系统时需要改写触发机制。
• 入口没有定义如何定位 spec/ticket、如何确认 seams，也没有检查当前 Git 分支；这些都依赖上游流程或用户。
• 配套文档指出一个次序张力：code-review 主要审查已提交到 HEAD 的 diff，而这里要求 review 后才 commit。更稳妥的工作流可能需要临时提交、明确 fixed point，或在新会话中复审。
• “完整测试集只在最后一次”适合昂贵套件；对极快或高风险项目，运行频率可能需要调整。
• skill 以 commit 收尾，却没有更新工单状态或验收清单；项目管理闭环仍需外层流程承担。

可迁移原则

1. 先写清输入契约。 执行型 skill 不应同时承担需求发现与计划拆解。
2. 让反馈回路分层。 高频运行便宜检查，低频运行昂贵全量检查。
3. 给自动化调用设置前置共识。 像 seam 这样的关键边界应在执行前确认。
4. 用独立质量门收尾。 实施者的“完成”判断之外，再增加规格与标准审查。
5. 把终点定义成可验证产物。 commit、发布物或状态记录应替代模糊的“已经做好”。

今日实践题

如果完整测试集需要 25 分钟，而单个测试文件只需 4 秒，你会如何为自己的实施 skill 写出“高频局部验证 + 低频全量验证”的明确顺序，并在哪一步确认测试 seams？

Evidence note

• 直接来源： 本报告的入口 skills/engineering/implement/SKILL.md，用于还原所有命令、顺序和显式边界。
• 支撑上下文： 同一仓库中的 ask-matt、tdd、code-review 及 docs/engineering/implement.md，仅用于解释它在流程中的位置、术语和已知权衡；这些内容不是入口原文。
• 解读： 关于不确定性压缩、成本分层、质量门价值与迁移建议的判断，是基于上述证据的工程分析。