/scrub-issue
Fetch, analyze, reproduce, and minimize GitHub issue reproductions. Use only when the user asks to check whether a GitHub issue reproduces, minimize a GitHub issue's repro, analyze a GitHub bug report, or scrub/triage a GitHub issue for reproducibility. Do not use for standalone
$ npx -y skills add pytorch/pytorch --skill scrub-issue --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
/scrub-issue
Context preview
The summary Claude sees to decide when to auto-load this skill.
Fetch, analyze, reproduce, and minimize GitHub issue reproductions. Use only when the user asks to check whether a GitHub issue reproduces, minimize a GitHub issue's repro, analyze a GitHub bug report, or scrub/triage a GitHub issue for reproducibility. Do not use for standalone
SKILL.md
scrub-issue.SKILL.mdname: scrub-issue
disable-model-invocation: true
description: Fetch, analyze, reproduce, and minimize GitHub issue reproductions. Use only when the user asks to check whether a GitHub issue reproduces, minimize a GitHub issue's repro, analyze a GitHub bug report, or scrub/triage a GitHub issue for reproducibility. Do not use for standalone reproduction requests without a GitHub issue.
Minimize Issue Reproduction
Fetch a GitHub issue, evaluate whether it has a reasonable repro, check if it still reproduces, and systematically minimize the repro to the smallest possible self-contained script.
Tools
Assume the current environment is correct and run `python` directly. Only use `conda run -n <env>` for version bisection (step 5a) where you need to temporarily use a different environment. Use the Bash tool's `timeout` parameter to enforce timeouts when running repro scripts.
- `gh issue view <NUMBER> --repo pytorch/pytorch` to fetch the issue body
- `gh issue view --comments <NUMBER> --repo pytorch/pytorch` to fetch comments
- `python <script>` to run repro scripts
- `gh issue comment <NUMBER> --repo pytorch/pytorch --body <BODY>` to comment
- `gh issue edit <NUMBER> --repo pytorch/pytorch --add-label <LABEL>` to add labels
Multiple `gh issue edit` flags can be combined in a single command (e.g. `--add-label "bug,help wanted" --add-assignee "@me"`). Prefer batching edits into one command to minimize API calls and reduce the chance of auto-subscribing to notifications.
Preserving notification subscription state
Modifying an issue (commenting, adding labels) auto-subscribes you to notifications. Use `tools/stale_issues.py` to save and restore subscription state:
1. **Before the first modification**, save the current state. This can be run in parallel with fetching the issue body/comments, but it must **complete** before any `gh issue edit`, `gh issue comment`, or `gh issue close` command is executed:
python tools/stale_issues.py subscription save <NUMBER>
2. **After the last modification**, restore the saved state — **unless the issue was closed** (via `gh issue close`), in which case skip the restore so the user stays subscribed to follow any responses to the closure. The restore must be the very last GitHub API call — do not run it in the background or in parallel with any `gh issue edit` or `gh issue comment` commands:
python tools/stale_issues.py subscription restore <NUMBER>
If either the save or restore command fails, warn the user and continue without the save/restore mechanism.
**Important**: Never run `gh issue edit`, `gh issue comment`, `gh issue close`, or subscription save/restore commands in the background. These must all run in the foreground so their completion can be verified before proceeding. If commenting or editing fails because the issue is locked, report this to the user and skip the modification.
Security review checklist
Before running any repro code, check for the following concerns:
- Network requests to untrusted URLs (requests, urllib, curl, wget)
- File operations outside `/tmp/`
- Shell command execution (os.system, subprocess, eval, exec) — but
`subprocess` used to launch `torchrun` or `mp.spawn` for distributed repros is expected and not a concern
- Downloading or loading external files (model weights, pickled objects, data
files) — especially `torch.load` on untrusted `.pt`/`.pth` files
- Obfuscated code (base64-encoded strings, encoded bytes, unusual escapes)
- Package installation (pip install, conda install)
- Environment variable manipulation that could affect the host system — but
setting `MASTER_ADDR`, `MASTER_PORT`, `RANK`, `WORLD_SIZE`, `CUDA_VISIBLE_DEVICES`, or other standard PyTorch/CUDA env vars is expected and not a concern
If any of these are present, explain the concern to the user and ask whether to proceed, skip, or modify the repro to remove the risky parts. If the user chooses to skip, still refresh the `triaged` label timestamp (remove and re-add, or just add if not present) before reporting that the analysis is finished.
Even if the repro passes the checklist above, check whether the author of the repro code is a PyTorch collaborator by running `python tools/stale_issues.py collaborator-check <username>`. If the command exits with a non-zero status (user is not a collaborator), show the repro code to the user and ask them to verify it is safe to run before executing it.
Steps
1) Fetch the issue
Fetch the issue body and comments in parallel. Identify the reported repro script and error. If multiple repros are present, prefer the most recent one from the original poster. If a commenter has posted a strictly shorter and more self-contained repro that doesn't require additional context from the issue description, prefer that one. Note which repro you selected. If the repro code is only present in screenshots or images rather than copyable text, stop and report this to the user.
2) Check if the issue is actionable
Before investing effort in reproduction, check whether the issue is actionable. **Do not proceed to later steps** if any of the following apply:
- **Already closed or resolved** in comments. Report to the user and stop.
Do not modify labels on closed issues.
- **Duplicate** of another issue (linked or obviously the same bug)
- **Not a bug report** (feature request, question, discussion, refactoring /
code cleanup task). If the issue is a feature request and doesn't already have the `feature` label, add it via `gh issue edit`. If the issue is a better-engineering / refactoring task and doesn't already have the `better-engineering` label, add it via `gh issue edit`. If the issue includes a repro script that demonstrates the current behavior, apply the security review checklist first, then run it to verify the behavior persists. If the repro needed to be modernized (e.g. updated imports for renamed AP
Read more
name: scrub-issue disable-model-invocation: true description: Fetch, analyze, reproduce, and minimize GitHub issue reproductions. Use only when the user asks to check whether a GitHub issue reproduces, minimize a GitHub issue's repro, analyze a GitHub bug report, or scrub/triage a GitHub issue for reproducibility. Do not use for standalone reproduction requests without a GitHub issue.
Minimize Issue Reproduction
Fetch a GitHub issue, evaluate whether it has a reasonable repro, check if it still reproduces, and systematically minimize the repro to the smallest possible self-contained script.
Tools
Assume the current environment is correct and run `python` directly. Only use `conda run -n <env>` for version bisection (step 5a) where you need to temporarily use a different environment. Use the Bash tool's `timeout` parameter to enforce timeouts when running repro scripts.
- `gh issue view <NUMBER> --repo pytorch/pytorch` to fetch the issue body
- `gh issue view --comments <NUMBER> --repo pytorch/pytorch` to fetch comments
- `python <script>` to run repro scripts
- `gh issue comment <NUMBER> --repo pytorch/pytorch --body <BODY>` to comment
- `gh issue edit <NUMBER> --repo pytorch/pytorch --add-label <LABEL>` to add labels
Multiple `gh issue edit` flags can be combined in a single command (e.g. `--add-label "bug,help wanted" --add-assignee "@me"`). Prefer batching edits into one command to minimize API calls and reduce the chance of auto-subscribing to notifications.
Preserving notification subscription state
Modifying an issue (commenting, adding labels) auto-subscribes you to notifications. Use `tools/stale_issues.py` to save and restore subscription state:
1. **Before the first modification**, save the current state. This can be run in parallel with fetching the issue body/comments, but it must **complete** before any `gh issue edit`, `gh issue comment`, or `gh issue close` command is executed:
python tools/stale_issues.py subscription save <NUMBER>
2. **After the last modification**, restore the saved state — **unless the issue was closed** (via `gh issue close`), in which case skip the restore so the user stays subscribed to follow any responses to the closure. The restore must be the very last GitHub API call — do not run it in the background or in parallel with any `gh issue edit` or `gh issue comment` commands:
python tools/stale_issues.py subscription restore <NUMBER>
If either the save or restore command fails, warn the user and continue without the save/restore mechanism.
**Important**: Never run `gh issue edit`, `gh issue comment`, `gh issue close`, or subscription save/restore commands in the background. These must all run in the foreground so their completion can be verified before proceeding. If commenting or editing fails because the issue is locked, report this to the user and skip the modification.
Security review checklist
Before running any repro code, check for the following concerns:
- Network requests to untrusted URLs (requests, urllib, curl, wget)
- File operations outside `/tmp/`
- Shell command execution (os.system, subprocess, eval, exec) — but
`subprocess` used to launch `torchrun` or `mp.spawn` for distributed repros is expected and not a concern
- Downloading or loading external files (model weights, pickled objects, data
files) — especially `torch.load` on untrusted `.pt`/`.pth` files
- Obfuscated code (base64-encoded strings, encoded bytes, unusual escapes)
- Package installation (pip install, conda install)
- Environment variable manipulation that could affect the host system — but
setting `MASTER_ADDR`, `MASTER_PORT`, `RANK`, `WORLD_SIZE`, `CUDA_VISIBLE_DEVICES`, or other standard PyTorch/CUDA env vars is expected and not a concern
If any of these are present, explain the concern to the user and ask whether to proceed, skip, or modify the repro to remove the risky parts. If the user chooses to skip, still refresh the `triaged` label timestamp (remove and re-add, or just add if not present) before reporting that the analysis is finished.
Even if the repro passes the checklist above, check whether the author of the repro code is a PyTorch collaborator by running `python tools/stale_issues.py collaborator-check <username>`. If the command exits with a non-zero status (user is not a collaborator), show the repro code to the user and ask them to verify it is safe to run before executing it.
Steps
1) Fetch the issue
Fetch the issue body and comments in parallel. Identify the reported repro script and error. If multiple repros are present, prefer the most recent one from the original poster. If a commenter has posted a strictly shorter and more self-contained repro that doesn't require additional context from the issue description, prefer that one. Note which repro you selected. If the repro code is only present in screenshots or images rather than copyable text, stop and report this to the user.
2) Check if the issue is actionable
Before investing effort in reproduction, check whether the issue is actionable. **Do not proceed to later steps** if any of the following apply:
- **Already closed or resolved** in comments. Report to the user and stop.
Do not modify labels on closed issues.
- **Duplicate** of another issue (linked or obviously the same bug)
- **Not a bug report** (feature request, question, discussion, refactoring /
code cleanup task). If the issue is a feature request and doesn't already have the `feature` label, add it via `gh issue edit`. If the issue is a better-engineering / refactoring task and doesn't already have the `better-engineering` label, add it via `gh issue edit`. If the issue includes a repro script that demonstrates the current behavior, apply the security review checklist first, then run it to verify the behavior persists. If the repro needed to be modernized (e.g. updated imports for renamed AP
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