---
name: code-review
description: 审查当前差异以查找正确性错误和可重用/简化/效率清理问题，在给定的工作量水平上（低/中：更少、更高置信度的发现；高→最大：更广泛的覆盖，可能包含不确定的发现；ultra：云端深度多代理审查）。传入 --comment 将发现作为内联 PR 评论发布，或传入 --fix 在审查后将发现应用到工作树。
---

`高工作量 → 3+5 个角度 × 6 个候选 → 1 票验证（偏重召回）→ ≤10 个发现`

你正在以高工作量审查**召回**：捕捉一个仔细的审查员在一次审查中会捕捉的每一个真实错误。在这个级别上，捕捉真实错误比避免误报更重要。宁可多报告。

## 阶段 0 — 收集差异

运行 `git diff @{upstream}...HEAD`（或 `git diff main...HEAD` / `git diff HEAD~1` 如果没有上游）以获取待审查的统一差异。如果有未提交的变更，或范围差异为空，也运行 `git diff HEAD` 并将工作树变更纳入范围——审查通常在提交前运行。如果传入了 PR 编号、分支名称或文件路径作为参数，改为审查该目标。将此差异视为审查范围。

## 阶段 1 — 查找候选（3 个正确性角度 + 3 个清理角度 + 1 个高层级角度 + 1 个约定角度，每个最多 6 个）

通过 Agent 工具运行 **8 个独立的查找角度**。每个报告**最多 6 个候选发现**，包含 `file`、`line`、单行 `summary` 和具体的 `failure_scenario`。

### 角度 A — 逐行差异扫描

逐行阅读差异中的每个片段。然后为每个片段阅读其所在的函数——被触及函数中未改变行中的错误也在范围内（PR 重新暴露或未能修复它们）。对每一行问：什么输入、状态、时序或平台使此行错误？查找反转/错误的条件、差一错误、空/未定义解引用、缺少 `await`、假零检查、错误的变量复制粘贴、catch 中吞噬的错误、未转义的正则表达式元字符。

### 角度 B — 已删除行为审查器

对于差异删除或替换的每一行，指出它强制执行了什么不变量或行为，然后在新代码中搜索该不变量在哪里被重新建立。如果找不到，那就是一个候选：一个被移除的守卫、一个被丢弃的错误路径、一个被缩窄的验证、一个覆盖了真实情况的被删除测试。

### 角度 C — 跨文件追踪器

对于差异变更的每个函数，找到其调用者（Grep 搜索符号）并检查变更是否破坏了任何调用点：新的前置条件、改变的返回形状、新的异常、时序/排序依赖。同时检查被调用者：同一 PR 中的并行变更是否使调用变得不安全？

### 重用

以上角度寻找错误；此角度和接下来的两个在已变更代码中寻找清理问题。标记重新实现了代码库中已有功能的新代码——在共享/实用模块和与变更相邻的文件中搜索，并指出应改为调用的现有辅助函数。

### 简化

标记差异增加的不必要复杂性：冗余或可推导的状态、带有轻微变化的复制粘贴、深层嵌套、遗留的死代码。指出做相同工作的更简单形式。

### 效率

标记差异引入的浪费工作：冗余计算或重复 I/O、顺序运行的独立操作、添加到启动或热路径上的阻塞工作。同时标记由闭包或捕获环境构建的长生命周期对象——它们在对象的整个生命周期内保持整个外围作用域存活（当该作用域持有大值时会导致内存泄漏）；优先使用仅复制所需字段的类/结构体。指出更便宜的替代方案。

### 高层级

检查每个变更是否在正确的深度实现，而不是作为一个脆弱的创可贴。在共享基础设施上叠加特殊情况是修复不够深入的信号——优先泛化底层机制，而非添加特殊情况。

### 约定（CLAUDE.md）

找到约束已变更代码的 CLAUDE.md 文件：用户级 ~/.claude/CLAUDE.md、仓库根 CLAUDE.md，以及变更文件祖先目录中的任何 CLAUDE.md 或 CLAUDE.local.md（目录的 CLAUDE.md 仅适用于该目录及以下的文件）。阅读每个存在的文件，然后检查差异中明显违反它们所规定规则的地方。

仅在你能够引用确切的规则和确切违规行时才标记违规——不涉及风格偏好、不涉及模糊的"文档精神"推断。在发现中，命名 CLAUDE.md 路径并引用规则，使报告可以引用它。如果没有适用的 CLAUDE.md，此角度返回空。

清理、高层级和约定候选使用相同的 `file`/`line`/`summary` 格式；在 `failure_scenario` 中，陈述具体成本（什么被重复、浪费、更难维护，或违反了哪条 CLAUDE.md 规则）而非崩溃。当输出上限强制截断时，正确性错误始终优先于清理、高层级和约定发现。

将所有具有可命名故障场景的候选提交——静默丢弃半信半疑候选的查找器绕过了验证步骤，是遗漏的主要致因。

## 阶段 2 — 验证（1 票，偏重召回）

对近似重复的候选进行去重（相同缺陷、相同位置、相同原因 → 保留一个）。对于每个剩余候选，通过 Agent 工具运行**一个验证器**：给它差异、相关文件和候选；它精确返回 **CONFIRMED / PLAUSIBLE / REFUTED** 之一。

**默认 PLAUSIBLE** — 不要因为候选是"推测性的"或"依赖于运行时状态"而反驳它，当该状态是现实的：并发竞态、罕见但可到达路径上的 nil/undefined（错误处理程序、冷缓存、缺失可选字段）、假零被视为缺失、代码未排除的边界上的差一错误、重试风暴 / 部分故障、丢失锚点的正则表达式/允许列表。这些是 PLAUSIBLE。

**REFUTED** 仅当可从代码构建证据时：事实上错误（引用实际行）；可证明不可能（类型/常量/不变量——展示它）；已在此差异中处理（引用守卫）；或纯风格，无可观察效果。

保留 **CONFIRMED 和 PLAUSIBLE**。丢弃 REFUTED。

## 输出

将发现返回为最多 10 个对象的 JSON 数组：

```json
[
  {
    "file": "path/to/file.ext",
    "line": 123,
    "summary": "一句话陈述错误",
    "failure_scenario": "具体输入/状态 → 错误输出/崩溃"
  }
]
```

按严重程度从高到低排序。如果超过 10 个幸存，保留最严重的 10 个。如果验证后无发现幸存，返回 `[]`。
