review

审查

找出会改变结果或使更改不安全的缺陷。不要把个人偏好当成问题。

使用一位未参与实现的全新子 Agent。要求其直接审查，不要委派他人。如果你就是审查者，请直接审查。保持只读。不要编辑文件或发布评论。

范围

审查用户指定的实现目标。目标可以是文件、差异、分支、提交、拉取请求或 GitHub 上的其他代码更改。对于尚未实现的技术提案，请使用 /architecture-review。

如果用户没有指定目标，请审查仓库的完整本地更改集。包括当前分支相对于默认分支的提交、暂存更改、未暂存更改和未跟踪文件。

结合仓库及其紧邻代码作为上下文。如果没有本地更改，请如实说明。不要以整个仓库审计代替目标审查。

标准

仅在满足以下条件时批准：

• 更改符合其来源，并按要求运行。
• 没有已知缺陷或未处理的风险可能违反安全、数据丢失、兼容性或运维方面的来源或仓库规则。

不要要求尽善尽美，也不要因个人偏好而阻止更改。请引用技术证据或仓库惯例。

审查结论是独立 Agent 的证据，不等同于 GitHub 批准，也不能替代人工审查。

审查顺序

1. 明确审查框架。 向审查者提供任务、验收标准、任务或规格中的不变条件 ID、仓库规则、完整差异或拉取请求，以及测试证据。指出会受到更改影响的用户或开发者。
2. 着眼全局。 阅读更改摘要和相关规格或工单。确认更改属于该系统、符合预期行为，并且只交付一个可审查的结果。发现不匹配时，应先报告，再审查细节。
3. 审查主要行为。 从交付结果的文件和流程入手。检查行为、失败场景、安全边界、接口、兼容性、迁移、并发和运维。
4. 结合上下文审查每一行人工编写的更改。 阅读足够的周边代码，以判断正确性、回归、复杂度、命名、注释、风格和文档。对于生成文件或大型数据，检查源文件并抽查输出。问题应限于更改范围内。
5. 审查验证依据。 检查测试是否：
   • 覆盖更改后的行为和受影响的失败路径。
   • 证明每一项被引用的 AC-n、REQ-n、INV-n 或任务标准。
   • 断言用户或调用方可观察到的行为，或有文档说明的内部契约。
   • 在实现有误时会失败。
   • 不会照搬实现逻辑，也不会在测试准备阶段隐藏场景。
6. 运行有针对性的检查，以确认或推翻可能改变问题判断或审查结论的主张。
7. 检查专业领域覆盖情况。 识别安全、隐私、并发、无障碍、国际化或特定领域的工作。如果审查者缺乏判断所需的证据或技能，应标记为风险未经验证。若该缺口可能掩盖违反规则的问题，且没有合格的审查者负责覆盖，则使用 Blocked。
8. 报告问题。 按优先级使用下方格式提交可采取行动的问题。

代码审查发现

仅报告真实的 Bug、影响客户的问题，以及本次更改引入或暴露且已证实的简化。检查安全性、逻辑、行为、可靠性、兼容性、回归问题及受影响的故障路径。

检查足够多的上下文代码，以证明每项发现。简化必须在减少状态、间接层、重复内容或运维工作量的同时，提供相同的结果和证明。仅在符合 Could fix 的情况下报告。

每项发现均使用以下格式：

Priority: Must fix / Should fix / Could fix
Confidence: 0 to 5
What I found: Describe the technical problem.
Why it matters: Explain the impact on customers, callers, or the service.
Trigger and effect: State the exact condition and what the customer or service experiences.
Where: File and line.
Suggested fix: Give a short, practical direction.

优先级含义：

• Must fix： 不适合合并。此更改可能导致安全故障、数据丢失、必需行为失效或严重的服务回归。
• Should fix： 存在真实缺陷或可靠性风险，应在合并前修正。
• Could fix： 已证实且影响有限的问题或简化，无需阻止合并。不要将风格偏好归入此类。

置信度含义：

• 5： 已通过复现、测试或直接代码证据确认。
• 4： 有强有力的证据，且不存在可信的其他解释。
• 3： 有可能成立，但缺少部分运行时证据。
• 0 到 2： 不要报告。应进一步调查，或标记为未验证。

使用通俗措辞。说明什么情况下会发生什么故障，以及会影响哪些人。省略风格偏好、理论上的担忧和更改范围之外的问题。

结论

如果无法使用新的子 Agent，请停止审查，并报告独立审查受阻，除非用户明确接受有记录的自我审查。

如果没有发现问题，请明确说明。最后以 Approve、Request changes 或 Blocked 之一结束，并说明还有哪些内容尚未验证。存在 Must fix 或 Should fix 级别的问题时，必须给出 Request changes。Could fix 级别的问题不会阻止 Approve。

范围

• 将发现限制在本次更改范围内，但应检查足够多的上下文，以判断每处更改及其对系统的影响。
• 不要将个人偏好当作发现。使用技术证据和仓库惯例。
• 不要仅因检查通过就批准。