生产导向 PR 审查

要解决什么问题

很多 PR 审查会停在命名、格式或「也许以后有问题」的猜测上，真正会在生产环境暴露的问题——逻辑错误、回归、权限漏洞、写库顺序、并发竞态、测试只覆盖 happy path——反而被淹没。合并前你需要的是：可证实的、与 diff 直接相关的发现，而不是低信号的风格点评。

技能如何工作

PR Review Scout 把审查流程固定成「先上下文、再判变更、再追路径」：

1. 先建上下文：读变更文件与邻近代码，从命名、注释、测试和周边模块理解预期行为；核对是否动到 API 契约、持久化、缓存、鉴权、异步流或用户可见行为。上下文不足时，明确写出假设，不用臆测补洞。
2. 读 diff 找行为变化：沿调用点、状态迁移和失败模式追踪每条变更路径。
3. 按优先级找问题：正确性与回归 → 数据安全与状态一致性 → 安全与权限 → 可靠性与运维（竞态、泄漏、错误被吞）→ 有真实用户影响的性能 → 测试缺口。
4. 输出有门槛的发现：只有「问题可信、影响有意义、解释能钉在变更代码上、能用 2～5 句话说明失败模式」才写入报告；按严重度排序，并附开放问题、残余风险与简短变更摘要。

典型用法包括：Review this PR for bugs and regressions、Check this diff like a senior reviewer and focus on correctness 等。

适用边界

• 默认不展开风格 nit，除非你明确要求更宽泛的反馈。
• 审查态度是 skeptical but fair：不编造无代码依据的运行时行为；区分「已确认问题」与「基于假设的风险」。
• 更细的检查项可参考技能内的 references/review-checklist.md（若环境提供该引用）。