用途
该技能用于对一项实现变更进行独立审查，目标是找出可能改变结果或使变更不安全的缺陷。它强调不要将个人偏好当作审查发现。审查由未参与实现该变更的新子智能体执行，且保持只读，不编辑文件、不发表评论。
审查范围
审查用户指定的实现目标，可以是文件、diff、分支、提交、拉取请求或其他 GitHub 上的代码变更。如果用户未指定目标，则审查仓库完整的本地变更集，包括当前分支相对于默认分支的提交、已暂存变更、未暂存变更和未跟踪文件。审查以仓库及紧邻代码为上下文；如果没有本地变更，应说明这一点，不得以全仓库审计替代。
审查标准
仅在以下情况批准：变更与其来源一致且行为符合要求；没有已知缺陷或未处理风险可能破坏来源或仓库在安全、数据丢失、兼容性或运维方面的规则。不要求完美，不因个人偏好阻塞，需引用技术证据或仓库约定。结论是独立智能体的证据，不是 GitHub 批准，也不能替代人工审查。
审查顺序
- 设定框架：向审查者提供任务、验收标准和不变量 ID、仓库规则、完整 diff 或拉取请求、测试证据，并指明受变更影响的用户或开发者。
- 宏观审视：阅读变更摘要和相关规格或工单，确认变更属于系统、符合预期行为并交付一个可审查的结果；在审查细节前报告不匹配。
- 审查主要行为：从交付结果的文件和流程开始，检查行为、失败、安全边界、接口、兼容性、迁移、并发和运维。
- 在上下文中审查每一行人工编写的变更：阅读足够周边代码以判断正确性、回归、复杂度、命名、注释、风格和文档；对生成文件或大数据检查来源并抽查输出；发现应保持在变更范围内。
- 审查证明：检查测试是否覆盖变更行为和受影响的失败路径，是否证明每个引用的 AC-n、REQ-n、INV-n 或任务标准，是否断言用户或调用者可观察的行为或文档化的内部契约，是否在实现损坏时会失败，是否复制实现逻辑或在设置中隐藏场景。运行聚焦检查以确认或反驳可能改变发现或结论的主张。
- 检查专业覆盖：识别安全、隐私、并发、可访问性、国际化或领域特定工作；当审查者缺乏证据或技能判断时，将风险标记为未验证；当该缺口可能隐藏破坏规则的问题且无合格审查者覆盖时，使用 Blocked。
- 报告发现：按优先级顺序返回可执行的发现。
代码审查发现
仅报告真实缺陷、影响客户的问题以及由变更引入或暴露的已证实简化。检查安全、逻辑、行为、可靠性、兼容性、回归和受影响的失败路径。检查足够周边代码以证明每个发现。简化必须用更少状态、间接、重复或运维工作交付相同结果和证明，且仅作为 Could fix 报告。
每个发现的格式：
- Priority: Must fix / Should fix / Could fix
- Confidence: 0 到 5
- What I found: 描述技术问题。
- Why it matters: 解释对客户、调用者或服务的影响。
- Trigger and effect: 说明确切条件以及客户或服务经历什么。
- Where: 文件和行。
- Suggested fix: 给出简短实用的方向。
优先级含义：
- Must fix：不安全合并。变更可能导致安全失败、数据丢失、破坏必需行为或严重服务回归。
- Should fix：真实缺陷或可靠性风险，应在合并前纠正。
- Could fix：已证实的有限问题或简化，不需要阻塞合并。不用于风格偏好。
置信度含义：
- 5：通过复现、测试或直接代码证据确认。
- 4：强证据，无可信替代解释。
- 3：可能，但某些运行时证据不可用。
- 0 到 2：不报告。进一步调查或将区域标记为未验证。
使用平实语言，说明什么会坏、何时坏、影响谁。省略风格偏好、理论担忧和变更之外的问题。
结论
如果新子智能体不可用，停止并报告独立审查被阻塞，除非用户明确接受有记录的自我审查。如果没有发现，说明这一点。以 Approve、Request changes 或 Blocked 结束，然后说明哪些仍未验证。Must fix 或 Should fix 发现要求 Request changes。Could fix 发现不阻止 Approve。
边界
发现保持在变更范围内，但检查足够周边代码以判断每个变更行及其系统影响。不要将偏好变成发现，使用技术证据和仓库约定。不要仅因为检查通过就批准。