// Review PyTorch pull requests for code quality, test coverage, security, and backward compatibility. Use when reviewing PRs, when asked to review code changes, or when the user mentions "review PR", "code review", or "check this PR".
| name | pr-review |
| description | Review PyTorch pull requests for code quality, test coverage, security, and backward compatibility. Use when reviewing PRs, when asked to review code changes, or when the user mentions "review PR", "code review", or "check this PR". |
Review PyTorch pull requests focusing on what CI cannot check: code quality, test coverage adequacy, security vulnerabilities, and backward compatibility. Linting, formatting, type checking, and import ordering are handled by CI.
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.
Do not skim. Do not summarize the diff and move on. Read every changed line and ask: does this interact with existing PyTorch infrastructure that the author may not know about? When uncertain, investigate — spawn a sub-agent to read the surrounding code, the infrastructure the PR should be using, or the tests that should exist. The cost of a false negative (missing a real issue) is much higher than the cost of investigation.
Local CLI mode: Use gh commands to get PR metadata, changed files, full diff,
existing comments/reviews, and associated issue information.
Local Branch mode: Use git diff and git log against main as shown in the
Local Branch Mode section above.
GitHub Actions mode: PR metadata, comments, and reviews are already in the prompt.
Use git diff origin/<baseBranch>...HEAD for the full diff and
git log origin/<baseBranch>..HEAD --oneline for the commit log.
Before reviewing, build understanding of what the PR touches and why:
This is the core of the review. Go through every changed line in the diff and evaluate it against the review checklist in review-checklist.md.
How to use sub-agents during review:
The checklist is large. You cannot hold the full context of every infrastructure system in your head. Instead, when you encounter a changed line that touches a checklist area, spawn a sub-agent to investigate whether the checklist item applies. For example:
Spawn sub-agents in parallel for independent investigation areas. A typical review of a medium PR should spawn 3-8 sub-agents. Large PRs touching multiple subsystems may need more.
Checklist areas (see review-checklist.md for full details):
Evaluate BC implications. See bc-guidelines.md for:
For non-trivial BC questions (e.g., "does changing this default break downstream users?"), 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 and a specific checklist item.
| Area | Focus | Reference |
|---|---|---|
| Code Quality | Abstractions, patterns, complexity | review-checklist.md |
| API Design | New patterns, flag-based access, broader implications | review-checklist.md |
| C++ Kernels | TensorIterator, DispatchStub, AT_DISPATCH, structured kernels, device guards, memory format | review-checklist.md |
| CUDA/Device | C10_CUDA_CHECK, stream/event guards, recordStream, CUDA graphs, AcceleratorHooks | review-checklist.md |
| Op Registration | native_functions.yaml, Composite fallback, meta/fake impls, tags, schema annotations | review-checklist.md |
| Autograd | derivatives.yaml, autograd.Function patterns, gradcheck, forward-mode AD, vmap | review-checklist.md |
| Python Utils | torch_function, pytree, logging, deprecation, backends context | review-checklist.md |
| nn Modules | ModuleList/Dict, nn.init, parametrize, state_dict versioning, LazyModule | review-checklist.md |
| Dynamo/Inductor | @register_lowering, decompositions, CustomGraphPass, config.patch, graph breaks | review-checklist.md |
| FX/Export | PassBase, PassManager, Interpreter, subgraph rewriter, ShapeProp, make_fx | review-checklist.md |
| Type Promotion | elementwise_dtypes, TensorIterator dtype handling, result_type, promoteTypes | review-checklist.md |
| Serialization | weights_only, safe_globals, skip_data | review-checklist.md |
| Distributed | DeviceMesh, distributed testing with MultiThreadedPG | review-checklist.md |
| Tensor Subclasses | _make_wrapper_subclass, tensor_flatten/unflatten | review-checklist.md |
| Testing | OpInfo, ModuleInfo, device-generic, @dtypes, @parametrize, make_tensor | review-checklist.md |
| Security | Injection, credentials, input handling | review-checklist.md |
| Performance | Regressions, device handling, memory, profiling, benchmarking | review-checklist.md |
| Thread Safety | Data races, GIL assumptions, NoGIL, CPython C API | review-checklist.md |
| BC | Breaking changes, deprecation | bc-guidelines.md |
Structure your review as follows. Omit sections where you have no findings — don't write "No concerns" for every empty section. Only include sections with actual observations.
## PR Review: #<number>
<!-- Or for local branch reviews: -->
## Branch Review: <branch-name> (vs main)
### Summary
Brief overall assessment of the changes (1-2 sentences).
### Code Quality
[Issues and suggestions]
### Infrastructure
[Flag any checklist items from the PyTorch Infrastructure section that apply.
Reference the specific infrastructure the PR should be using.]
### Testing
[Testing adequacy findings — missing OpInfo usage, non-device-generic tests, etc.]
### API Design
[Flag new patterns, internal-access flags, or broader implications if any.]
### Security
[Issues if any]
### Thread Safety
[Threading concerns if any]
### Backward Compatibility
[BC concerns if any]
### Performance
[Performance concerns if any]
### Recommendation
**Approve** / **Request Changes** / **Needs Discussion**
[Brief justification for recommendation]
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
C10_CUDA_KERNEL_LAUNCH_CHECK(), a single weights_only=False, a single missing Composite dispatch key — each of these is a real bug that affects real users. Do not skip lines.When reviewing, consult these project files for context. Spawn sub-agents to read these rather than relying on memory — the files 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 tagsTriages GitHub issues by routing to oncall teams, applying labels, and closing questions. Use when processing new PyTorch issues or when asked to triage an issue.
Debug PyTorch 2 compiler stack failures including Dynamo graph breaks, Inductor codegen errors, AOTAutograd crashes, and accuracy mismatches. Use when encountering torch.compile errors, BackendCompilerFailed exceptions, recompilation issues, Triton kernel failures, FX graph problems, or when the user mentions debugging PT2, Dynamo, Inductor, or compiled model issues.
Document undocumented public APIs in PyTorch by removing functions from coverage_ignore_functions and coverage_ignore_classes in docs/source/conf.py, running Sphinx coverage, and adding the appropriate autodoc directives to the correct .md or .rst doc files. Use when a user asks to remove functions from conf.py ignore lists.
Migrate a file to use stricter Pyrefly type checking with annotations required for all functions, classes, and attributes.
Write Metal/MPS kernels for PyTorch operators. Use when adding MPS device support to operators, implementing Metal shaders, or porting CUDA kernels to Apple Silicon. Covers native_functions.yaml dispatch, host-side operators, and Metal kernel implementation.