Review PyTorch pull requests for code quality, test coverage, security, and backward compatibility...
Review PyTorch pull requests focusing on what CI cannot check: code quality, test coverage adequacy, security vulnerabilities, and backward compatibility.
If the user invokes /pr-review with no arguments, do not perform a review. Instead, ask the user what they would like to review:
What would you like me to review?
- A PR number or URL (e.g.,
/pr-review 12345)- A local branch (e.g.,
/pr-review branch)
The user provides a PR number or URL:
/pr-review 12345
/pr-review https://github.com/pytorch/pytorch/pull/12345
For a detailed review with line-by-line specific comments:
/pr-review 12345 detailed
Use gh CLI to fetch PR data:
# Get PR details
gh pr view <PR_NUMBER> --json title,body,author,baseRefName,headRefName,files,additions,deletions,commits
# Get the diff
gh pr diff <PR_NUMBER>
# Get PR comments
gh pr view <PR_NUMBER> --json comments,reviews
Review changes in the current branch that are not in main:
/pr-review branch
/pr-review branch detailed
Use git commands to get branch changes:
# Get current branch name
git branch --show-current
# Get list of changed files compared to main
git diff --name-only main...HEAD
# Get full diff compared to main
git diff main...HEAD
# Get commit log for the branch
git log main..HEAD --oneline
# Get diff stats (files changed, insertions, deletions)
git diff --stat main...HEAD
For local branch reviews:
When invoked via @claude /pr-review on a GitHub PR, the action pre-fetches PR
metadata and injects it into the prompt. Detect this mode by the presence of
<formatted_context>, <pr_or_issue_body>, and <comments> tags in the prompt.
The prompt already contains:
Use git commands to get the diff and commit history. The base branch name is in the
prompt context (look for PR Branch: <head> -> <base> or the baseBranch field).
# Get the full diff against the base branch
git diff origin/<baseBranch>...HEAD
# Get diff stats
git diff --stat origin/<baseBranch>...HEAD
# Get commit history for this PR
git log origin/<baseBranch>..HEAD --oneline
# If the base branch ref is not available, fetch it first
git fetch origin <baseBranch> --depth=1
Do NOT use gh CLI commands in this mode -- only git commands are available.
All PR metadata, comments, and reviews are already in the prompt context;
only the diff and commit log need to be fetched via git.
A single line of code can have deep cross-cutting implications: a missing device guard causes silent data corruption on multi-GPU, a missing Composite dispatch key breaks every out-of-tree backend, a manual dtype check instead of TensorIterator silently skips type promotion. Treat every line as potentially load-bearing.
The review checklist is large. You cannot hold the full context of every infrastructure system in your head. Spawn sub-agents to investigate whether checklist items apply: read surrounding code, infrastructure the PR should be using, or tests that should exist. Spawn them in parallel for independent areas. A typical medium PR should spawn 3-8 sub-agents.
Before reviewing, build understanding of what the PR touches and why:
Go through every changed line in the diff and evaluate it against the review checklist in review-checklist.md.
Evaluate BC implications per bc-guidelines.md. For non-trivial BC questions, spawn a sub-agent to search for existing callers of the modified API.
Structure your review with actionable feedback organized by category. Every finding should be traceable to a specific line in the diff.
After drafting the review, spawn a sub-agent per reported issue (in parallel) to independently verify the claim by re-reading the relevant code and surrounding context. Each sub-agent returns valid, invalid, or needs rewording. Drop invalid issues, reword the rest. If unsure, leave the issue with a comment for the author that this low confidence.
Structure your review as follows. Omit sections where you have no problems to report — most reviews should only have a few sections. Do not write "No concerns", "Looks good", or any affirmative commentary. Every sentence in the review must identify a problem or request a change.
The Summary section is the one exception: it should briefly state what the PR does (1 sentence) and then state the problems found, or explicitly say no issues were found.
## PR Review: #<number>
<!-- Or for local branch reviews: -->
## Branch Review: <branch-name> (vs main)
### Summary
What the PR does (1 sentence), then the overall verdict.
### Code Quality
[Problems only]
### Infrastructure
[Problems only — flag checklist items that are violated]
### Testing
[Problems only — missing tests, wrong patterns, inadequate coverage]
### API Design
[Problems only]
### Security
[Problems only]
### Thread Safety
[Problems only]
### Backward Compatibility
[Problems only]
### Performance
[Problems only]
### Recommendation
**Approve** / **Request Changes** / **Needs Discussion**
Missing tests (new functionality without tests, bug fixes without regression tests) always means **Request Changes**.
[Brief justification — focus on what blocks approval, if anything]
Only include this section if the user requests a "detailed" or "in depth" review.
Do not repeat observations already made in other sections. This section is for additional file-specific feedback that doesn't fit into the categorized sections above.
When requested, add file-specific feedback with line references:
### Specific Comments
- `src/module.py:42` - Consider extracting this logic into a named function for clarity
- `test/test_feature.py:100-105` - Missing test for error case when input is None
- `torch/nn/modules/linear.py:78` - This allocation could be moved outside the loop
When reviewing, consult these project files for context — read them rather than relying on memory, as they change frequently:
CLAUDE.md - Coding style philosophy and testing patternsCONTRIBUTING.md - PR requirements and review processtorch/testing/_internal/common_utils.py - Test patterns and utilitiestorch/testing/_internal/opinfo/core.py - OpInfo test frameworkaten/src/ATen/native/native_functions.yaml - Operator declarations (for checking tags, dispatch keys, structured kernels)tools/autograd/derivatives.yaml - Backward formulas (for checking if an op should register here)aten/src/ATen/native/tags.yaml - Operator semantic tags