PyTorch Pull Request Review

PyTorch Pull Request Review is an official skill in the PyTorch repository. It supports a human or agent-assisted examination of pull request changes and focuses on questions that an ordinary CI pipeline cannot fully answer. According to the provider, those questions include code quality, adequate test coverage, security vulnerabilities, and backward compatibility. The skill is a review playbook for the PyTorch context, not a merge bot, not a replacement for maintainers, and not a guarantee that a reviewed patch is defect-free. Its recommendations must be checked against the actual diff, unchanged surrounding code, and the current project rules.

Usage and context

The skill can be used with a pull request number, a GitHub URL, or a local branch. With no argument, it should first ask what the user wants reviewed. In normal local mode, the prescribed GitHub tools are used to inspect metadata, changed files, commits, the diff, and existing comments. In branch mode, the comparison with main and the commit history provide the context. In an automated GitHub Action, pull request metadata, description, comments, reviews, and the changed-file list may already be included in the prompt; in that case the diff should be obtained through the supplied Git references rather than assuming another retrieval path is available.

Review focus

According to the provider, every changed line should be considered together with its surrounding code. The focus is not formatting, linting, or failures already covered by CI, but design quality, interfaces, thread safety, device behavior, PyTorch infrastructure, test patterns, and effects on existing users. One missing device guard, an incorrect dispatch integration, or a manual type check can have broad consequences. Relevant project files such as CONTRIBUTING.md, CLAUDE.md, internal testing helpers, OpInfo structures, operator declarations, and autograd rules should be read when needed, because PyTorch conventions cannot be inferred from a filename alone.

Consolidation and reporting

The workflow recommends building context first, then reviewing every diff line deeply, checking backward compatibility, and consolidating observations before drafting the report. Findings with the same root cause or the same fix should become one finding. The report should contain only problems, concerns, and actionable requests. Each finding needs a traceable file and line reference together with a concrete recommendation. The suggested categories distinguish security, thread safety, backward compatibility, API design, infrastructure, testing, performance, and code quality. Missing tests for new functionality mean Request Changes under the specified output format.

Security boundaries and responsibility

A review agent can send source code, comments, and context to the connected model provider. Local repository inspection therefore does not automatically mean that all data remains with the local user. Credentials, private diffs, and confidential comments must be handled under the organization’s policies. The skill does not make pull request changes and does not replace permission checks or maintainer accountability. Recommendations can become stale when PyTorch infrastructure or review rules change. PyTorch publishes its source under BSD-3-Clause. This entry was reviewed on September 9, 2026 against the official skill file and the official PyTorch documentation. GitHub stars are not stored because the Skill model has no github_stars field.