用途
implement 用于把用户给出的规格（spec）或一组工单（tickets）中描述的工作真正实现出来。当用户希望把一份现成的规格、工单或已商定的计划构建出来，或直接说“实现它”时，就使用这个技能。
如果用户传入了一个工单引用，先从问题跟踪器获取该工单，并在开始前说明它的标题。如果引用不明确，则询问用户。
主要能力
该技能把实现过程组织为六个步骤，每一步只有在其完成标准成立时才算完成：
-
构建（Build）：尽可能以 Skill 工具调用 "tdd"，在预先商定的接缝处工作。定期运行类型检查和单个测试文件。凡是本次运行之后仍然存在的产物（docblock、代码注释、README、文档、ADR）都不得指向 .scratch/，因为该文件夹会被定期清空，引用会失效；应内联说明所需事实，或引用仓库中的永久文件。完成标准：规格或工单的每一部分都已写出。
-
测试（Test）：运行一次完整测试套件。完成标准：套件已运行且知道其结果。
-
重构（Refactor）：在套件为绿的前提下，对本次运行所写的代码做一次清理。前置条件：测试步骤后完整套件为绿；若不是，则跳过此步并在 Verdict 中说明。范围：仅限本次运行的 diff 所创建或修改的代码（未提交的工作树；在 /delegate-tickets 下则恰好是当前工单）。在 diff 之外看到的有价值重构绝不应用，只在 Verdict 中记录。规则：不得改变行为，绝不为让重构通过而修改测试。先做快照，使用 git stash create（记录状态，不改 ref、索引或工作树）或把 diff 涉及的文件复制到一旁。重构后运行完整套件：绿则保留重构；红则恢复快照，使工作树精确回到重构前的绿色状态（对 git stash create 快照使用 git restore --source=<snapshot> --worktree -- <files>，它不动索引；同时删除重构创建的文件、重建其删除的文件，因为快照不覆盖它们），然后继续进入审查。完成标准：重构要么在套件为绿的情况下被保留，要么被撤销回绿色快照，要么因套件为红而被跳过。
-
审查（Review）：现在以真正的 Skill 调用方式调用 /review-axes 技能。把未暂存的工作树作为其固定点：改动尚未进入任何提交，因此基于 ref 的 diff 会返回空。同时传入所给工单的路径，或在没有工单时传入规格路径，作为 spec 参数，使其无需自行搜索规格，并同步正确的复选框。把规格或工单中的验收标准复选框（- [ ] / - [x]）留给 /review-axes，它会在 Spec 审查后根据代码实际行为同步它们。完成标准：/review-axes 在本次运行中返回其 Standards 和 Spec 报告。步骤 1 到 3 通过是本步骤的输入，绝不是它的替代：下面的 Verdict 由审查输出构建，因此在审查存在之前无法写出。
-
提交（Commit）：把工作提交到当前分支。完成标准：本次运行的改动已进入当前分支的一个提交。
-
报告（Report）：以 Verdict 部分结尾。
子代理 effort 约束
本次运行中生成的每个子代理，无论是你生成的，还是你调用的技能（/tdd、/review-axes）生成的，都以 effort: medium 运行，无论其模型是什么。用户的 effort 级别只属于本会话，绝不延续到子代理。
high 或以上（high、xhigh、max）需要用户明确同意才能生成：先询问，说明子代理名称、模型、effort 以及为什么 medium 不够，然后等待。没有回答即视为否。一次同意只覆盖它所针对的那次生成。
如果宿主无法为每次生成设置 effort，而子代理会从本会话继承 high 或更高，这种继承等同于以 high 生成：同样需要先获得同意。
如果没有人能回答（你作为子代理运行、无人值守，或简报说明没人在场），停止并把该问题作为阻塞项报告。绝不退回到内联完成工作。在交互式会话中，继续按上述方式询问并等待同意。同样的规则适用于本次运行会向用户提出的所有其他问题，例如规格在哪里：无人值守时它是阻塞项，绝不猜测。
Verdict 规则
以 Verdict 部分结尾。一行：先是 emoji，然后是简短原因。🟢 是单独的 emoji，后面没有文字。
- 🟢：一切按计划进行——完全实现，没有任何偏离规格或工单，/review-axes 未提出需要处理的问题，无需用户操作。只打印 emoji，不打印其他内容。
- 🟡：已实现，但中途不得不调整：计划逻辑改变、方法被替换、某个规格细节被解释，或 /review-axes 提出了值得一看的发现。也适用于：重构因套件变红而被撤销（附一行原因），或在 diff 之外看到有价值的重构（建议开一个 prefactor 工单，绝不应用）。被保留的重构不影响颜色。因套件为红而跳过的重构会在 Verdict 中说明，而红色套件本身按现有方式决定颜色。说明改了什么以及为什么。
- 🔴：某部分没有落地，或用户必须在继续前采取行动：某部分未实现、/review-axes 发现规格缺口、某个决定需要用户拍板、需要凭据/迁移/手动步骤，或任何破坏其“直接开始下一个工单”流程的情况。说明是什么以及用户需要做什么。
选择最严重且适用的颜色：任何红色条件都会使 Verdict 为 🔴，即使其余部分进展顺利。
适用场景
适用于已有明确规格、工单或已商定计划、需要将其落地实现的开发工作流。尤其适合希望实现过程遵循“构建—测试—重构—审查—提交—报告”固定流程，并对子代理 effort 有严格管控的场景。
限制
- 子代理默认以 medium effort 运行，使用 high 或更高需用户明确同意，无人值守时相关提问会成为阻塞项。
- 重构仅在完整套件为绿时进行，且不得改变行为、不得修改测试。
- 本次运行之后仍存在的产物不得引用 .scratch/ 文件夹。
- 在 diff 之外发现的有价值重构不会被应用，只会记录。
- 关于收费、价格、平台支持等具体信息，资料中暂未提供。