/distributed-triage

name: distributed-triage
description: 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.
hooks:
  PreToolUse:
    - matcher: "mcp__github__issue_write|mcp__github__update_issue|mcp__github__add_issue_comment|mcp__github__transfer_issue"
      hooks:
        - type: command
          command: "python3 \"$CLAUDE_PROJECT_DIR\"/.claude/skills/triaging-issues/scripts/validate_issue_target.py"
    - matcher: "mcp__github__issue_write|mcp__github__update_issue"
      hooks:
        - type: command
          command: "python3 \"$CLAUDE_PROJECT_DIR\"/.claude/skills/triaging-issues/scripts/validate_labels.py"

Distributed Issue Triage Sub-Skill

This sub-skill picks up where the PT-level triage bot leaves off. It processes issues that already have the `oncall: distributed` label and performs second-level triage: routing to a distributed sub-oncall, classifying by module, and marking triaged.

Contents

• [MCP Tools Available](#mcp-tools-available)
• [Reference Files](#reference-files)
• [Comment Deduplication](#comment-deduplication)
• [Distributed Triage Steps](#distributed-triage-steps)
• Step 0: Already Triaged by Human
• Step 1: Is This Actually a Distributed Issue?
• Step 2: Route to Distributed Sub-Oncall
• Step 3: Classify Module
• Step 4: Type Labels
• Step 5: High Priority — REQUIRES HUMAN REVIEW
• Step 6: Missing Reproduction
• [Constraints](#constraints)

**Distributed labels reference:** See [distributed-labels.json](distributed-labels.json) for the labels this skill is allowed to apply. **ONLY apply labels from this file.**

**Distributed triage rubric:** See [distributed-rubric.md](distributed-rubric.md) for detailed routing guidance, module classification signals, and confidence calibration.

**Response templates:** See [templates.json](templates.json) for distributed-specific comment templates.

---

MCP Tools Available

Use these GitHub MCP tools for triage:

| Tool | Purpose | |------|---------| | `mcp__github__get_issue` | Get issue details and existing labels | | `mcp__github__get_issue_comments` | Get existing issue comments | | `mcp__github__update_issue` | Apply labels or close issues | | `mcp__github__add_issue_comment` | Add comment (only for reproduction requests or mislabel flags) | | `mcp__github__search_issues` | Find similar issues for context |

---

Comment Deduplication

Before adding any issue comment: 1. Read the existing comments with `mcp__github__get_issue_comments`. 2. Check whether the triage bot has already posted the same template or a substantially equivalent request/explanation. 3. If a duplicate exists, do not add another comment. Continue with any non-comment actions that are still needed, such as labels.

Treat a comment as duplicate even if the wording differs slightly or an older template version was used. For distributed triage, this includes an existing distributed reproduction request or an existing "not distributed" notice.

---

Distributed Triage Steps

0) Already Triaged by Human?

A human has fully classified the issue only when it has **BOTH**: 1. Any `module:` label listed in [distributed-labels.json](distributed-labels.json), AND 2. One of the sub-oncall labels: `oncall: distributed parallelisms`, `oncall: distributed infra`, or `oncall: distributed checkpointing`.

If both are present:

• Add `bot-triaged` + `triaged` labels (the human classification is complete and confident)
• **STOP** — a human already classified this issue.

If only one is present (a module label without a sub-oncall, or a sub-oncall without a module label), triage is **incomplete** — proceed to Step 1. The PT-level triage bot can apply distributed module labels alongside `oncall: distributed`, but it does not pick the sub-oncall; that is your job.

*This step alone should clear a large portion of the backlog.*

1) Is This Actually a Distributed Issue?

Read the issue title, description, and comments. Determine whether the issue is actually related to distributed training.

**Signs it is NOT a distributed issue:**

• Single-GPU issue with no distributed code (e.g., `torch.nn` on one GPU, CUDA OOM on one device)
• Build/packaging issue (e.g., `undefined symbol: ncclAlltoAll` at `import torch` with no distributed code)
• Pure `torch.compile` issue with no distributed component
• Issue about a domain library (vision, text, audio) that happens to mention "distributed"

**If NOT a distributed issue:** 1. Add `triage review` + `bot-triaged` labels 2. Post a comment using the `not_distributed` template from [templates.json](templates.json), unless an equivalent "not distributed" comment already exists 3. Do **NOT** remove `oncall: distributed` — let the human oncall re-route 4. **STOP**

2) Route to Distributed Sub-Oncall

Each issue carries **exactly ONE** sub-oncall label. If the issue already has one of the three sub-oncall labels (`oncall: distributed parallelisms`, `oncall: distributed infra`, or `oncall: distributed checkpointing`), keep it as-is — do NOT add a second sub-oncall, even if your own classification would have picked a different one. Use the existing sub-oncall to decide the next step (continue to Step 3 if it's `oncall: distributed parallelisms`; otherwise add `bot-triaged` and STOP per the rules below).

If no sub-oncall is present, apply exactly one based on the routing rules in [distributed-rubric.md](distributed-rubric.md):

| Sub-Oncall Label | When to Apply | |-----------------|---------------| | `oncall: distributed parallelisms` | FSDP, DDP, DTensor, tensor parallel, context parallel, pipeline parallel. **This is the default** when unsure. | | `oncall: distributed infra` | c10d, process groups, collectives, NCCL/Gloo/MPI backends, elastic/torchrun, RPC, stores, distributed tools, DeviceMesh, symmetric memory | | `oncall: distributed c