review

/review

工作流

1. 获取实际范围，绝不自行重构范围：检查提供的 diff；否则检查 git diff main...HEAD、git diff --cached、git diff 和 git status --short。默认包括 已跟踪的未提交工作。如果存在未跟踪文件，询问用户是否要纳入审查；说明哪些部分可供审查。
2. 先阅读变更的测试以及 CI/配置，再阅读实现。没有充分理由就重写测试以改变行为，或无正当理由放宽门槛，均属阻断项。
3. 提供结构化审查，说明风险、影响范围以及可用的测试/验证证据。变更代码有明显的调用方、依赖方或公共接口时，建议检查这些部分及其相关测试；不要把每次审查都变成调用链考古。
4. 提出不超过 5 个追问式问题——每个关键设计决策一个；只问设计意图，不问风格。
5. 用户批准具体修复后：应用修复 → 运行相关测试和 lint → 暂停并追问用户尚未解决的设计或验证问题 → 提交前明确征求批准。

范围纪律

只审查变更内容——绝不将既有且未修改的代码报告为问题。diff 是审查依据，但并非唯一上下文：必要时阅读变更文件，或明显的调用方、依赖方、相关测试，以判断变更代码的影响。真实代码库中必须严格遵守这条规则：

发现项只针对变更代码。利用周边代码理解影响；不要把审查变成既有问题的待办清单。

推送前安全审查

对于即将推送的内容，在发布前对分支自身的变更进行安全审查（可选：使用 trivy fs 检查有漏洞的依赖）。重点关注：日志中记录的密钥/令牌/PIN/PII，以及对不可信配置进行的 __proto__/原型遍历读取。

Agent 编写的 diff

每次审查都要执行测试篡改和 CI 弱化检查。如果分支主要由 Agent 编写，或你怀疑是 Agent 编写的，还要结合使用 agentic-code-review。对于每个新增或变更的 AI/LLM 功能，检查不可信提示词输入：如果它可能影响特权数据或操作，则为阻断项；否则为关注项。审查深度应根据影响范围，而非作者身份来确定；点击合并的人类要对变更负责。

严重性等级

根据观察到的行为分类，而非标签：计算错误属于阻断项；名称或重命名属于小问题，除非提供的 diff 或上下文证明它会破坏兼容性或行为。对返回值/公共结构中的字段进行重命名，最多属于关注项（“检查旧名称的消费者”）；没有展示调用方时，绝不能列为阻断项，也绝不能让它掩盖真正的行为缺陷。

等级	标准	必要操作
阻断项	行为错误、安全漏洞、数据丢失、不变量被破坏，或门槛被无正当理由削弱	合并前修复
关注项	设计缺陷、缺少证据/测试，或尚未证实会对用户造成损害的性能问题	讨论 + 很可能需要修复
小问题	风格、命名、轻微重复	可选

如果某项性能问题可能影响可用性，但影响尚不明确，应先询问用户是否要将其视为阻断项，再确定等级。

输出格式

## Review Context
- **Scope:** branch diff + staged + unstaged changes
- **Risk:** Medium
- **Blast radius:** `createInvoice()` feeds the payment record
- **Validation evidence:** no test output supplied

## Blockers
- `src/auth.ts:42` — expiry check uses `<` not `<=`; off-by-one passes expired tokens

## Concerns
- No test for error path in `processPayment()`

## Nits
- `userData` → `user` (same meaning, shorter)

## Questions
1. Why is `retryCount` hardcoded to 3 — should this be config?

深度严谨模式

当用户要求严格／全面审查时（例如「/review --strict」、「深度审查」、「严格审查」、「代码质量审计」），在上述工作流的基础上加入 code-review-and-quality 评审准则：逐项检查五个维度（正确性、可读性、架构、安全性、性能），将其中推定的阻断项列入 Blockers，并按照更高的批准标准审查提交。对于 Agent 编写的分支，还要加入 agentic-code-review。

相关内容

• mattpocock/code-review — 采用两个维度（标准 + 规范与原始问题的契合度）进行审查，并由多个子 Agent 并行执行。来源： https://github.com/mattpocock/skills/tree/main/skills/engineering/code-review
• code-review-and-quality — 是上述深度严谨模式所用内置深度严谨评审准则的上游项目；另请参阅 agentic code review，了解 Agent 差异的失效模式。

基准测试

场景：.benchmarks/scenarios/review-001-severity-tiers.md · 运行日期：2026-08-31 · 日志：.benchmarks/runs/2026-08-31/review-001-severity-tiers.json

Model	Without	With	Delta
claude-opus-4-8	67%	83%	+16%
claude-sonnet-4-6	83%	67%	−16%
claude-haiku-4-5	83%	83%	+0%

NEG（运行日期：2026-08-31）。Sonnet 在严重性等级边界上下降 16%，opus 上升 16%。标准与等级表之间的分类存在歧义；在进行任何编辑之前，已排队等待仅针对 c5 的诊断性重新运行（已达到上限）。门槛依据 .agents/skills/skill-optimizer/rules/release-gates.md。