code-review

name	code-review
description	多维度、Token 经济型代码审查。用于审查 diff / 分支 / PR，或任务提到"代码审查"、"review"、"找 bug"时使用。根据 diff 大小调整审查深度，按维度与严重度汇报发现。只汇报不修改代码，除非明确要求。

代码审查 (Code Review)

结构化的 Token 节约型审查流程。一次性覆盖所有相关维度，深度随 diff 大小自适应。

第 0 步——先确定审查范围

在读取任何代码前先确定变更范围：

• 分支 vs 基分支：git diff --stat main...HEAD（或指定的基分支）
• PR：gh pr diff <n> --patch、gh pr view <n>
• 指定文件：仅审查这些路径

统计变更文件数和净行数，选择路径：

Diff 大小	路径	行为
≤ 8 个文件且 ≤ 500 行	简略模式（默认）	单次集中审查 diff 及其直接调用方，结果内联汇报
更大或跨模块	完整模式	逐维度深入审查，发现写入文件以避免占用上下文

简略模式为默认——消耗约一个数量级更少的 token。仅当 diff 确实大或高风险（认证、数据库迁移、公共 API、并发）时才升级到完整模式。开头用一句话说明所选路径及原因。

审查维度

覆盖 diff 实际触及的所有维度。跳过无相关变更的维度，不要为了凑数而填充。

1. 正确性 — 逻辑错误、差一错误、null/undefined、未处理的边界情况、错误路径、对调用方的错误假设。
2. 安全性 — 注入、XSS、认证/授权缺陷、密钥泄露、路径遍历、SSRF、不安全的反序列化。如有发现，加载 security-review Skill 获取完整清单。
3. 性能 — N+1 查询、无界循环/分配、热路径上的阻塞调用、缺少分页/超时、内存泄露。
4. 架构 — 不当耦合、抽象泄露、职责归错层、不必要的复杂度。
5. 可维护性 — 命名、函数体量、魔法数字、死代码、重复逻辑、与周边代码库的风格偏离。
6. 文档与注释 — AI 模板注释（复述代码）、注释掉的死代码、解释 WHAT 而非 WHY 的注释、过时的文档说明。
7. 兼容性 — 破坏性 API/签名变更、改变的公共契约、默认值变更、数据库/Schema 迁移、未更新的调用方。

严重度分级

• critical（致命）— 数据丢失、安全漏洞、崩溃、核心行为破坏。合并前必须修复。
• major（严重）— 真实 bug 或合理输入下的退化；错误结果。
• minor（轻微）— 影响极窄的 bug、薄弱的错误处理、明显坏味道。
• nit（吹毛求疵）— 风格/命名/注释优化。仅当积累成可维护性问题才报告，否则省略。

项目上下文校准

分配严重度前检查：项目版本阶段（package.json version——v0.x → 降低 API 稳定性严重度）、部署模式（localhost 工具 → 降低认证/网络发现严重度）、仓库可见性（私有 → 密钥泄露降为 warning）。

严重度纠正（防止膨胀）

• 在分配严重度前阅读项目现有约定（AGENTS.md、CLAUDE.md、GEMINI.md）。
• 对不适用本项目实际情况的发现降级，注明校准原因。
• 宁可只有一个准确的高严重度发现，也不要十个被夸大的。每次虚假警报都会侵蚀整个审查的可信度。
• 对调用方明确声明的设计选择（"我们有意选择 X"）不标注为发现——那是设计决策，不是问题。

自我质疑检查（输出前）

在写下任何发现前，无声运行以下对抗检查：

1. 我能推翻它吗？ 构建反向论证。"这没问题因为……第 N 行的错误处理器已经覆盖了。"如果反驳比发现更强，丢弃。
2. 严重度有没有膨胀？ 在第二个审查者审视下能站住脚吗？如果必须费力论证"critical"，就别标。不确定时降一级。
3. 这是真问题还是个人偏好？"这个变量名可以更优"不算发现，除非真的导致误解。

以下情形立即否决发现：

• 引用的 file:line 有误或代码实际不在 diff 影响范围内。
• 针对此 diff 未触碰的已有代码（最多作为上下文备注，不是审查项）。
• 严重度相对于项目威胁模型被夸大。
• 项目未强制要求的纯设计/风格观点。
• 重复了另一个发现——合并，不重复列。
• 是记录在案的故意设计决策。

只输出幸存于全部三项问题和所有否决规则的发现。

输出格式

开头一行严重度汇总：critical: N | major: N | minor: N | nit: N 和所选路径（简略/完整）。

随后按严重度降序列出发现，格式如下：

[severity] <标题>  (维度)
location: path/to/file.ext:LINE
issue:  <出了什么问题，以及触发它的输入/条件>
impact: <破坏了什么，或攻击者/用户获得了什么>
fix:    <最小化的具体修复方案，可交由 flash 代理直接执行>

末尾附简短总体评估（可合并？有阻断项？）。如果变更确实干净，直说——不要为了看起来有产出而制造发现。

大审查——通过文件通信

完整模式下，将发现写入文件（如 .gemini/review-<short-ref>.md），向调用方仅返回严重度汇总 + 文件路径。保持大审查内容在调用方上下文之外。

审查→修复循环

被要求审查并修复时，运行有界循环：

1. 审查当前 diff。
2. 无 findings 高于 nit → 停止，报告干净。
3. 对 critical / major 发现应用最小修复（以及能干净解决的 minor）。
4. 验证：运行项目的 format/lint/test 命令。优先从 GEMINI.md 发现，其次从仓库推断（package.json scripts、Makefile 等）。
5. 仅对变更区域重新审查。重复。

停止条件：干净（无非 nit 发现）、最多 5 轮、或收敛。在迭代 2+ 时，前置一个 ## 前一轮发现 块列出上一轮发现。除非是 REGRESSION，不重复报告已有发现。

规则

• 发现以文本汇报；不修改代码，除非任务明确要求修复。
• 先审查 diff 及其直接爆炸半径；仅在发现指向别处时才扩大范围。
• 引用具体 file:line 位置。"第 42 行差一错误因为……"优于"这看起来不对"。
• 只做诚实评估——不做表演式肯定，不夸大。