TR

triaging-issues

GitHub issue triage automation for routing and labeling.

Install

mkdir -p .claude/skills/triaging-issues && curl -L -o skill.zip "https://agentskills.codes/api/skills/download/525" && unzip -o skill.zip -d .claude/skills/triaging-issues && rm skill.zip

Installs to .claude/skills/triaging-issues

Activation

This is the description your AI agent reads to decide when to run this skill — the better it matches your request, the more reliably it fires.

Triages GitHub issues by routing to oncall teams, applying labels, and closing questions. Use when processing new PyTorch issues or when asked to triage an issue.
162 chars✓ has a “when” trigger
Intermediate

Key capabilities

  • Routes issues to appropriate oncall teams
  • Validates labels against the approved registry
  • Automates first-line responses using templates
  • Applies triage status labels to GitHub issues
  • Transfers issues to secondary teams when necessary

How it works

Executes predefined scripts that interact with GitHub APIs to validate labels and process issue metadata according to a strict project rubric.

Inputs & outputs

You give it
Issue URL or ID
You get back
Labeled issue with automated team routing and response

When to use triaging-issues

  • Label new GitHub issues
  • Route issues to appropriate oncall teams
  • Close stale or duplicate questions
  • Validate issue triage labels

About this skill

PyTorch Issue Triage Skill

This skill helps triage GitHub issues by routing issues, applying labels, and leaving first-line responses.

Contents

  • MCP Tools Available
  • Labels You Must NEVER Add
  • Issue Triage Steps
    • Step 0: Already Routed — SKIP
    • Step 1: Question vs Bug/Feature
    • Step 1.5: Needs Reproduction — External Files
    • Step 2: Transfer
    • Step 2.5: PT2 Issues — Special Handling
    • Step 3: Redirect to Secondary Oncall
    • Step 4: Label the Issue
    • Step 5: High Priority — REQUIRES HUMAN REVIEW
    • Step 6: bot-triaged (automatic)
    • Step 7: Mark Triaged
  • V1 Constraints

Labels reference: See labels.json for the full catalog of labels suitable for triage. ONLY apply labels that exist in this file. Do not invent or guess label names. This file excludes CI triggers, test configs, release notes, deprecated labels, and labels requiring human decision.

PT2 triage guide: See pt2-triage-rubric.md for detailed labeling guidance when triaging PT2/torch.compile issues.

Response templates: See templates.json for standard response messages.


MCP Tools Available

Use these GitHub MCP tools for triage:

ToolPurpose
mcp__github__issue_readGet issue details, comments, and existing labels
mcp__github__issue_writeApply labels or close issues
mcp__github__add_issue_commentAdd comment (only for redirecting questions)
mcp__github__search_issuesFind similar issues for context

Labels You Must NEVER Add

