AI Skills
pr-review

pr-review

热门

审查 PyTorch 的 Pull Request（PR），重点检查代码质量、测试覆盖率、安全性以及向下兼容性（BC）。适用于 PR 审查、代码变更评审，或者当用户提及“review PR”、“code review”、“帮我看下这个 PR”等场景。

10万Star
2.9万Fork
更新于 2026/8/3
获取 Skill源代码

相关 Skills

gifgrep39万blucli38万recsys-pipeline-architect24万
SKILL.md
只读
名称
pr-review
描述

审查 PyTorch 的 Pull Request（PR），重点检查代码质量、测试覆盖率、安全性以及向下兼容性（BC）。适用于 PR 审查、代码变更评审，或者当用户提及“review PR”、“code review”、“帮我看下这个 PR”等场景。

PyTorch PR Review Skill

审查 PyTorch Pull Request，专注 CI 无法覆盖的内容：代码质量、测试充分性、安全漏洞和向下兼容性（BC）。

使用模式

无参数模式

如果用户在未附带任何参数的情况下调用 /pr-review，不要执行审查，而是询问用户想审查什么内容：

您想审查什么？

  • PR 编号或 URL（例如 /pr-review 12345）
  • 本地分支（例如 /pr-review branch）

本地 CLI 模式

用户提供 PR 编号或 URL：

/pr-review 12345
/pr-review https://github.com/pytorch/pytorch/pull/12345

如果需要包含逐行详细意见的深度审查：

/pr-review 12345 detailed

使用 gh CLI 获取 PR 数据：

# 获取 PR 详情
gh pr view <PR_NUMBER> --json title,body,author,baseRefName,headRefName,files,additions,deletions,commits

# 获取 diff
gh pr diff <PR_NUMBER>

# 获取 PR 评论
gh pr view <PR_NUMBER> --json comments,reviews

本地分支模式

审查当前分支中尚未合并到 main 的变更：

/pr-review branch
/pr-review branch detailed

使用 git 命令获取分支变更：

# 获取当前分支名称
git branch --show-current

# 获取相比 main 变更的文件列表
git diff --name-only main...HEAD

# 获取相比 main 的完整 diff
git diff main...HEAD

# 获取分支的 commit 日志
git log main..HEAD --oneline

# 获取 diff 统计数据（变更文件数、新增/删除行数）
git diff --stat main...HEAD

对于本地分支审查：

  • “Summary”（摘要）部分应基于 commit 信息和 diff 阐述该分支变更的目的
  • 在审查标题中显示当前分支名称，而非 PR 编号
  • 其他所有审查标准与 PR 审查完全一致

GitHub Actions 模式

当通过 GitHub PR 上的 @claude /pr-review 触发时，Action 会预先拉取 PR 元数据并注入到 prompt 中。可以通过 prompt 中是否存在 <formatted_context>、<pr_or_issue_body> 和 <comments> 标签来识别此模式。

Prompt 中已包含：

  • PR 元数据（标题、作者、分支名称、新增/删除行数、文件数量）
  • PR 正文/描述
  • 所有评论与 review 意见（含文件/行号引用）
  • 变动文件列表及其路径和变更类型

使用 git 命令获取 diff 和 commit 历史。基准分支（base branch）名称可以在 prompt 上下文中找到（寻找 PR Branch: <head> -> <base> 或 baseBranch 字段）。

# 获取相比基准分支的完整 diff
git diff origin/<baseBranch>...HEAD

# 获取 diff 统计
git diff --stat origin/<baseBranch>...HEAD

# 获取此 PR 的 commit 历史
git log origin/<baseBranch>..HEAD --oneline

# 如果本地没有基准分支 ref，先 fetch 过来
git fetch origin <baseBranch> --depth=1

在此模式下请勿使用 gh CLI 命令——仅可使用 git 命令。所有 PR 元数据、评论和 review 已包含在 prompt 上下文中，只需通过 git 拉取 diff 和 commit 日志。

Review 理念

一行简单的代码也可能产生深远的影响：缺失 device guard 会在多 GPU 环境下导致静默数据损坏；遗漏 Composite dispatch key 会搞垮所有树外（out-of-tree）后端；手写 dtype 校验而非使用 TensorIterator 会静默绕过类型提升（type promotion）。请把每一行代码都当成可能承载关键逻辑（load-bearing）的节点来对待。

  1. 只报告问题 — Review 输出必须只包含问题、隐患和可落地的建议。不要提及写得对的地方，不要夸赞优秀决策，不要解释为什么某处没有问题。如果某个板块没有任何问题，直接完全省去。读者的宝贵时间不容浪费——每句话都必须指向需要修复或进一步讨论的内容。
  2. 深入调查，不要凭空猜测 — 如果不确定检查项（checklist）是否适用，可以派生子 Agent（sub-agent）去阅读相关代码。凭空猜错的 Reviewer 只会带来负价值。
  3. 审视设计，而不仅仅是实现 — 一个 PR 完全可能以极高水平的实现去完成一个烂设计。要对旁路通信（side-channel communication）、私有开关标志（on/off private flags）保持警惕，并要求为组件间的新契约提供具体的接口文档。
  4. 聚焦 CI 查不出来的盲区 — 别去纠结代码格式、lint 报错、类型错误或 CI 失败。把精力放在设计质量、接口正确性、线程安全、向下兼容性（BC）隐患、测试充分性以及设计模式一致性上。
  5. 所有问题都是必须修复的（Must-fix） — 这里没有所谓的“琐碎小事（nits）”。只要值得提，就值得改。每一处不一致随着时间推移都会侵蚀代码库。
  6. 明确且具有可操作性 — 引用具体的文件路径和行号。明确告诉作者应该使用哪个函数、类或文件。
  7. 契合上下文环境 — 看看同一个文件里类似的功能是怎么实现的。同一个文件内出现模式不匹配（Pattern mismatch）绝对是错的。
  8. 假定作者是专业人士 — 作者很懂 PyTorch；只解释那些非显而易见的背景信息。
  9. 绝不重复 — 每条观察意见只能出现在 Review 输出的某一个章节中，严禁重复。

