TomorrowLM 请求代码审查
派遣 CodeReview 子代理在问题扩散前发现代码问题。审查者获得的是精心组织的评估上下文，而非完整的会话历史。核心原则：早审查，勤审查。
何时请求审查
必须审查：
- 子代理驱动开发中每个任务完成后
- 完成重要功能后
- 合并到 main 之前
可选但有价值：
- 卡住时（换个视角）
- 重构之前（建立基线）
- 修复复杂 bug 之后
审查模式
在开始审查前执行环境探测，根据结果选择模式。
环境探测
| 步骤 | 操作 | 说明 |
|---|---|---|
| 1. 探测终端 | 执行 npx gitnexus analyze --index-only，失败后基于工具返回结果重试一次 |
确认终端可用；同时刷新索引 |
| 2. 探测 MCP | 检查 GitNexus MCP 工具列表中是否有 detect_changes |
确认完整审查能力是否就绪 |
| 3. 确认附件 | 检查用户是否提供了附件文件（粘贴代码、拖拽文件等） | 作为模式 C 的判断依据。若降级后仍无附件，先询问审查范围 |
模式选择
| 模式 | 条件 | 审查方式 |
|---|---|---|
| A. 完整审查 | 终端可用 + GitNexus MCP 可用 | git diff + GitNexus 影响分析 + CodeReview 子代理 |
| B. diff 审查 | 终端可用 + GitNexus MCP 不可用 | git diff + CodeReview 子代理（无影响分析） |
| C. 附件审查 | 终端不可用（重试后确认）+ 用户提供了附件 | 静态走读。开头声明「本次审查为附件静态走读，未执行 git diff 和 GitNexus 影响分析」，不输出影响范围章节 |
审查流程
0. 前置上下文检查（仅模式 A/B）
确认变更范围、需求或审查重点可用；必要时补充代码上下文、调用关系和影响面数据。已有测试、类型检查或构建结果可以作为上下文，但仅用于确认审查输入可用，不构成代码审查通过、生产就绪或可合并结论，也不要为代码审查重复启动 verification-before-completion。
1. 获取变更范围
模式 A/B：
BASE_SHA=$(git rev-parse HEAD~1) # 或 origin/main
HEAD_SHA=$(git rev-parse HEAD)
模式 C： 跳过，直接使用附件文件作为审查范围。
2. 收集影响数据（仅模式 A，主会话执行）
子代理无法调用 MCP 工具。主会话完成所有 MCP 调用，结果以文本注入子代理 prompt。
| 步骤 | 操作 | 说明 |
|---|---|---|
| 刷新索引 | npx gitnexus analyze --index-only |
环境探测已执行则跳过，否则单独执行 |
| 确认仓库 | MCP gitnexus.list_repos |
确认索引就绪 |
| 变更影响 | MCP gitnexus.detect_changes |
获取变更符号、受影响流程、风险等级 |
| 深入分析 | 对高风险符号调 gitnexus.impact |
获取 d=1~3 调用链 |
| 补充上下文 | 对关键符号调 gitnexus.context |
获取完整调用关系 |
所有结果收集为文本，作为 {GITNEXUS_DATA} 注入。
3. 派遣 code-reviewer 子代理
若当前环境没有可用的 CodeReview / code-reviewer 子代理，不要假装已审查；暂停并说明缺少专用审查代理，询问用户是否改用当前可用的通用子代理执行同等审查。
使用 CodeReview 子代理，将 code-reviewer.md 模板填入 prompt。占位符按模式注入：
| 占位符 | 说明 | 模式 A | 模式 B | 模式 C |
|---|---|---|---|---|
{WHAT_WAS_IMPLEMENTED} |
刚完成的内容 | ✅ | ✅ | ✅ |
{PLAN_OR_REQUIREMENTS} |
预期功能。无正式计划填"无正式计划，审查重点放在代码质量、架构合理性和明显 bug" | ✅ | ✅ | ✅ |
{BASE_SHA} / {HEAD_SHA} |
起始/结束提交 | ✅ | ✅ | ❌ |
{DESCRIPTION} |
简要说明 | ✅ | ✅ | ✅ |
{GITNEXUS_DATA} |
影响分析结果 | 实际数据 | "无 GitNexus 数据" | 不填 |
4. 处理反馈
- Critical：标记为必须修复 → 交给实现流程修复 → 重新运行原始复现和受影响验证 → delta review
- Important：标记为继续前必须修复 → 交给实现流程修复 → 重新运行受影响验证 → delta review
- Minor：仅记录
// TODO(review): <描述>，由实现流程或维护人后续处理，每 5 个任务或每批次结束时集中清理 - Suggestion：作为可选改进记录，不阻断当前流程
- 审查者有误：用技术理由反驳，展示证明代码/测试
5. Delta Review
修复 Critical/Important 后执行轻量级重审，确认修复到位：
1. 获取修复 diff: BASE_SHA=$(git rev-parse HEAD~N) / HEAD_SHA=$(git rev-parse HEAD)
2. 派遣同一子代理：
WHAT_WAS_IMPLEMENTED: 针对审查反馈的修复
PLAN_OR_REQUIREMENTS: 上一轮 Critical/Important 问题列表
DESCRIPTION: 修复了 N 个问题：[简要列出]
3. 在修复后的验证完成后，子代理复查修复 diff 及其直接关联影响，包括直接调用方、相关执行流和受影响契约，确认原始问题已解决 + 无新问题
返回: PASS（可继续）/ FAIL（需再修）
FAIL 处理： 第 1 次 → 修复重试 | 第 2 次 → 回退完整审查 | 第 3 次 → 暂停并请求指导
只有 Minor 则无需 delta review。
将审查结果交给上层流程；修复实现、最终验证和完成声明不属于代码审查职责，由对应流程负责。
职责边界
代码审查负责：
- 分析代码变更的正确性、安全性、架构和可维护性；
- 检查接口契约、调用关系、影响面和需求一致性；
- 输出问题、证据、风险等级和修改建议；
- 对 Critical 或 Important 修复执行 Delta Review。
代码审查不负责：
- 复现运行时故障或完成根因调查；
- 直接实现修复代码或补测试；
- 执行最终全量验证、验收或发布判断；
- 宣称任务已完成。
HARD-GATE
以下规则无例外，即使用户说"很简单"、"别折腾了"、"直接手动"、"跳过"或"紧急"：
- 不因"简单"跳过审查 — 一行文案、一个变量名、一个 CSS 属性，都不绕过
- Critical 必须修复 — 修复后 delta review 确认，降级为 Minor 才可记录 TODO 延后
- 工具失败必须重试 — 终端/MCP 偶发失败时，根据工具返回结果重试 1 次再判定降级；"别折腾了"不绕过
- 无子代理不假装 — 缺少 CodeReview / code-reviewer 子代理时暂停并说明，不用通用子代理冒充
"用户明确指令优先于 skill 规则"不适用于以上四条。
红线
绝不要：
- 因为"很简单"就跳过审查
- 忽略 Critical 问题或带着未修复的 Important 继续推进
- 对合理技术反馈进行争辩
- 因工具偶发失败直接降级 — 必须根据工具返回结果重试 1 次再判定
- 在没有 CodeReview / code-reviewer 子代理时假装完成了子代理审查
如果审查者有误： 用技术理由反驳，展示证明其可行的代码/测试，要求澄清。
审查输出示例参见：references/examples/review-output.md