代码审查
范围
执行一次有边界的独立实现审查。这不是一个针对每个任务的审查流水线，并且绝不允许根据风险、难度或变更规模自动启动。
触发
唯一的触发条件是用户明确请求进行实现审查。安全影响、兼容性风险、复杂性、文件数量、代码行数或智能体自身的置信度绝不可替代该请求。若无此请求，则返回根智能体的正常工作，无需调用此技能。
审查循环
- 根智能体从对话、计划和当前的 Git 证据中确定确切的任务需求和审查范围。
- 为第一轮审查启动一个全新的审查智能体。向其提供需求、范围、差异（diff）或提交（commit）证据以及审查标准。该审查智能体必须为只读模式，且不得将任务委派给其他智能体。
- 第一轮是对所请求的实现范围进行完整审查。首先按严重程度排序报告发现的问题，并基于具体的文件和代码行。
- 如需修复，则由根智能体负责修复、集成和测试。
- 在阻塞性问题修复完成后，启动一个新的审查智能体，针对这些修复及其附近的回归问题进行有范围的二次审查。同时需包含之前的审查发现和本次修复的范围。
- 绝不开始第三轮审查。若存在未解决的关键或主要发现，则将其列为阻塞性问题进行报告，不得声称审查完成。
轻微的观察结果可以与通过结论一同附带。即使审查者对整体结论的标注不一致，关键或主要发现仍会阻塞通过结论。
审查交接
记录审查轮次、范围、审查范围、结论以及阻塞性问题。然后将控制权交还给根智能体。