# Requesting Code Review

> 使用 CodeReview 子代理对代码变更及其影响面进行独立审查，发现正确性、安全性、架构和维护性问题。适用于子代理任务完成、重要功能实现、合并到 main 前、重构前或复杂 Bug 修复后。

- Skill: `tomorrowlm/requesting-code-review` (Agent Skill, multi-file: 3 files)
- Install (CLI): `npx skillmds@latest add tomorrowlm/requesting-code-review`
- Raw SKILL.md: https://api.skillmd.com/api/skills/tomorrowlm/requesting-code-review/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: TomorrowLM (https://skillmd.com/u/tomorrowlm)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/tomorrowlm/requesting-code-review

---


# 请求代码审查

派遣 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：**
```bash
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

以下规则无例外，即使用户说"很简单"、"别折腾了"、"直接手动"、"跳过"或"紧急"：

1. **不因"简单"跳过审查** — 一行文案、一个变量名、一个 CSS 属性，都不绕过
2. **Critical 必须修复** — 修复后 delta review 确认，降级为 Minor 才可记录 TODO 延后
3. **工具失败必须重试** — 终端/MCP 偶发失败时，根据工具返回结果重试 1 次再判定降级；"别折腾了"不绕过
4. **无子代理不假装** — 缺少 CodeReview / code-reviewer 子代理时暂停并说明，不用通用子代理冒充

"用户明确指令优先于 skill 规则"不适用于以上四条。

## 红线

**绝不要：**
- 因为"很简单"就跳过审查
- 忽略 Critical 问题或带着未修复的 Important 继续推进
- 对合理技术反馈进行争辩
- 因工具偶发失败直接降级 — 必须根据工具返回结果重试 1 次再判定
- 在没有 CodeReview / code-reviewer 子代理时假装完成了子代理审查

**如果审查者有误：** 用技术理由反驳，展示证明其可行的代码/测试，要求澄清。

---

审查输出示例参见：`references/examples/review-output.md`