ce-code-review

代码审查

帮助调用方在约定范围内交付正确的更改。找出后果足以采取行动的缺陷和改进；根据代码的预期行为和项目要求进行评判，而不是偏好某种重写方式。即使差异很小，严重缺陷仍然重要。足够完善的更改无需提出任何问题。

完成条件： 已完成必要的审查和验证，保留的问题均有源代码依据，并向调用方清楚说明结果及任何尚未覆盖的范围。只有在调用明确授权时才应用更改，并遵守以下规则。

工件根目录

在编写任何工件路径之前，先确定 CE 工件根目录 <root>。

• 读取 <repo-root>/.compound-engineering/config.yaml 中的 docs_root（<repo-root> = git rev-parse --show-toplevel）。不得从 config.local.yaml 读取。未设置时，<root> 精确默认为 docs，与之前相同。
• 验证已设置的值：它必须是相对于仓库的目录，其实际路径（解析符号链接后）必须仍位于仓库内，且不得是仓库根目录或位于 .git/ 下。否则，停止并给出错误，指出 docs_root 及其值——绝不可回退到 docs。
• 使用 <root> 作为唯一的工件位置：若目录不存在则创建；将每个路径拼接为 <root>/<subdir>，其中 <subdir> 为本技能自己的子目录；绝不同时读取 docs。

执行流程

按顺序执行以下步骤。参考资料提供详细信息，但绝不能改变顺序。进入每个步骤并开始该步骤所负责的工作时，再读取相应参考资料；提前读取不算满足要求。仅交给某个叶节点的参考资料，不算已由你读取。

1. 首先阅读 references/modes-and-output.md。该文件明确了参数、冲突、快速审查短路、Review 深度门槛，以及本次调用的返回内容。
2. 阶段 1。 阅读 references/scope.md，确定审查差异、范围模式和确定性范围信号。然后在进入阶段 2 前应用 Review 深度门槛。Lite 模式会结束本次运行，不再读取后续主干参考文件；Lite 和 focused 模式均依据 references/depth-paths.md 从当前上下文运行。
3. 阶段 2。 阅读 references/intent-and-plan.md，撰写每位审查者都会收到的意图摘要，并找出阶段 6 用于核验需求的计划。
4. 阶段 3。 阅读 references/persona-catalog.md 和 references/select-and-route.md，然后根据变更的风险选择所需的审查者，查找适用的标准文件，并决定如何进行对抗式审查。
5. 阶段 3d。 如果为本地审查树选择了对抗式审查，则必须在分派任何本地角色之前，启动并持久化 references/cross-model-review.md 定义的获准跨模型任务。调用此技能本身即表示授权使用其配置的或允许列表中的对等路由，但前提是你已按要求披露接收方以及将离开本机的代码。无需再次征求用户确认，也不要因为用户没有重复授权就跳过对等审查。用户明确禁止外部审查时，或检出内容设置了 cross_model_review_mode: off 且没有有效的主动授权时，均应以此为准；这两种情况都必须在绑定路由前解决。启动的对等审查会在此阶段替代本地对抗式角色；只有在范围界定、允许列表、连接、身份验证或启动方面确实失败时，才将本地备用审查者留在名单中；后续阶段仍可根据该参考文件规定的条件恢复本地审查者。
6. 阶段 4。 阅读 references/dispatch-reviewers.md。在本轮中，将选定的本地审查者作为一个并发批次分派，批次规模不得超过宿主当前的 Agent 上限。每次成功启动只有在拿到终止结果后才能收集：有效的精简返回会被采纳，工具错误或格式错误的输出会被记录为审查者失败，单独的启动确认不算结果。对于异步回执，在该参考文件规定的时限内使用宿主的阻塞式收集能力；超出时限仍未收集到的审查者视为失败。终止结果可能通过调用返回、阻塞等待返回，或宿主发送的终止消息抵达；该消息必须指明启动任务并携带其负载；进度更新不算终止结果。如果无法可靠地收集已启动的工作，则停止该工作；对于任何已持久化的对等任务（跨模型任务），在返回失败结果前，按其参考文件要求执行清理；绝不要在进度状态下结束本轮并等待结果。禁止将本地审查转为轮询式后台任务。跨模型对等任务是唯一允许脱离会话运行的工作，并且可以与此批次并行。
7. 阶段 5 和 6。 收到所有审查者的结果后，撰写 references/finish-input.md 定义的收尾输入，并遵循该参考文件：它规定了验证器的启动方式和运行产物列表。按顺序分派其中指定的两个叶子子 Agent，每个都以 references/finish-review.md 为种子；叶子会从磁盘读取该文件，不要自行打开：先启动合并叶子，将对等审查的发现纳入一次，并从运行目录合并；然后启动并收集所选验证器，再启动报告叶子来生成报告。两个叶子都不得启动子 Agent；所有子 Agent 均由你启动。将报告叶子的返回原样作为此技能的响应输出。绝不要直接根据原始审查产物自行合成报告，也不要在分派上下文中合并或生成报告。在多 Agent 流程中，只输出此技能的报告：不要另外调用宿主原生的发现或报告工具，这些工具仅适用于快速审查短路。

操作原则

• 默认仅报告；绝不推送。 直接调用 ce-code-review 只会生成发现，不会应用这些发现。只有指定 apply:local，或在调用提示词中明确要求应用或修复本次审查的发现，才会进入应用阶段；已弃用的 mode:autofix 标记不具备此作用。即使 mode:agent 嵌套在之后会应用发现的工作流中，也绝不会修改工作树。无论处于哪种模式，都绝不推送、创建 PR 或提交工单。
• 不发起阻塞式提问。 绝不使用 AskUserQuestion、request_user_input、ask_user 或其他阻塞式提问工具。根据明确标记、Git 状态、PR 元数据和对话内容推断意图、计划和范围。在 Coverage 或结论中注明不确定之处，不要停下来提问。
• 仅执行明确授权的修改。 绝不运行 gh pr checkout、git checkout、git switch 或类似的分支切换命令。提供 PR 编号、URL 或分支名称仅用于选择审查范围，不代表有权修改工作树。未提交的工作只能在包含这些改动的检出环境中审查；因此，要在功能分支上审查，就留在该分支（或自行检出），并传入 base: 或不指定目标。
• 报告结果，而非操作细节。 向用户展示的内容应围绕审查展开：审查对象、包含的覆盖范围、每个条件性审查角度的一句话理由、独立的跨模型审查，以及发现。提及用户能识别的对象，例如 PR 编号、审查者的关注点或同级模型。本技能的内部标签、任务分派记录和设置过程说明不得出现在面向用户的文本中。绝不要对同级模型作出超出其回执所能证实的陈述。这条原则规定的是哪些内容应展示或隐去，而非措辞；请使用你自己的表达方式。