implement

按照用户在规范或工单中描述的内容分六步实施。只有满足完成标准后，才算完成每一步。

如果用户提供了工单引用，请从问题跟踪系统中获取该工单，并在开始前说明其标题。如果引用不明确，请询问。

子 Agent 工作量

本次运行中启动的每个子 Agent，无论是你启动的，还是你调用的技能（/tdd、/review-axes）启动的，都以 effort: medium 运行，无论使用什么模型。用户指定的工作量仅适用于当前会话，不会延续到子进程。

high 或更高（high、xhigh、max）的工作量需要先获得用户明确同意：询问用户，说明子 Agent 的名称、模型、工作量，以及为什么 medium 不够，然后等待回复。没有回复就视为不同意。一次同意仅适用于它所针对的子进程。

如果宿主无法为每个子进程单独设置工作量，而子 Agent 会继承本会话中的 high 或更高工作量，则视为以 high 工作量启动：必须先获得同样的同意。

如果无人能够回答（例如，你以子 Agent 身份运行、无人值守，或任务说明中提到当前无人可联系），请停止并报告该问题为阻塞项。绝不能直接在当前进程中完成工作。在交互式会话中，按上述方式继续询问并等待同意。同一规则也适用于本次运行中需要向用户提出的其他问题，例如规范在哪里：无人值守时，应将其列为阻塞项，绝不能猜测。

1. 构建

尽可能调用 Skill 工具并传入「tdd」，在事先约定的衔接点开展工作。定期运行类型检查和单个测试文件。

本次运行结束后仍会保留的任何内容（文档注释、代码注释、README、文档、ADR）都不得引用 .scratch/ 中的内容：该文件夹会定期清空，因此引用会失效。请直接写明所需事实，或引用仓库中的永久文件。

完成标准：规范或工单中的所有内容都已编写完成。

2. 测试

完整运行一次测试套件。

完成标准：测试套件已运行，并且已知其结果。

3. 重构

仅当测试套件在「测试」步骤后通过时，才对本次运行编写的代码进行一轮清理。

• 前提条件：「测试」步骤后完整测试套件通过。如果未通过，请跳过此步骤，并在「结论」中说明。
• **范围：**仅限本次运行新增或修改的代码（未提交的工作树，因此在 /delegate-tickets 下仅限当前工单）。绝不应用 diff 范围之外发现的值得进行的重构；请在「结论」中记录。
• **规则：**不得改变行为。绝不修改测试来让重构通过。
• **先创建快照。**使用 git stash create（记录状态，不更改任何引用、索引或工作树），或将 diff 中的文件复制到别处。
• **重构后，运行完整测试套件。**如果通过，则保留重构。如果未通过，则将快照恢复到重构前通过测试时的状态，使工作树与重构前完全一致（对于 git stash create 快照，运行 git restore --source=<snapshot> --worktree -- <files>，这不会更改索引；此外，还要删除重构创建的任何文件，并重新创建重构删除的任何文件，因为快照不会覆盖这些内容），然后继续进行「审查」。

完成标准：保留重构且测试套件通过；或恢复到通过测试时的快照；或因测试套件未通过而跳过。

4. 审查

现在以真实的 Skill 调用方式调用 /review-axes 技能。将未暂存的工作树作为固定点传给它：这些更改尚未提交到任何提交中，因此基于引用的差异会是空的。同时，将你收到的工单路径作为 spec 参数传入；如果没有工单，则传入规范文件路径，这样它就不必搜索规范，并能同步正确的复选框。将验收标准复选框（- [ ] / - [x]）留在规范或工单中，由 /review-axes 在规范审查后根据代码的实际情况同步。

完成条件：本次运行中，/review-axes 已返回 Standards 和 Spec 报告。步骤 1 至 3 通过，是执行此步骤的前提，而不是替代：下面的 Verdict 基于审查输出，因此只有审查完成后才能撰写。

5. 提交

将你的工作提交到当前分支。

完成条件：本次运行的更改已提交到当前分支。

6. 报告

以 Verdict 部分结束。

Verdict

一行：表情符号，后接简短原因。🟢 这个表情符号单独使用，后面不附带文字。

• 🟢 一切按计划进行：已完整实现，没有偏离规范或工单，/review-axes 未提出任何需要处理的问题，无需用户采取行动。只输出表情符号。
• 🟡 已实现，但过程中有调整：计划逻辑发生变化、替换了方案、对规范细节作了解读，或 /review-axes 提出了值得关注的问题。同样使用 🟡：重构后测试套件失败，因此撤销了重构（用一句话说明），或在差异范围之外发现了值得进行的重构（建议创建一个前置重构工单，切勿直接实施）。保留的重构不影响颜色。如果因测试套件失败而跳过重构，请在 Verdict 中说明；测试套件失败本身也会像现在一样决定颜色。说明发生了什么变化及原因。
• 🔴 有内容未完成，或用户必须采取行动才能继续：有部分内容未实现，/review-axes 发现规范缺口，需要用户作出决定，需要凭据、迁移或手动步骤，或存在任何会妨碍用户“直接开始下一个工单”的情况。说明具体问题和用户需要采取的行动。

选择适用情况中最严重的颜色：只要符合任何红色条件，Verdict 就必须为 🔴，即使其他方面进展顺利。