| name | code-review |
| description | 多维度代码审查（正确性、安全、性能、架构、可维护性、文档、兼容性）。审查 diff/分支/PR 时使用，也可用于审查→修复循环。按 diff 大小自适应深度，按项目上下文校准严重度。只报告不擅自改代码（除非明确要求修复）。 |
| paths | ["**/*.ts","**/*.tsx","**/*.js","**/*.jsx","**/*.py","**/*.go","**/*.rs","**/*.java","**/*.kt","**/*.swift"] |
| priority | medium |
代码审查
结构化的多维度审查规程。一个审查员一次覆盖所有维度，深度随 diff 大小自适应。
第 0 步 — 确定审查范围
先确定变更集和大小再读代码：
- 分支 vs 基：
git diff --stat main...HEAD（或指定的基分支）
- PR：用
gh pr diff <n> --patch，gh pr view <n>
- 指定文件：只看那些路径
统计变更文件数和净变更行数。选择审查路径：
| Diff 大小 | 路径 | 行为 |
|---|
| ≤ 8 文件且 ≤ 500 行 | 精简（默认） | 单次聚焦 pass，直接内联报告。 |
| 更大或跨切面 | 完整 | 逐维度 walk，发现写入文件。 |
精简是默认值，成本约低一个数量级。仅在 diff 确实大或高风险（认证、迁移、公开 API、并发）
时升级到完整。用一行说明选择了哪条路径及原因。
审查维度
覆盖 diff 实际触及的每个维度。未涉及的维度直接跳过，不填充报告。
- 正确性 — 逻辑错误、差一错误、null/undefined、未处理边界情况、错误路径、
对调用方的不正确假设。
- 安全 — 注入、XSS、认证/授权缺口、密钥、路径穿越、SSRF、不安全反序列化。
若涉及任一，加载
security-review 技能做完整检查清单。
- 性能 — N+1 查询、无界循环/分配、热路径上的阻塞调用、缺分页/超时、泄漏。
- 架构 — 不当耦合、泄漏抽象、责任错层、不必要的复杂度。
- 可维护性 — 命名、函数长度、魔法数字、死代码、重复逻辑、与代码库风格偏离。
- 文档与注释 — AI 样板注释（复述代码）、注释掉的代码、解释 WHAT 而非 WHY 的注释、
过时的文档声明。执行注释纪律。
- 兼容性 — 破坏性 API/签名变更、公开契约变更、默认值变更、数据库/模式迁移、
未更新的调用方。
报告前静默验证：从头到尾读每个变更文件；检查未使用的导入、遗留 TODO、调试打印；
确认新增/修改的函数有调用方。
严重度
- critical — 数据丢失、安全漏洞、崩溃、核心行为破坏。合并前必须修复。
- major — 合理输入下的真实 bug 或回归；错误结果。
- minor — 影响面窄的 bug、弱错误处理、明显坏味道。
- nit — 风格/命名/注释润色。仅当累积成可维护性问题时报告，否则省略。
项目上下文校准
指定严重度前检查：项目版本阶段（package.json version — v0.x → API 稳定性严重度降级）、
部署模式（localhost → 认证/网络类发现降级）、仓库可见性（私有 → 密钥暴露降级为 warning）。
抑制已知设计噪音
若调用方提供了决策/上下文说明——内联（"我们故意选了 X"）、.qwen/decisions.md 路径、
或 QWEN.md/AGENTS.md 中记录的约束——将这些选择视为故意的，不作为发现报告。
仅在 diff 本身使已记录的选项变得具体不安全时（如：曾假定可信输入的决策现在暴露给
不可信路径）才告警。
自我怀疑检查（输出前）
为每个发现无声运行三次检查。默认拒绝——发现只有经得起审视才值得记录：
- 我能推翻这个吗？ 构建反驳："这里没问题因为……第 N 行的错误处理器已经覆盖了它 /
只在管理路径触发 / 输入在上游第 M 行已验证。"若反驳强于发现，舍弃。
- 严重度膨胀了吗？ 若需勉强才能论证"critical"，就不是 critical。不确定时降一级。
- 真实问题还是个人偏好？ "这个变量名可以更好"若不是造成真实混淆就不是发现。
立即拒绝满足以下任一条件的发现：
- 引用的
file:line 错误或代码不在 diff 影响范围内。
- 针对 diff 未触及的已有旧代码（最多作为上下文备注——不是本次变更的审查项）。
- 严重度相对项目威胁模型膨胀（见上文校准）。
- 纯设计/风格观点，项目未强制。
- 与另一发现重复——合并，不列两遍。
- 已记录的故意决策（见抑制规则）。
只有通过全部三个问题和所有拒绝规则的发现才能输出。
审查→修复循环
被要求审查并修复时，运行有界循环：
- 审查当前 diff（范围 + 维度 + 严重度如上）。
- 若无 nit 以上发现——停止，报告干净。
- 对 critical/major 发现做最小修复（以及明显的 minor）。遵循 QWEN.md；改动精准。
- 验证：运行项目的格式化/lint/测试命令。先从
QWEN.md 发现，再从仓库推断
（package.json scripts、Makefile 等）。若无，说明跳过验证。
- 仅对变更区域重新审查。重复。
停止条件：干净（无 nit 以上发现）、最多 5 轮、或收敛。将每轮重新审查的
发现分类为 NEW（新增）、RECURRING（上轮未解决）、或 REGRESSION（修复过程中重新引入）。
仅当一轮产生 nit 以上 NEW 或 REGRESSION 发现时继续循环；一旦一轮零此类发现，停止并
将剩余 RECURRING 发现交给人类处理。
报告格式
以一行严重度摘要开头：critical: N | major: N | minor: N | nit: N 和审查路径（精简/完整）。
然后逐条列出发现，按严重度排序，每条：
[severity] <标题> (维度)
<!-- id: <12-char-hash> -->
location: path/to/file.ext:LINE
issue: <哪里错了以及触发条件>
impact: <破坏了什么，或攻击者/用户获得了什么>
fix: <flash 模型能执行的最小具体修复>
以简短总体评估结尾（可合并？有阻塞项？）。变更确实干净时直说——不制造发现。
文档漂移批处理
非 critical 的文档发现统一归入 ## 文档漂移 小节做清单，不散落报告各处。
大审查——通过文件通信
完整路径时，把发现块写入文件（如 .qwen/review-<short-ref>.md），只返回严重度摘要加
文件路径给调用方。这样大审查内容不占用上下文。
规则
- 发现以文本报告；不修改代码，除非明确要求修复（循环模式）。
- 先审查 diff 及直接波及范围；仅当发现指向别处时才扩大。
- 遵守 QWEN.md——特别是质量基线和注释纪律。
- 引用具体
file:line 位置。
- 只做诚实评估——不做敷衍的正面评价，不做人为膨胀。
