review

合并前审查

检查请求的变更是否存在实际缺陷，以及验收证据是否缺失。审查请求默认仅报告结果。只有在收到修复请求或已有授权时才应用修复；绝不能根据审查调用推断已获得提交、推送、合并或 PR 权限。

固定审查范围

确定 PR 目标分支或明确提供的基准分支，然后验证该引用存在。仅在没有其他信息时，才使用仓库配置或默认分支作为后备，并说明存在的不确定性。如有需要且可用，../../../scripts/detect-base-branch.sh 可解析候选分支；其后备结果并非依据。应从已加载的技能目录解析此路径，而不是假定存在 Claude 环境变量。

如果可访问网络且需要确保信息最新，则获取一次基准分支。记录基准 SHA、HEAD 和合并基点。审查 git diff <merge-base> <head>，以查看已提交的分支变更，而不是与更新的基准分支最新提交进行比较。使用 review-scope.py 和 --base <verified-ref> 确定范围并记录指纹。仅在请求审查工作树变更时才添加 --include-local；其本地补丁和未跟踪文件属于独立证据。指定基准分支名称并不会排除本地审查。请求范围内没有变更时，就没有内容需要审查。

保留无关的未提交变更。审查前对检出内容做快照；如果审查期间 HEAD 或范围内文件发生变化，则停止审查，确认变更来源，并重新固定受影响的证据。不要还原其他变更者的改动。

审查

确定范围后，先着手处理只需查看快照即可开展的工作，再阅读差异。派发任何必需的独立审查者（见下文）。如果仓库现有的测试和 lint 命令不会产生外部影响，就在后台运行。一次只运行一个测试套件，因为各套件会共用端口、数据库和测试夹具；lint、类型检查和静态分析等静态检查不会共用这些资源，因此可以与测试套件并行启动。对于无需审查者的小型差异，后台检查是唯一的并行工作。

绝不要在某项检查正在后台运行时于前台运行同一项检查，也绝不要循环轮询其日志；继续审查，并在收到检查完成通知后读取结果。应在一个步骤中同时发起相互独立的读取和搜索，而不是每轮只发起一项。

阅读 checklist.md；如果无法获取，请报告清单覆盖项缺失。清单中的诊断规则和抑制规则适用，而本入口文件负责控制范围、操作权限和结论。

将差异与用户目标及 PR 意图进行比较；提供证据，报告范围增加项和遗漏的要求。当变更需要时，检查差异块之外的共享调用方、持久化数据、枚举消费者、错误路径、授权和信任边界。提出问题前，先检查现有处理方式。

优先检查数据/SQL 和迁移安全性、并发、身份验证、API 契约和大模型信任边界。然后检查相关错误处理、有条件副作用、耦合、测试、性能和前端行为。严重程度取决于已证实的后果，而不是发现问题的清单章节。将相关安全模式作为证据前，只阅读匹配的模式：

差异涉及……	阅读模式……
缓冲区/数组处理（C/C++）	01 Bounds, 11 Integer Arithmetic
新增/变更身份验证或中间件	03 Auth
加密操作（哈希、签名、随机数生成）	04 Crypto Hygiene
解析器/反序列化/上传	17 Canonicalization, 02 Injection, 01
并发/goroutine/锁	05 Race Conditions
特权操作的错误路径	07 Error Handling
依赖项/锁文件/CI 配置	08 Supply Chain
Web/浏览器/前端	16 Web App Security
新增 HTTP 端点	03 Auth, 02 Injection, 16 Web
安全敏感代码的重构	14 Regression Prevention

模式路径位于 ../../core/review-security/patterns/ 下。与 CVE 相似只是一个假设；应在此代码中确认输入是否可达及其影响。根据已安装的版本和权威文档验证 API。将无法执行的检查标记为未验证。

对于前端变更，请使用现有设计系统、设计令牌和组件（如果存在 DESIGN.md，也应参照）。针对相关检查加载 design-checklist.md。仅凭代码产生的疑虑，必须经过渲染/计算结果确认，才能认定为视觉缺陷。字体、网格、CSS 覆盖或小标签并非必然有缺陷。对于大型前端变更（例如涉及多个文件或超过 200 行变更的前端代码），可以将设计清单交给一个只读子 Agent。向其提供已确定的范围和变更的前端文件，并要求它按清单格式返回代码层面的发现。渲染确认由主审查者负责，并且一次只进行一项浏览器检查。

独立审查

作为主要审查负责人时，对于非平凡的身份验证、支付或安全变更、新的外部集成、变更行数超过 200 行的差异，或明确提出的请求，应安排一位独立的只读审查者。使用实际运行环境支持的工具和模型配置来派遣；不要臆造 API 字段，也不要假设 Claude Agent 的命名规则适用于 Codex。遵守上级的委派限制。如果无法安排，应记录这一审查缺口。范围确定后应立即派遣，在你开始审查之前完成；只需在作出结论前等待审查结果。