使用子 Agent（Sub-agents）

Review 检查清单庞大繁杂。你不可能把每个基础设施系统的完整上下文全塞进脑子里。派生子 Agent 去调查检查项是否适用：阅读修改文件周围的代码、PR 应当使用的基础设施，或者应当补全的测试。对于独立的领域，可以并行派生。一个中等规模的 PR 通常需要派生 3 到 8 个子 Agent。

Review 工作流

第 1 步：理解上下文

在开始 Review 前，先搞清楚 PR 动了什么、为什么要动：

  1. 从标题/描述/Issue 中确定变更的目的
  2. 按类型对变更分类（新代码、测试、配置、文档）
  3. 梳理变更影响范围（受影响的文件、变更的行数）
  4. 派生子 Agent 阅读每个发生重大变更的文件周围未修改的代码，以理解现有的模式和基础设施

第 2 步：深度 Review

逐行审查 diff 中的每一行变更，并根据 review-checklist.md 中的检查清单进行评估。

第 3 步：检查向下兼容性（BC）

对照 bc-guidelines.md 评估向下兼容性影响。对于复杂的 BC 问题，派生子 Agent 去检索受修改 API 的现有调用方。

第 4 步：生成 Review 意见

按分类整理出具可操作性的反馈意见。每条结论都必须能追溯到 diff 中的具体行。

第 5 步：交叉验证（Fact-Check）

起草完 Review 意见后，针对报告的每个问题（并行）派生子 Agent，通过重新阅读相关代码和周边上下文进行独立验证。每个子 Agent 需返回 valid（有效）、invalid（无效）或 needs rewording（需重新表述）。剔除无效问题，重构表述。如果不确定，留下一条注释告知作者该项置信度较低。

输出格式

按如下结构组织你的 Review 意见。对于没有发现问题的板块，直接省略——大多数 Review 应该只包含少数几个板块。不要写“没有问题”、“看起来不错”或任何肯定的评语。Review 中的每一句话都必须指出问题或提出修改要求。

唯一例外的是 Summary（摘要）板块：用 1 句话简述 PR 做了什么，随后列出发现的问题，或者明确说明未发现问题。

## PR Review: #<number>
<!-- 或用于本地分支审查： -->
## Branch Review: <branch-name> (vs main)

### Summary
用 1 句话总结 PR 做了什么，随后给出整体评估结论。

### Code Quality
[仅列出发现的问题]

### Infrastructure
[仅列出发现的问题 — 标记违反检查清单的项目]

### Testing
[仅列出发现的问题 — 缺失测试、不当模式、覆盖率不足]

### API Design
[仅列出发现的问题]

### Security
[仅列出发现的问题]

### Thread Safety
[仅列出发现的问题]

### Backward Compatibility
[仅列出发现的问题]

### Performance
[仅列出发现的问题]

### Recommendation
**Approve** / **Request Changes** / **Needs Discussion**

缺失测试（新功能无测试、Bug 修复无回归测试）一律视为 **Request Changes**。

[简要说明理由 — 重点阐述阻止 Approve 的原因（如果有的话）]

具体评论（仅限 Detailed 深度审查模式）

仅在用户明确要求“detailed”或“in depth”审查时才包含此章节。

不要重复在其他板块中已提出的观察意见。 本章节用于提供无法归入上述分类板块的、针对特定文件的额外反馈。

当收到请求时，提供带有行号引用的特定文件反馈：

### Specific Comments
- `src/module.py:42` - 考虑将此逻辑提取为命名函数以提高可读性
- `test/test_feature.py:100-105` - 缺失针对输入为 None 时的异常情况测试
- `torch/nn/modules/linear.py:78` - 此处的内存分配可以移到循环体之外

参考文件

在进行审查时，请查阅这些项目文件以获取上下文——务必读取最新文件内容而非依赖记忆，因为它们变动频繁：

  • CLAUDE.md - 代码风格理念与测试模式
  • CONTRIBUTING.md - PR 要求与 Review 流程
  • torch/testing/_internal/common_utils.py - 测试模式与工具库
  • torch/testing/_internal/opinfo/core.py - OpInfo 测试框架
  • aten/src/ATen/native/native_functions.yaml - 算子声明（用于检查 tag、dispatch key、结构化 kernel）
  • tools/autograd/derivatives.yaml - 反向传播公式（用于检查算子是否应在此注册）
  • aten/src/ATen/native/tags.yaml - 算子语义 tag