用途
code-review 用于分析代码变更，检查正确性、安全性、边界情况和代码质量，并以结构化方式返回发现项（Finding schema v1）。它适合以下场景：
- 审查代码变更（暂存、未暂存或特定提交）
- 审查特定文件或文件集合
- 对 PR 或分支进行快速结构化审查
如果需要带对抗性验证的完整两遍审查，应改用 /two-pass-review。
主要能力
- 按 P0-P3 对发现项进行严重性分级
- 为每个发现项提供 0.0-1.0 的置信度分数
- 标注所违反的具体标准（criterion）
- 记录已执行的检查（checks_run），包括文件、标准和 lint/类型检查结果
- 未发现问题时返回空的 findings 数组，不制造问题
使用方式
1. 收集审查对象
确定要审查的内容：
- 用户指定了文件：读取这些文件
- 用户指定了 diff 范围：运行 git diff <range>
- 否则：运行 git status 和 git diff 查看当前变更
对于修改过的文件，审查其 diff；对于未跟踪的文件，读取完整内容；对于已删除的文件，检查是否存在损坏的引用。
如果需要相关文件作为上下文（类型、接口、调用方），也应一并读取。
如果范围不明确（未指定文件、无 diff 范围，或 diff 跨越许多不相关文件），使用 AskUserQuestion 工具确认要审查的内容后再继续。展示检测到的文件/变更，询问是审查全部还是缩小到子集。
2. 自动化检查
如果项目支持：
- 读取 package.json 检查可用脚本
- 如果存在 lint 脚本，运行它
- 如果存在 tsconfig.json，运行 npx tsc --noEmit
- 将任何失败记为 P0/P1 发现项
3. 分析
审查代码的以下方面：
- 正确性——代码是否实现了预期功能？
- 安全性——注入、未授权访问、数据暴露？
- 边界情况——未处理的场景、边界条件？
- Bug——明显错误、差一错误、空引用？
- 性能——低效模式（仅在有事证时才标记）？
不要标记：风格偏好、命名意见、没有事证的理论风险，或你会用不同方式写但并非错误的内容。
4. 返回发现项
返回符合下方输出 Schema 的 ReviewOutput 信封。
- 将所有发现项的 verdict 和 evidence 设为 null
- 包含诚实的置信度分数——1.0 表示确定，低于 0.5 表示在猜测
- 在 checks_run 中填充所评估的内容（文件、标准、lint/类型检查结果）
- 如果未发现问题，返回空的 findings 数组——不要制造问题
约束
- 不实施修复。除非明确要求，否则不要实现修复。
- 只报告。将发现项呈现给用户审查。
输出 Schema
Finding
Finding {
id: sequential number starting from 1,
severity: "P0" | "P1" | "P2" | "P3",
title: short title,
body: detailed explanation with evidence,
file: file path or null for global issues,
line_start: number or null,
line_end: number or null,
confidence: 0.0-1.0,
criterion: what was violated,
verdict: "confirmed" | "demoted" | "rejected" | null,
evidence: reasoning for verdict | null
}
ReviewOutput
发现项包裹在 ReviewOutput 信封中：
ReviewOutput {
schema_version: "v1",
findings: Finding[],
checks_run: string[]
}
严重性分级
- P0——必须修复：破坏功能、安全漏洞、数据丢失，或违反标准
- P1——发布前修复：正确但不完整、脆弱，或存在可靠性风险
- P2——应当修复：质量问题、代码异味，不阻塞
- P3——锦上添花：观察、风格、次要改进
字段说明
- confidence——1.0 表示确定，低于 0.5 表示在猜测。要诚实。
- criterion——P0/P1 发现项必填。写明所违反的具体标准。
- verdict——由两遍审查中的验证器填充。直接产出发现项时设为 null。
- evidence——验证器对 verdict 的推理。直接产出发现项时设为 null。
- checks_run——列出所评估的每个标准、检查的文件路径或验证的验收标准。对于 AC，使用 AC-N: PASS — [evidence] 或 AC-N: FAIL — [reason]。
适用场景与限制
适用于对代码变更、PR、分支或特定文件进行快速结构化审查，输出可读的分级发现项。限制包括：不实施修复，只报告；不标记风格偏好、命名意见或无证据的理论风险；性能问题仅在有事证时才标记；两遍对抗性验证需使用 /two-pass-review。