PyTorch Issue Triage

PyTorch Issue Triage is an official skill in the PyTorch repository. It helps maintainers and on-call teams review GitHub issues through a defined sequence, identify the responsible area, choose permitted labels, and prepare an appropriate next step. According to the provider, the skill is intended for processing new PyTorch issues and covers routing, requests for more information, label selection, and recording completed triage. It is not a ticketing system, an autonomous root-cause analyzer, or a promise that a single model response can replace a maintainer’s judgment.

Workflow and input context

The process starts with the complete issue and its existing labels. According to the provider, an issue carrying any on-call label is skipped because it already belongs to a responsible queue. For questions that are not bug reports or feature requests, the workflow calls for a forum redirect and closure with an approved response template. When the situation is ambiguous, the next step is to request additional information. The skill also distinguishes external files and cases that cannot yet be reproduced. Links to downloadable files or model artifacts should be removed for security reasons, while the reporter is asked for a self-contained reproduction. A hardware-specific problem, a model that cannot be run publicly, or a complex distributed setup may likewise require a reproduction before further classification.

Routing and domain labels

For issues belonging to another PyTorch project, the skill describes transferring the issue to the appropriate repository. It lists specialized on-call destinations for areas such as JIT, Distributed, Export, Quantization, Mobile, Profiler, and Visualization. PT2 is explicitly handled differently: the oncall: pt2 label does not end general triage; it requires a suitable module label and further steps. The documentation calls out common routing mistakes. MPS is not Mobile, DTensor belongs with Distributed, and ONNX receives a module label rather than an unsupported on-call destination. The affected code area should be inferred by asking where a fix would need to be made, not by reacting to one keyword in a stack trace or issue title.

Safety and decision boundaries

According to the provider, only labels present in the label reference may be applied. CI controls, deprecated labels, human-reserved severity labels, and unsupported on-call names must not be invented or added. Human-applied labels are not overridden. For segfaults, silent correctness problems, regressions, internal assertions, or issues affecting many users, the workflow first calls for triage review and human confirmation; high priority must not be assigned independently. The skill also separates security, privacy, and data-exposure risks from ordinary routing work. Updating issues, adding comments, transferring issues, and closing them are external actions that require checking the repository, issue number, permissions, and current context before execution. The supplied hooks validate targets and labels, but they do not replace accountable human review.

Practical value and limitations

The skill is useful as a consistent checklist for a large open-source project with many modules and specialized teams. It can help new maintainers avoid missing established routing rules and preserve the intended order of decisions. It only knows the information available through the connected GitHub context, however. Similar issues, reproductions, external files, and current ownership must actually be checked. Labels can change, so labels.json and the other reference files in the same source revision remain authoritative. PyTorch publishes its source under the BSD-3-Clause license. This entry was reviewed on September 9, 2026 against the official skill file and the official PyTorch documentation site. It describes the provider’s stated scope, not a guarantee of correct triage, availability, or security in every environment. GitHub stars are not stored because the Skill model has no github_stars field.