review

评审

根据各轮检查评审变更，然后综合各轮结果给出结论。

如果引用的技能在本地不可用，请在运行时从 open-review 仓库获取该技能，包含整个目录及其子目录。如果可用，请使用 npx skills use elliottlawson/open-review@<name>；否则从 GitHub 获取该目录。

范围

评审相对于基础分支合并基点的差异（git diff origin/main...HEAD，或调用方指定的基础分支／范围）。确认引用可解析；如果差异为空，请说明并停止。跳过生成文件和 vendored 文件。

步骤 0 — 查找项目参考资料

使用 /infer-conventions 查找项目的规范和技术栈；在各轮检查中使用它加载的内容。如果项目没有记录规范，请在结论中说明，不要自行臆造。

各轮检查

按顺序执行：使命 → 架构 → 实现 → 工艺 → 安全 → 性能。然后综合各轮结果给出结论：

• 批准 — 达成使命，且没有阻塞性问题。
• 需要修改 — 发现实际问题；请说明问题。
• 暂缓 — 使命不明确，或架构问题需要先讨论。

深度校准。 根据范围调整评审深度——2 个文件的错误修复应简要评审；30 个文件的功能则需深入评审。

标记问题前先验证。 每项发现都必须指明具体行及具体后果。无法验证时，请提出问题。

报告

以文字形式报告发现的问题——注明严重级别（critical／warning／info）、发现该问题的检查轮次、文件和行号，以及问题的重要性。

• 评审变更，而非整个代码库。 仅针对新增或有实质性变更的代码提出阻塞性问题；对既有违规至多作为建议提出。
• 引用规范并说明目标模式。 项目有书面规范时，指出发现违反了哪份文档，并说明应遵循的模式。
• 重复问题只报告一次。 多个文件存在同一问题时，作为一项发现报告，并说明其普遍适用范围。

在 CI 环境下，/review-as-json 会将此评审包装并输出为 JSON。