Agent skill

pr-review

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".

View SKILL.md on GitHub Repository
Stars 98,726
Forks 27,372

Install this agent skill to your Project

npx add-skill https://github.com/pytorch/pytorch/tree/main/.claude/skills/pr-review

SKILL.md

PyTorch PR Review Skill

Review PyTorch pull requests focusing on what CI cannot check: code quality, test coverage adequacy, security vulnerabilities, and backward compatibility.

Usage Modes

No Argument

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)

Local CLI Mode

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:

bash
# 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

Local Branch Mode

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:

bash
# 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:

  • The "Summary" should describe what the branch changes accomplish based on commit messages and diff
  • Use the current branch name in the review header instead of a PR number
  • All other review criteria apply the same as PR reviews

GitHub Actions Mode

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:

  • PR metadata (title, author, branch names, additions/deletions, file count)
  • PR body/description
  • All comments and review comments (with file/line references)
  • List of changed files with paths and change types

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).

bash
# 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.

Review Philosophy

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.

  1. Investigate, don't guess — When uncertain whether a checklist item applies, spawn a sub-agent to read the relevant code. A reviewer who guesses wrong provides negative value.
  2. Review the design, not just the implementation — A PR can have perfectly correct implementation of a bad design. Question side-channel communication, on/off private flags, and demand concrete interface documentation for new contracts between components.
  3. Focus on what CI cannot check — Don't comment on formatting, linting, type errors, or CI failures. Focus on design quality, interface correctness, thread safety, BC implications, test adequacy, and pattern adherence.
  4. Everything is a must-fix — There are no "nits." If it's worth mentioning, it's worth fixing. Every inconsistency degrades the codebase over time.
  5. Be specific and actionable — Reference file paths and line numbers. Name the function/class/file the author should use.
  6. Match the immediate context — Read how similar features are already implemented in the same file. Pattern mismatches within a file are always wrong.
  7. Assume competence — The author knows PyTorch; explain only non-obvious context.
  8. No repetition — Each observation appears in exactly one section of the review output.

Using sub-agents

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.

Review Workflow

Step 1: Understand Context

Before reviewing, build understanding of what the PR touches and why:

  1. Identify the purpose of the change from title/description/issue
  2. Group changes by type (new code, tests, config, docs)
  3. Note the scope of changes (files affected, lines changed)
  4. Spawn sub-agents to read the unchanged code surrounding each significantly changed file to understand existing patterns and infrastructure

Step 2: Deep Review

Go through every changed line in the diff and evaluate it against the review checklist in review-checklist.md.

Step 3: Check Backward Compatibility

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.

Step 4: Formulate Review

Structure your review with actionable feedback organized by category. Every finding should be traceable to a specific line in the diff.

Output Format

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.

markdown
## 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]

Specific Comments (Detailed Review Only)

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:

markdown
### 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

Files to Reference

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 patterns
  • CONTRIBUTING.md - PR requirements and review process
  • torch/testing/_internal/common_utils.py - Test patterns and utilities
  • torch/testing/_internal/opinfo/core.py - OpInfo test framework
  • aten/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

Recommended Agent Skills

Expand your agent's capabilities with these related and highly-rated skills.

pytorch/pytorch

aoti-debug

Debug AOTInductor (AOTI) errors and crashes. Use when encountering AOTI segfaults, device mismatch errors, constant loading failures, or runtime errors from aot_compile, aot_load, aoti_compile_and_package, or aoti_load_package.

98,726 27,372
Explore
pytorch/pytorch

add-uint-support

Add unsigned integer (uint) type support to PyTorch operators by updating AT_DISPATCH macros. Use when adding support for uint16, uint32, uint64 types to operators, kernels, or when user mentions enabling unsigned types, barebones unsigned types, or uint support.

98,726 27,372
Explore
pytorch/pytorch

at-dispatch-v2

Convert PyTorch AT_DISPATCH macros to AT_DISPATCH_V2 format in ATen C++ code. Use when porting AT_DISPATCH_ALL_TYPES_AND*, AT_DISPATCH_FLOATING_TYPES*, or other dispatch macros to the new v2 API. For ATen kernel files, CUDA kernels, and native operator implementations.

98,726 27,372
Explore
pytorch/pytorch

metal-kernel

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.

98,726 27,372
Explore
pytorch/pytorch

scrub-issue

Fetch, analyze, reproduce, and minimize GitHub issue reproductions. Use when asked to check if an issue reproduces, minimize a repro, analyze a bug report, or scrub/triage an issue for reproducibility.

98,726 27,372
Explore
pytorch/pytorch

skill-writer

Guide users through creating Agent Skills for Claude Code. Use when the user wants to create, write, author, or design a new Skill, or needs help with SKILL.md files, frontmatter, or skill structure.

98,726 27,372
Explore

Didn't find tool you were looking for?

Be as detailed as possible for better results