pr-review

PR 审查

从五个维度进行基于差异的代码审查。读取已更改的文件，选择适用的审查方法，并生成按严重程度排序的汇总报告。

原生替代方案： Claude Code 的 /ultrareview 会运行轻量的原生缺陷导向审查（Opus 4.7 发布时，Pro/Max 计划用户每月可免费使用三次）。如需从五个维度进行按严重程度排序的分析（代码质量 + 测试 + 错误处理 + 类型 + 注释），并提供文件:行号引用，请使用此技能；如需快速排查差异中的缺陷，请使用 /ultrareview。

参考文件

文件	内容	加载时机
references/code-review.md	指南合规性、缺陷检测、置信度评分	始终
references/test-analysis.md	行为测试覆盖率、关键程度评级	测试文件已更改
references/error-handling.md	静默失败模式、catch 块分析	错误处理已更改
references/type-design.md	不变量分析、四维度评级标准	类型定义已添加或修改
references/comment-quality.md	注释准确性、长期价值、过时检测	注释或文档字符串已添加

---

工作流

阶段 1：确定范围

1. 确定审查目标：
   • 默认：git diff（尚未暂存的更改）
   • 如果用户指定 PR：git diff main...HEAD 或 gh pr diff <number>
   • 如果用户指定文件：直接审查这些文件
2. 使用 git diff --name-only 列出所有已更改的文件
3. 阅读项目的 CLAUDE.md（如果存在），了解项目特定规则

阶段 2：分流

对已更改的文件进行分类，并选择适用的维度：

条件	维度	要加载的参考文件
始终	代码审查	references/code-review.md
与 *test*、*spec*、*_test.*、test_* 匹配的文件	测试分析	references/test-analysis.md
包含 try/catch、except、.catch、Result、错误回调的文件	错误处理	references/error-handling.md
包含 class、interface、type、struct、enum、dataclass 定义的文件	类型设计	references/type-design.md
包含新增或修改的文档字符串、JSDoc 或块注释的文件	注释质量	references/comment-quality.md

仅加载适用的参考文件。跳过没有匹配文件的维度。

阶段 3：审查

针对每个适用维度，使用已加载的方法分析差异：

1. 代码审查 — 检查每个已更改文件是否违反指南或存在缺陷。 应用置信度评分（0-100）。仅报告评分 >= 80 的问题。
2. 测试分析 — 将测试覆盖范围映射到已更改的代码路径。为缺口评级（1-10）。 仅报告评级 >= 5 的缺口。
3. 错误处理 — 检查差异中的每个错误处理程序，查找静默失败。 分类为 CRITICAL/HIGH/MEDIUM。
4. 类型设计 — 从四个维度评估新增或修改的类型（封装、不变量表达、有用性、强制执行）。分别评级（1-10）。
5. 注释质量 — 验证准确性、评估长期价值，并标记过时注释。

阶段 4：汇总

将所有发现合并为一份报告，去重并按严重程度排序。

去重规则：

• 如果两个维度标记了同一个文件:行，只保留严重程度较高的发现
• 如果代码审查和错误处理都标记了一个空的 catch 块，将它们合并为一条 发现，并采用错误处理的严重程度（它是专门的维度）

跨维度严重程度映射：

维度	映射为严重	映射为重要	映射为建议
代码审查	置信度 90-100	置信度 80-89	—
测试分析	评级 9-10	评级 7-8	评级 5-6
错误处理	CRITICAL	HIGH	MEDIUM
类型设计	任意评级 <= 3/10	任意评级 4-6/10	评级 7-8/10
注释质量	事实错误	具有误导性或不完整	复述显而易见的代码

---

输出格式

# PR Review Summary

**Scope:** [X files changed, Y dimensions applied]
**Dimensions:** [list of active dimensions]

## Critical Issues (must fix before merge)
- **[dimension]** `file:line` — Description. Fix suggestion.

## Important Issues (should fix)
- **[dimension]** `file:line` — Description. Fix suggestion.

