审查 PR/commit/diff…

对代码变更（PR、commit、diff）做安全导向的差分评审，按代码库规模自适应分析深度，量化爆炸半径并检查测试覆盖，最终生成 markdown 报告。

适用场景

解决思路

1. 按风险而非改动大小分类：HIGH 风险触发条件为认证、加密、外部调用、价值转移、移除校验；MEDIUM 为业务逻辑、状态变更、新增公开 API；LOW 为注释、测试、UI、日志。
2. 按代码库规模选择策略：SMALL（<20 文件）用 DEEP，读取全部依赖并做完整 git blame；MEDIUM（20-200）用 FOCUSED，只查 1 跳依赖和优先文件；LARGE（200+）用 SURGICAL，只分析关键路径。
3. 执行 Pre-Analysis 建立基线上下文（可结合 audit-context-building skill）。
4. Phase 0 分诊：对每个改动文件按风险等级分类，确定分析范围。
5. Phase 1 代码分析：对移除的安全相关代码执行 git blame，追溯历史与回归。
6. Phase 2 测试覆盖：检查被修改代码是否有测试覆盖，缺失测试则提升风险等级并在报告中标注。
7. Phase 3 爆炸半径：通过统计调用者数量量化计算爆炸半径，覆盖传递性调用者，对 HIGH 风险变更必须计算。
8. Phase 4 深度上下文：对 HIGH 风险变更做深入上下文分析。
9. Phase 5 对抗分析：对 HIGH 风险变更做攻击者建模与利用场景分析，可委派给 differential-review:adversarial-modeler 子代理（必须使用完整命名空间名作为 subagent_type，裸名会注册失败）。
10. Phase 6 报告：按 reporting.md 的结构与模板生成完整 markdown 报告文件，不能只输出到聊天。
11. 对移除的『security』『CVE』『fix』提交中的代码、被移除的访问控制修饰符（onlyOwner、internal → external）、无替代的校验移除、无检查的新增外部调用、高爆炸半径（50+ 调用者）叠加 HIGH 风险变更，立即升级并强制做对抗分析。
12. 交付前完成质量清单：所有改动文件已分析、对移除的安全代码做过 git blame、HIGH 风险已算爆炸半径、攻击场景具体而非泛泛、发现引用具体行号与 commit、已生成报告文件、已向用户发送摘要通知。
13. 可结合 issue-writer skill 将发现转为正式审计报告：issue-writer --input DIFFERENTIAL_REVIEW_REPORT.md --format audit-report。
14. 避免常见借口：不要因 PR 小而跳过（Heartbleed 只有 2 行）、不要因熟悉代码库而省略基线、不要跳过 git 历史、不要凭直觉判断爆炸半径、不要因无测试就放过、不要把重构默认当作无安全影响、不要只口头说明而不写报告。

适用边界 · 注意事项

• 全新项目（greenfield）代码，没有可对比的基线。
• 仅文档改动、格式化或 lint 等无安全影响的变更。
• 用户明确只要求快速摘要并接受相应风险时。