| 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 实际触及的所有维度。跳过无相关变更的维度，不要为了凑数而填充。
- 正确性 — 逻辑错误、差一错误、null/undefined、未处理的边界情况、错误路径、对调用方的错误假设。
- 安全性 — 注入、XSS、认证/授权缺陷、密钥泄露、路径遍历、SSRF、不安全的反序列化。如有发现，加载
security-review Skill 获取完整清单。
- 性能 — N+1 查询、无界循环/分配、热路径上的阻塞调用、缺少分页/超时、内存泄露。
- 架构 — 不当耦合、抽象泄露、职责归错层、不必要的复杂度。
- 可维护性 — 命名、函数体量、魔法数字、死代码、重复逻辑、与周边代码库的风格偏离。
- 文档与注释 — AI 模板注释（复述代码）、注释掉的死代码、解释 WHAT 而非 WHY 的注释、过时的文档说明。
- 兼容性 — 破坏性 API/签名变更、改变的公共契约、默认值变更、数据库/Schema 迁移、未更新的调用方。
严重度分级
- critical（致命）— 数据丢失、安全漏洞、崩溃、核心行为破坏。合并前必须修复。
- major（严重）— 真实 bug 或合理输入下的退化；错误结果。
- minor（轻微）— 影响极窄的 bug、薄弱的错误处理、明显坏味道。
- nit（吹毛求疵）— 风格/命名/注释优化。仅当积累成可维护性问题才报告，否则省略。
项目上下文校准
分配严重度前检查：项目版本阶段（package.json version——v0.x → 降低 API 稳定性严重度）、部署模式（localhost 工具 → 降低认证/网络发现严重度）、仓库可见性（私有 → 密钥泄露降为 warning）。
严重度纠正（防止膨胀）
- 在分配严重度前阅读项目现有约定（
AGENTS.md、CLAUDE.md、GEMINI.md）。
- 对不适用本项目实际情况的发现降级，注明校准原因。
- 宁可只有一个准确的高严重度发现，也不要十个被夸大的。每次虚假警报都会侵蚀整个审查的可信度。
- 对调用方明确声明的设计选择（"我们有意选择 X"）不标注为发现——那是设计决策，不是问题。
自我质疑检查（输出前）
在写下任何发现前，无声运行以下对抗检查：
- 我能推翻它吗？ 构建反向论证。"这没问题因为……第 N 行的错误处理器已经覆盖了。"如果反驳比发现更强，丢弃。
- 严重度有没有膨胀？ 在第二个审查者审视下能站住脚吗？如果必须费力论证"critical"，就别标。不确定时降一级。
- 这是真问题还是个人偏好？"这个变量名可以更优"不算发现，除非真的导致误解。
以下情形立即否决发现：
- 引用的
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），向调用方仅返回严重度汇总 + 文件路径。保持大审查内容在调用方上下文之外。
审查→修复循环
被要求审查并修复时，运行有界循环：
- 审查当前 diff。
- 无 findings 高于
nit → 停止，报告干净。
- 对
critical / major 发现应用最小修复（以及能干净解决的 minor）。
- 验证：运行项目的 format/lint/test 命令。优先从
GEMINI.md 发现，其次从仓库推断（package.json scripts、Makefile 等）。
- 仅对变更区域重新审查。重复。
停止条件：干净（无非 nit 发现）、最多 5 轮、或收敛。在迭代 2+ 时，前置一个 ## 前一轮发现 块列出上一轮发现。除非是 REGRESSION，不重复报告已有发现。
规则
- 发现以文本汇报；不修改代码，除非任务明确要求修复。
- 先审查 diff 及其直接爆炸半径；仅在发现指向别处时才扩大范围。
- 引用具体
file:line 位置。"第 42 行差一错误因为……"优于"这看起来不对"。
- 只做诚实评估——不做表演式肯定，不夸大。
