implement

1. Bilingual SKILL.md

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

Entry SHA-256: 483bdc4ccf4ac31d86ac7beeaa0d0db80313e71e120bb8c59b3196ae5decd53d

2. Why This Skill Is Clever

一句话核心机制

把已经决定好的 spec / ticket 直接推进为一个经过分层测试、独立审查并落到当前分支的 commit，同时在开工前先核验 ticket 身份。

触发与边界

• Direct source： frontmatter 中的 disable-model-invocation: true 表明这是一个由用户显式启动的 skill；正文假设用户已经提供 spec、tickets 或 ticket reference。
• Direct source： 它不负责重新规划需求，只负责“Implement the work described by the user”。引用若含糊，唯一明确的停机条件是先询问。
• Supporting context： 同目录 agents/openai.yaml 也设置 policy.allow_implicit_invocation: false，与上游的双 harness 调用约定保持一致。
• Interpretation： 这是执行阶段的窄入口，不应拿它替代需求澄清、拆票或架构探索。

信息架构 / 执行顺序

1. 锁定输入身份。 如果收到 ticket reference，先从 tracker 获取并说出标题；含糊则暂停询问。
2. 按已决定的范围实现。 spec / tickets 是工作边界，而不是重新设计的邀请。
3. 在 seam 上驱动 TDD。 在可行且边界已预先约定时，显式调用 tdd skill。
4. 按成本分层反馈。 高频运行 typecheck 和单个测试文件，把完整套件留到最后一次。
5. 独立审查并固化。 完成后调用 code-review，随后 commit 到当前分支。

最巧妙的设计点

1. 把歧义消解变成可观察动作。 原文要求 state its title before starting。标题复述不是礼貌性摘要，而是一个低成本 identity check：若 #42 被解析到错误仓库，用户在写代码前就能发现。
2. 通过 pre-agreed seams 约束 TDD 的落点。 它不只说“写测试”，而是要求测试锚定在已确认的公共边界。这样测试更像稳定契约，而不是实现细节的快照。
3. 把验证成本分层。 typechecking regularly、single test files regularly 与 full test suite once at the end 组合成快反馈循环加最终全量门禁，避免每个微小改动都支付全套成本。
4. 强制显式 Skill 调用。 Call the Skill tool with "tdd" 与随后调用 code-review，让重要子流程在 trace 中可见，也能复用各自独立的规则，而不是靠一句模糊的“测试并检查”。
5. 以 commit 作为完成边界。 Commit your work to the current branch 把“写完代码”推进为可追踪的仓库状态，减少半成品只留在 working tree 的风险。

防失败机制与 trade-off

Direct source 明确规定的门禁：

• ticket reference 必须解析并复述标题；歧义时必须询问；
• TDD 只在可行且 seam 已预先约定时调用；
• typecheck 与聚焦测试应定期运行，完整测试套件在最后运行；
• 完成后必须调用 code-review；
• 最终必须 commit 到当前分支。

Trade-off 与可移植性风险：

• where possible 给了必要弹性，但没有要求记录跳过 TDD 的理由；执行者可能把例外扩大成默认。
• skill 假定 issue tracker、Skill tool、Git branch 和测试命令都已可用，这些是 harness / 项目环境依赖。
• Supporting context： 官方 docs 指出一个现实顺序风险：code-review 若只查看已提交的固定点 diff，而此处又要求 review 在 commit 前执行，审查可能看不到尚未提交的改动。这是 companion docs 的已知限制，不是所选 SKILL.md 自己声明的保证。
• 直接 commit 到 current branch 简洁但偏强势；若团队要求 PR、隔离分支或人工批准，需要在外层工作流增加门禁。

可迁移原则

1. 对短引用先做身份回显，再执行有成本的工作。
2. 把测试放在预先确认的行为边界，而不是临时选中的实现细节上。
3. 将验证拆成高频便宜检查与一次低频全量检查。
4. 对关键子流程使用显式工具调用，让执行证据可观察。
5. 用持久化仓库状态定义完成，但必须明确分支与审批边界。

今日实践题

如果用户只说“实现 #42”，你会要求 agent 在第一行回显哪两个信息，才能最大限度避免工单解析错位？

Evidence note

本文的流程顺序、短引文、调用要求和测试节奏来自所选 skills/engineering/implement/SKILL.md（Direct source）；用户调用语义、review 可见性风险与流程位置参考了同仓库 agents/openai.yaml、.agents/invocation.md 和 docs/engineering/implement.md（Supporting context）；关于身份回显、成本分层与完成边界的价值判断属于设计解释（Interpretation）。Supporting context 并非所选原文的一部分。