diff-inspector

评审时机

在发起拉取请求和合并之前进行评审。如果相关差异未发生变化，则复用上次的评审结果；否则重新评审。

---

确定评审范围

根据用户输入、当前工作树、拉取请求或合并目标，确定相关代码差异。根据需要检查仓库现有的 Git 状态、惯例和任务上下文。如果检查后评审范围或基准仍不明确，请询问用户。

---

评审流程

1. 检查范围： 将差异与明确提出的请求进行比较，并报告明显的范围偏离或缺失要求。
2. 评审代码： 使用以下技术检查项评审完整差异。

---

技术评审

评审完整差异。对于每个适用的方面，请核实：

• SQL 和数据安全： 查询能否安全处理不可信值、是否保持范围受限，以及是否维护数据完整性。
• 竞态条件和状态： 并发操作、先检查再执行的流程、共享状态和异步工作能否保持原子性和一致性。
• 身份验证和安全： 变更后的入口是否实施身份验证、授权、所有权、令牌有效性和输入验证。视情况检查机密信息处理、不安全的直接对象引用、权限提升、XSS、命令注入、SSRF 和路径遍历。
• 错误处理： 是否能发现并处理故障，包括部分失败、超时、清理和恢复。
• 性能和资源： 检查无界工作、资源泄漏、N+1 查询、缺少索引、可避免的二次复杂度工作、开销大的循环、沉重的依赖项和获取瀑布。
• 可维护性： 检查不必要的复杂性、重复逻辑、职责不清、抽象泄漏，以及理解、测试或扩展变更的难度。
• 数据迁移： 检查不可逆迁移、会锁定表的架构变更、缺少外键索引、不安全的回填，以及在依赖代码之前删除架构。
• 完整性和兼容性： 对每个发生变更的共享契约（例如状态、字段、路径、标识符、架构或配置）：
  1. 先盘点相关位置：使用稳定的契约片段（例如路径前缀、文件名模式、字段名、命令名或解析器函数）搜索整个目标树。
  2. 追踪每个生产者及其所有消费者，并从每个消费者反向追踪到具体的生产者，包括差异之外未变更的文件。只有在消费者计算该值或调用了具名的共享解析器时，才算存在具体的生产者。文档中的占位符、示例，以及预期来自先前工具的状态均不算。
  3. 比较双方使用的确切值或推导逻辑。报告未核实的位置、缺失的实现，以及重复或不一致的推导逻辑。
• API 契约： 根据上述兼容性追踪方法，检查不兼容的响应、没有默认值的新必填输入、变更后的错误格式和分页行为。
• 测试： 测试应证明变更后的公开行为，并覆盖负面情况、边界情况、故障路径和回归保护。检查隔离性问题和易产生不稳定结果的模式。

证据与严重性

只有当相关代码或观察到的行为能够证实具体故障场景时，才将问题列入 Findings。对于有证据支持、但缺少决定性事实的疑虑，应单独列入 Needs investigation，并指出缺失的事实以及验证方法。

• P0： 严重或阻断性问题。可能导致安全漏洞、数据丢失、服务中断或其他必须在合并前修复的故障。
• P1： 严重问题。可能导致行为错误或重大回归，通常应在合并前修复。
• P2： 中等且影响范围有限的问题。可采取行动，但在风险可接受时可以安排在合并后处理。

对于每项发现：

• 引用相关文件及行号
• 描述触发条件和影响
• 根据影响分配 P0、P1 或 P2
• 标记为 CONFIRMED
• 建议采取适度的处理措施

不要将猜测或风格偏好报告为缺陷。

发现格式：[P0/P1/P2] [CONFIRMED] file:line - 触发条件、影响、描述和建议的处理措施

调查格式：[NEEDS INVESTIGATION] file:line - 观察到的证据、可能的故障、缺失的事实以及验证步骤。应有条件地描述影响，而不要将其标记为已确认缺陷的严重性。

---

对抗性子 Agent

当差异较大、涉及多个组件，或影响身份验证、授权、支付、敏感数据、迁移、并发或关键用户工作流等高影响行为时，运行对抗性子 Agent。

You are an adversarial reviewer. Review the established diff.

Think like an attacker and a chaos engineer. Find ways this code will fail in
production — not style issues, not missing tests, actual breakage or security holes.

Apply the relevant Technical review checks from this skill independently.
Include file and line references, the failure trigger, evidence, and impact.
Use the Evidence and severity rules: CONFIRMED findings receive P0/P1/P2;
NEEDS INVESTIGATION concerns go in a separate section with missing facts
and verification steps. Do not classify uncertainty as a confirmed defect.

---

文档与指南一致性

检查差异所影响的文档和可分发指南，包括仓库根目录以及受影响的包、模块或子树中的内容。酌情检查：

• README 文件、架构指南、贡献指南、API 参考和其他说明性文档
• 特定于包或模块的文档
• 项目惯例要求的变更日志和发行说明，或变更会影响用户时的相关文档
• 面向在仓库中工作的 Agent 的仓库操作约定，例如 AGENTS.md 或 CLAUDE.md
• 仓库分发的可安装 Agent 技能、提示词、模板、示例、插件元数据及其他面向 Agent 的产物

检查行为、接口、设置、配置、安装、迁移、必需产物、工作流、交接规则、工具用法或部署限制的变更，是否已反映在所有受影响的文档或产物中。

当仓库分发可安装技能或其他面向 Agent 的产物时，应将其视为产品输出。核实其中的说明、示例、引用、元数据和打包方式是否仍与变更后的行为一致。

报告每项不一致之处，并引用变更代码和受影响文档或产物的位置。

---

最终输出

先按 P0 到 P2 的顺序列出已确认的发现，再列出有证据支持、需要进一步调查的疑虑。按故障场景和受影响位置审查并去重技术检查、文档检查和对抗性检查的结果，同时保留不同原因和最有力的证据。

使用以下结构：

## Diff Inspector
Scope: [CLEAN / DRIFT / MISSING]
Reviewed: [diff source and scope]
Adversarial review: [RUN — Trigger: reason]

### Findings
- [P0/P1/P2] [CONFIRMED] file:line - trigger, impact, description, and recommended action

### Needs investigation
- [NEEDS INVESTIGATION] file:line - observed evidence, possible failure, missing fact, and verification step

### Scope differences
- [include only when scope drift or missing requirements exist]

仅当运行了对抗性审查时，才包含 Adversarial review 行。如果没有已确认的发现，请写明 No confirmed findings.。单独报告需要调查的疑虑。不要包含空章节。