review-pr 是一个结构化代码审查技能，用于评审拉取请求（PR）或一组代码变更。它专注于本次变更引入的问题，而非代码库中已存在的旧问题，并最终生成一份按优先级排序的 HTML 报告。
【用途】 适用于以下场景：合并前评审 PR；在提交 PR 前评审自己的代码；对特定 diff 进行安全或正确性审计；在实现某功能后进行增量审查。
该技能明确列出不应做的事情：不标记作者未触及的既有问题；不因风格/格式问题阻塞（那是 linter 的职责）；不按个人偏好重写代码；不列出缺乏证据的推测性风险。
【工作流程】
阶段 1 — 上下文收集。在查看任何 diff 之前，先阅读：PR 描述（这次变更想做什么）、关联 issue（解决什么问题）、提交信息（作者每一步的意图）、CLAUDE.md / CONTRIBUTING.md（项目特定约定）。如果 PR 是草稿、标题含 WIP 或已关闭，需先询问用户再继续。对于变更超过 400 行的 PR，会提示用户并建议拆分，仅在用户确认后继续。
阶段 2 — 过滤出本次 PR 引入的问题。只报告本 diff 中新增的问题，使用 git blame 确认问题由本次变更引入而非继承自既有代码。示例命令：git log -p --follow -S "<suspicious code>" -- <file>；git log --all --oneline -S "<removed-code-pattern>"。如果可疑模式在代码库其他地方已存在且并非本次新增，则标记为既有问题并跳过。
阶段 3 — 审查维度，按优先级顺序：
- 安全（最高优先级）：注入（SQL、命令、LDAP、XPath、模板注入）；认证/授权（缺失鉴权检查、权限提升、JWT/session 问题）；敏感数据（代码、日志或错误信息中的密钥、凭据或 PII）；输入验证（未验证的用户输入进入危险操作）；加密（弱算法、硬编码密钥、不安全随机数）；依赖风险（新增的包是否可信、维护良好、最小化）。每个发现需具体说明利用场景，而非仅说“这可能不安全”。
- 正确性：逻辑错误、差一错误、null/undefined 处理；async/await 正确性、未处理的 promise rejection；边界情况（空输入、零、负数、最大值）；错误传播（错误是否被静默吞掉）；竞态条件或共享可变状态。
- 性能：N+1 查询（循环内的数据库调用）；新查询模式缺少索引；无界操作（无分页、无限制）；异步代码中不必要的阻塞操作；一次性加载进内存的大负载。
- 可维护性：函数职责过多（超过 30 行值得审视）；深层嵌套（超过 3 层）；无解释的魔术数字/字符串；误导性的变量/函数命名；引入的死代码。
- 测试覆盖：正常路径是否有测试；边界与错误路径是否测试；测试断言是否有意义（不只是“它不抛异常”）；既有测试覆盖是否被无意破坏。
- 错误处理：静默错误的空 catch 块；清理操作缺少 finally；泄露内部细节的面向用户的错误信息。
- 文档（最低优先级）：公共 API 变更未更新文档；复杂逻辑无解释注释；与代码矛盾的过时注释。
阶段 4 — 置信度过滤。纳入报告前需自问：能否指出确切文件与行号？能否描述该问题导致实际问题的具体场景？置信度是否 ≥ 80%？任一答案为否，则丢弃该发现或降级为问题/建议。同时跳过：linter 已能捕获的问题；需要推测未来场景才成立的；无功能影响的纯风格问题；既有问题（非本次 PR 引入）。
阶段 5 — 生成 HTML 报告。生成自包含的 HTML 报告至 /tmp/code-review-report.html，包含 PR 标题与编号、分支、文件数、行数（+X / -Y）、按类别统计的摘要（Blocking、Important、Nits、Suggestions），以及按严重程度分区的发现列表：🔴 Blocking（安全漏洞、数据丢失风险、功能损坏——合并前必须修复）、🟡 Important（真实 bug 或风险，应修复但非紧急）、🔵 Nit（轻微质量问题，可轻松修复则修复）、💡 Suggestion（可选改进）、✅ Positive Observations（值得肯定的良好实践），并给出最终裁定：✅ Approve 或 🔄 Request Changes。
报告中每个发现包含标题、文件路径与行号、描述、代码对比示例（当前写法与修复写法）以及置信度百分比。严重程度参考另包含 👻 Pre-existing 等级，表示问题存在但非本次 PR 引入。
【使用方式与限制】 资料展示了完整的使用流程与 HTML 模板，但未提供安装命令、调用参数或与具体平台的集成方式。关于收费、价格、支持平台等信息，资料中暂未提供。