如果你被指派为该独立审查者或设计子 Agent，请执行审查并向上级返回证据。不要进一步委派、启动测试套件，也不要把缺少第三位审查者标记为审查覆盖缺口；检查工作由上级负责。

只向审查者提供目标、准确的 base/head 或本地快照、绝对检出路径、相关原始材料和只读限制，绝不提供你自己的发现。要求其提供已确认的发现，包括触发条件、文件/行证据和影响。没有发现也完全有效。要求其给出最终回复，包括审查范围和任何未完成的检查。记录其 Agent ID，并以家长身份保存返回的证据；沉默或不完整的回复不代表审查通过。如有需要，只询问一次可用结果，然后报告这一缺口，不要重复派遣。

发现与授权修复

每项发现都应说明严重程度、文件/行、具体故障场景、证据和建议的修正方案。区分已确认的缺陷、待调查线索和风险接受。不要为了凑数量而虚构发现。

在仅报告模式下，到报告发现、后台检查结果和结论为止。在修复模式下，在现有授权范围内进行有针对性的修正，将真正涉及设计/范围的决策集中处理，并避免引入无关改动。完成修改后，应针对最终文件重新运行所有可能受修复影响的检查；其余检查仍以后台结果为准。保留能够揭示真实缺陷的失败回归测试。重新审查变更范围，并在需要时进行独立审查。仅当某项具体陈述已不再准确时，才标记文档问题。

结果

面向用户的报告请使用以下易读的输出格式。对于由机器处理的环节，调用方可提供明确的架构来替代此格式；主要负责人仍须报告证据和结论。

以 Pre-Landing Review: N issues (X critical, Y informational) 开头。统计不同的已确认发现，包括本次审查期间已修复的发现。按已证实的影响分类：严重发现若未解决，会阻止合入；信息性发现不阻止合入。清单类别、来源以及修复是否为机械性修复，均不决定严重程度。将未经确认的调查线索单独列出，不计入统计。

按严重程度顺序展示两个部分，严重问题在前；空部分写 None.。每项发现都要简短具体：

### CRITICAL — X findings

1. **file:line — Problem title** — UNRESOLVED / FIXED / RISK ACCEPTED

   Problem: failing scenario, consequence and evidence.

   Fix: proposed correction, or the correction applied and its verification status.

### INFORMATIONAL — Y findings

2. **file:line — Problem title** — UNRESOLVED / FIXED / RISK ACCEPTED

   Problem: failing scenario, consequence and evidence.

   Fix: proposed correction, or the correction applied and its verification status.

然后展示一张简洁的 Markdown 完成情况表。填写实际结果；如适用，请使用 NOT RUN、SKIPPED 或 NO RESPONSE 并注明原因。保留失败检查的详细信息和未解决发现的引用，不要将其隐藏在统计数字中。

完成情况摘要	结果
审查范围	基准和头部 SHA；已提交和／或请求的本地更改
差异规模	更改的文件数、插入和删除行数
范围检查	CLEAN / DRIFT DETECTED / REQUIREMENTS MISSING，并附详细信息
严重发现	共 X 项；已修复和未解决的数量；另行注明已接受的风险
信息性发现	共 Y 项；已修复和未解决的数量；另行注明已接受的风险
修复	已应用的修正，或仅报告
检查	命令及 PASS / FAIL / NOT RUN 结果，包括受影响的修复后检查
独立审查	已完成的结果 / SKIPPED / NO RESPONSE / 不可用，并注明范围和原因
未解决事项	发现引用、决定及缺失的必需证据，或 None
交付状态	仅报告 / 未提交的修复 / 其他明确授权的交付

如无发现，使用 Pre-Landing Review: 0 issues (0 critical, 0 informational)，在两个部分中都写 None.，并使用相同的表格。无发现并不意味着验证已完成。

最后给出加粗的合入结论和简短理由，使用以下既定门槛：

• **可安全合入：**没有未解决的阻塞项；必需的验证和独立审查均已针对稳定的最终文件完成。
• **谨慎合入：**没有未解决的阻塞项，且所有必需门槛均已完成，但存在明确标注为非阻塞的注意事项或可选覆盖缺口。
• **不可合入：**存在已确认的阻塞项、回归问题或缺失的必需证据。应区分“发现缺陷”和“就绪情况尚未验证”。

已跳过的严重发现仍属于未解决项，结论应为不可合入。用户接受风险应单独记录；这不会改变发现的严重程度或验证状态。必需的审查者未响应意味着证据缺失，而非零发现。该结论不授权合并。