Set up PyTorch Pull Request Review safely

What the PyTorch pull-request review skill is and why it matters

The skill named pr-review comes directly from the official PyTorch repository on GitHub, located at .claude/skills/pr-review/SKILL.md. It helps evaluate pull requests within the PyTorch project systematically, with an explicit focus on aspects that an automated continuous-integration pipeline cannot check: code quality, adequacy of test coverage, security vulnerabilities, and backward compatibility. A pull request, commonly abbreviated PR, is in everyday software development a proposal to merge changes from a development branch into a project's main branch, and having experienced colleagues review such proposals is a central part of professional software quality assurance. According to the skill's description, it activates whenever a user asks for a PR review, mentions a PR number or URL, or uses phrasing such as review this PR. What stands out about this skill in particular is its explicit review philosophy: it is meant to report only problems and never praise correctly implemented code, because, in the vendor's own words, the reader's time is precious and every sentence should point to something actionable. For a project the size of PyTorch, with thousands of contributions per year, a structured, consistent review aid like this is a significant lever for keeping quality uniform across all submissions.

Prerequisites

For the skill to function you first need a working Git installation and, depending on the mode, the GitHub CLI, since in its local command-line mode the skill relies on the gh tool to fetch PR metadata, diffs, and comments. For reviewing a local branch without an existing PR, plain Git commands such as git diff and git log against the main branch are sufficient instead. According to the skill's description there is also a third operating mode for GitHub Actions, in which PR metadata is already injected into the prompt beforehand and only Git commands, not the gh CLI, may be used. In terms of substance, the skill assumes the user has access to the PyTorch repository and is familiar with its project conventions, since it explicitly points to project-specific files such as CLAUDE.md, CONTRIBUTING.md, or the operator declaration file native_functions.yaml, which it expects to be read for a well-founded assessment.

Step-by-step setup

Usage begins with choosing the right mode: if the skill is invoked without an argument, it first asks specifically what should be reviewed rather than guessing blindly. The actual review then runs through a multi-stage process. In the first step, the skill builds an understanding of the context by deriving the purpose of the change from the title and description, deploying sub-agents in parallel to read the surrounding, unchanged code and understand existing patterns. According to the vendor, a medium-sized PR should typically spawn three to eight such sub-agents. In the second step, every changed line is evaluated against a detailed checklist maintained in a separate reference file. In the third step, the skill specifically evaluates backward compatibility and, for unclear cases, deploys further sub-agents that search for existing callers of the modified interface. In the fourth step, all findings are consolidated, meaning observations that share the same root cause or the same fix are merged into a single finding to avoid redundancy. In the fifth and final step, every surviving finding is independently fact-checked by its own sub-agent, which classifies it as valid, invalid, or needing rewording, before the final review document is produced.

Security and best practices

Because code reviews require access to source code that can itself be security-sensitive, the skill should only be used in environments where repository access is already properly authorized, for example within a GitHub Actions pipeline with appropriately scoped permissions or in a local development environment using a personal GitHub token. The skill itself also treats security as its own review category and, per its defined precedence, assigns it the very highest priority ahead of backward compatibility or API design whenever a single finding touches multiple categories at once. Also notable is the rule that missing tests for new functionality or for bug fixes must always, according to the skill, result in a Request Changes recommendation, which represents a deliberate quality gate against insufficiently validated changes. Anyone adapting the skill for their own projects should be aware of these strict, undiplomatic evaluation rules, since they are deliberately designed so that every sentence in the output points to a concrete problem rather than containing generic, well-meaning praise.

Practical example and limits

A practical example straight from the skill's own documentation illustrates the standard it sets: a missing device guard can, according to the vendor, cause silent data corruption in multi-GPU operation, a missing Composite dispatch key breaks every out-of-tree backend, and a manual dtype check used instead of TensorIterator can silently skip a necessary type promotion. Failure modes this deeply rooted in PyTorch's architecture show why the skill is designed to be project-specific rather than generically applicable to arbitrary software projects. That is also exactly where its limits lie: anyone transplanting it unchanged into a different project loses the connection to PyTorch-specific concepts such as dispatch keys, the OpInfo test framework, or backward formulas in derivatives.yaml, which is why the referenced files and evaluation criteria need to be adapted to the target project. For PyTorch itself, and for projects with a similarly complex, multi-layered system architecture, however, the skill offers a thoughtful blueprint for combining careful human-style review with AI-assisted consolidation and fact-checking.