## Suggestions (consider)
- **[dimension]** `file:line` — Description.

## Strengths
- What's well-done in this changeset.

## Recommended Action
1. Fix critical issues
2. Address important issues
3. Consider suggestions
4. Re-run review after fixes

如果没有发现任何严重程度的问题，请简要总结已审查的内容和应用的维度，并确认代码符合标准。

---

维度选择

用户可以指定特定维度，而不是运行全部维度：

用户表述	应用的维度
“审查我的 PR” / “检查我的更改”	所有适用维度（默认）
“审查代码” / “检查代码质量”	仅代码审查
“检查测试” / “测试覆盖率够好吗”	仅测试分析
“检查错误处理” / “查找静默失败”	仅错误处理
“审查类型” / “检查类型设计”	仅类型设计
“检查注释” / “审查文档”	仅注释质量

当用户请求特定方面时，只加载对应的参考文件并跳过路由。

---

错误处理

问题	解决方法
没有可用的 git diff	请用户指定文件或范围
未找到 CLAUDE.md	根据通用最佳实践进行审查；注明该文件缺失
diff 中没有测试文件	跳过测试分析维度；在输出中注明
diff 为空	报告“没有要审查的更改”并停止
diff 超出上下文限制	重点审查用户最可能关注的文件；总结跳过的文件

---

校准规则

1. 精确优先于召回率。 误报会损害用户对审查的信任。只报告置信度 >= 80（代码审查）或严重性 >= 5（测试）的问题。宁可不报，也不要制造噪声。
2. 必须提供文件:行引用。 每条发现都必须包含具体位置。模糊的发现（“考虑改进错误处理”）无法采取行动。
3. 项目规则优先于通用规则。 如果 CLAUDE.md 要求“使用箭头函数”，即使惯例风格更偏好 function 声明，也不要指出箭头函数的问题。
4. 必须去重。 如果两个维度标记了同一个问题，将它们合并。绝不重复报告同一问题。
5. 肯定优点。 只列问题的审查令人沮丧。即使简短，也要指出做得好的地方。
6. 简化由 code-refiner 负责。 此技能负责审查和报告，不负责重构或简化——那是 code-refiner 技能的工作。请明确区分职责。

似是而非的理由

似是而非的理由	事实
“测试通过了，所以代码没问题”	测试必不可少，但还不够——它们无法发现架构、安全性、可读性和可维护性方面的问题
“改动很小，不用认真审查”	大多数生产事故都由小改动引发；3 行的身份验证绕过问题，比 300 行的重构更糟糕
“以后再整理”	以后永远不会到来——审查就是代码变成遗留代码前的质量关卡
“作者是资深工程师，我信任他们”	资历无法避免失误；旁观者能发现熟悉感让人忽略的问题
“我最近已经审查过类似代码了”	每个差异都有独特的上下文——沿用过去审查中的假设会导致问题遗漏
“这只是重构，不可能出问题”	重构会以微妙的方式改变行为——请通过测试和追踪调用位置来验证

危险信号

• 未完整阅读每个变更文件就批准（而非只看差异块）
• 发现问题时未标明文件和行号——含糊的反馈无法付诸行动
• 因为“看起来没问题”而跳过某个审查维度
• 只报告风格问题，却忽略逻辑、安全性或架构问题
• 以审查手写代码的同等严格程度审查生成的代码（迁移文件、protobuf 存根）
• 未去重就合并不同维度的发现

验证

• 已完整阅读每个变更文件，而非只看差异块
• 已对每个审查维度评分：正确性、安全性、性能、可读性、架构
• 每项发现都包含文件和行号
• 每变更 100 行至少提出一项可执行的发现；否则，须明确说明“未发现问题”并给出理由
• 审查摘要包含风险等级（LOW/MEDIUM/HIGH/CRITICAL），并区分阻塞与非阻塞问题
• 肯定优点——审查不应全是负面评价