Prefix/CategoryReason
Labels not in labels.jsonOnly apply labels that exist in the allowlist
ciflow/*CI job triggers for PRs only
test-config/*Test suite selectors for PRs only
release notes: *Auto-assigned for release notes
ci-*, ci:*CI infrastructure controls
sev*Severity labels require human decision
merge blockingRequires human decision
actionable, needs design, needs reproduction, needs researchReserved for human reviewers after they have reviewed the issue
Any label containing "deprecated"Obsolete
oncall: relengNot a triage redirect target. Use module: ci instead

If blocked: When a label is blocked by the hook, add ONLY triage review and stop. A human will handle it.

These rules are enforced by a PreToolUse hook that validates all labels against labels.json.

Never Override Human Labels

If a human has already applied labels (especially ci: sev, severity labels, or priority labels), do NOT remove or replace them. Your job is to supplement, not override.


Issue Triage (for each issue)

0) Already Routed — SKIP

If an issue already has ANY oncall: label, SKIP IT entirely. Do not:

  • Add any labels
  • Add triaged
  • Leave comments
  • Do any triage work

That issue belongs to the sub-oncall team. They own their queue.

1) Question vs Bug/Feature

  • If it is a question (not a bug report or feature request): close and use the redirect_to_forum template from templates.json.
  • If unclear whether it is a bug/feature vs a question: request additional information using the request_more_info template and stop.

1.5) External Files

Check if the issue body contains links to external files that users would need to download to reproduce.

Patterns to detect:

  • File attachments: .zip, .pt, .pth, .pkl, .safetensors, .onnx, .bin files
  • External storage: Google Drive, Dropbox, OneDrive, Mega, WeTransfer links
  • Model hubs: Hugging Face Hub links to model files

Action:

  1. Edit the issue body to remove/redact the download links
    • Replace with: [Link removed - external file downloads are not permitted for security reasons]
  2. Use the request_self_contained_reproduction template from templates.json
  3. Do NOT add triaged — wait for the user to provide a reproducible example

1.55) Missing Reproduction — Other Cases

Request a self-contained reproduction and stop when:

  • The user reports a hardware-specific issue (e.g., specific GPU model) without a self-contained repro script
  • The user references a specific model/checkpoint/dataset that is not publicly runnable in a few lines
  • The issue describes version-upgrade breakage but only provides a high-level description without a minimal script
  • The repro depends on a specific training setup, distributed environment, or non-trivial infrastructure

1.6) Edge Cases & Numerical Accuracy

If the issue involves extremal values or numerical precision differences:

Patterns to detect:

  • Values near torch.finfo(dtype).max or torch.finfo(dtype).min
  • NaN/Inf appearing in outputs from valid (but extreme) inputs
  • Differences between CPU and GPU results
  • Precision differences between dtypes (e.g., fp32 vs fp16)
  • Fuzzer-generated edge cases

IMPORTANT — avoid keyword-triggered mislabeling:

Label based on the root cause, not keywords that appear in the error or title. A keyword tells you what failed, not why.

  • An undefined symbol: ncclAlltoAll error at import torch is a packaging issue (module: binaries), not a distributed training bug — the user never ran distributed code.
  • A nan in a parameter name or tolerance check is not module: NaNs and Infs unless the bug is actually about NaN propagation.
  • A stack trace mentioning autograd does not mean module: autograd — check whether the bug is in autograd itself or just on the call path.
  • A test failure with tolerance thresholds is module: tests, not module: numerical-stability.

Ask: "Where would the fix need to be made?" That determines the label.

Action:

  1. Add module: edge cases label
  2. If from a fuzzer, also add topic: fuzzer
  3. Use the numerical_accuracy template from templates.json to link to the docs
  4. If the issue is clearly expected behavior per the docs, close it with the template comment

2) Transfer (domain library or ExecuTorch)

If the issue belongs in another repo (vision/text/audio/RL/ExecuTorch/etc.), transfer the issue and STOP.

2.5) PT2 Issues — Special Handling

PT2 is NOT a redirect. oncall: pt2 is not like the other oncall labels in Step 3. PT2 issues continue through Steps 4–7 for full triage — add oncall: pt2, then proceed to label with module: labels, mark triaged, etc.

Every oncall: pt2 issue MUST have at least one module: label. The PT2 oncall queue is too broad without a module label — the team needs to know which component is affected (e.g., module: dynamo, module: inductor, module: helion, module: dynamic shapes). If you cannot determine the specific module, use module: compile ux as a fallback, but always try to be specific first. See pt2-triage-rubric.md for detailed guidance.

3) Redirect to Secondary Oncall

CRITICAL: When redirecting issues to a non-PT2 oncall queue, apply exactly one oncall: ... label and STOP. Do NOT:

  • Add any module: labels
  • Mark it triaged
  • Do any further triage work

The sub-oncall team will handle their own triage. Your job is only to route it to them.

Oncall Redirect Labels

LabelWhen to use
oncall: jitTorchScript issues
oncall: distributedDistributed training (DDP, FSDP, RPC, c10d, DTensor, DeviceMesh, symmetric memory, context parallel, pipelining). Special handling: after applying this label, invoke the distributed triage sub-skill (/distributed-triage on this issue) for second-level triage — it will route to a sub-oncall, add module labels, and mark triaged.
oncall: exporttorch.export issues
oncall: quantizationQuantization issues
oncall: mobileMobile (iOS/Android), excludes ExecuTorch
oncall: profilerProfiler issues (CPU, GPU, Kineto)
oncall: visualizationTensorBoard integration

Common routing mistakes to avoid:

  • MPS ≠ Mobile. MPS (Metal Performance Shaders) is the macOS/Apple Silicon GPU backend. Do NOT route MPS issues to oncall: mobile. MPS issues stay in the general queue with module: mps.
  • DTensor → oncall: distributed. DTensor issues should always be routed to oncall: distributed, even if they don't mention DDP/FSDP.
  • ONNX → module: onnx. There is no oncall: onnx. Use module: onnx and keep in the general queue.
  • CI/releng → module: ci. Do not use oncall: releng. Use module: ci for CI infrastructure issues.
  • torch.compile + distributed. When torch.compile mishandles a distributed op (e.g., dist.all_reduce), the issue typically needs BOTH oncall: pt2 and oncall: distributed since the fix may span both codebases.

Note: oncall: cpu inductor is a sub-queue of PT2. For general triage, just use oncall: pt2.

4) Label the issue (if NOT transferred/redirected)

Only if the issue stays in the general queue:

  • Add 1+ module: ... labels based on the affected area
  • Prefer specific labels over general ones when both exist. Check labels.json descriptions for guidance on when a specific label supersedes a general one (e.g., module: sdpa instead of module: nn for SDPA issues, module: flex attention instead of module: nn for flex attention).
  • feature — wholly new functionality that does not exist today in any form
  • enhancement — improvement to something that already works (e.g., adding a native backend kernel for an op that already runs via fallback/composite, performance optimization, better error messages). If the enhancement is about performance, also add module: performance.
  • function request — a new function or new arguments/modes for an existing function
  • If the issue says the operation "currently works" or "falls back to" a slower path, that is enhancement, no

Content truncated.

When not to use it

  • For managing non-GitHub issue trackers
  • When an issue requires urgent human intervention before any bot activity

Prerequisites

GitHub accountGitHub API access

Limitations

  • Limited to the predefined labels in labels.json
  • Does not automate the actual code fix for bug reports
  • Strictly follows defined triage steps, limiting flexibility for edge-case issues

How it compares

It enforces institutional labeling compliance rather than allowing arbitrary label usage.

Compared to similar skills

triaging-issues side by side with the closest alternatives in the catalog.

SkillInstallsUpdatedSafetyDifficulty
triaging-issues (this skill)52moReviewIntermediate
jira116moNo flagsBeginner
landing03moNo flagsBeginner
ck01moReviewBeginner

Try saying

Example prompts that trigger this skill in your AI assistant.

Search skills

Search the agent skills registry