/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".
$ npx -y skills add pytorch/pytorch --skill pr-review --agent claude-codeHow it fires
How this skill gets triggered: by you, by Claude, or both.
- Fires itselfAuto-invocation. Claude auto-loads it when your prompt matches the work.Auto-invocation is when the right skill fires by itself at the right moment, driven by a FLOW.md router and a hook, instead of you invoking it by name. It is the difference between a skill being installed and a skill actually getting used.Read the full definition →
- You can call itInvoke it directly when you want it.
- Slash command
/pr-review
Context preview
The summary Claude sees to decide when to auto-load this skill.
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".
SKILL.md
pr-review.SKILL.mdname: 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".
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:
# 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:
# 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).
# 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. **Only report problems** — The review output must contain only issues, concerns, and actionable suggestions. Do NOT mention things that are done correctly, do NOT praise good decisions, do NOT explain why something is fine. If a section has no problems, omit it entirely. The reader's time is precious — every sentence must point to something that needs fixing or further discussion. 2. **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. 3. **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. 4. **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. 5. **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. 6. **Be specific and actionable** — Reference file paths and line numbers. Name the function/class/file the author should use. 7. **Match the immediate context** — Read how similar features are already implemented in the same file. Pattern mismatches within a file are always wrong. 8. **Assume competence** — The author knows PyTorch; explain only non-obvious context. 9. **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-ag
Read more
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".
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:
# 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:
# 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).
# 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. **Only report problems** — The review output must contain only issues, concerns, and actionable suggestions. Do NOT mention things that are done correctly, do NOT praise good decisions, do NOT explain why something is fine. If a section has no problems, omit it entirely. The reader's time is precious — every sentence must point to something that needs fixing or further discussion. 2. **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. 3. **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. 4. **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. 5. **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. 6. **Be specific and actionable** — Reference file paths and line numbers. Name the function/class/file the author should use. 7. **Match the immediate context** — Read how similar features are already implemented in the same file. Pattern mismatches within a file are always wrong. 8. **Assume competence** — The author knows PyTorch; explain only non-obvious context. 9. **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-ag
Tensors and Dynamic neural networks in Python with strong GPU acceleration
Other skills on 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.
Open skill - /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.
Open skill - /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.
Open skill - /ci-metrics
Query PyTorch CI, GitHub Actions, HUD, Grafana, and infrastructure metrics. Use when users ask about CI duration, job failures, queue times, workflow trends, runner health, dashboard data, or PyTorch infrastructure metrics.
Open skill - /cuda-index-width
Choose 32-bit vs 64-bit index math in PyTorch CUDA kernels. Use when fixing large-tensor indexing overflows, deciding whether to use int64_t, canUse32BitIndexMath, CUDA_KERNEL_LOOP_TYPE, or AT_DISPATCH_INDEX_TYPES, and when considering binary-size or performance impact of
Open skill - /distributed-triage
Sub-triages issues in the oncall:distributed queue by assigning distributed module labels, routing to sub-oncalls, and marking triaged. Use when an issue has been routed to oncall:distributed and needs second-level triage.
Open skill