Triage
An untriaged backlog punishes the reporters who did everything right. Your job is to restore signal: cluster the duplicates, name what each issue is, check it against the current code, and surface the handful actually worth fixing next. You draft; the maintainer sends. Never post, close, or label anything without explicit approval — every action ships as a draft.
Phase 1 — Inventory
Pull all open issues (forge CLI or API; if neither is authenticated, ask the user to export or paste). For each: number, title, age, last activity, labels, reporter, body gist. Note the shape of the backlog — a 40-issue backlog gets per-issue care; a 400-issue one gets clustering first and per-issue care for the survivors.
Phase 2 — Cluster
Group issues describing the same underlying thing: same error text or stack signature, same feature area + symptom, same request in different words. For each cluster, pick the canonical (best repro info wins, not oldest) and mark the rest as duplicates of it. Merge information: a duplicate often contains the repro detail the canonical lacks — move it before closing.
Phase 3 — Classify each survivor
- Kind: bug / feature request / question / docs / can't-tell.
- Repro status: has runnable repro / has partial info / vague. For bugs with repro, check it against current code — search for the error message, look at whether the involved path was since rewritten or the fix already landed (name the commit if so).
- Status verdict:
FIXED (by commit X), STALE (refers to code that no longer exists), NEEDS-INFO (can't act without repro), VALID (confirmed against current code), DISCUSS (needs a maintainer decision, not a fix).
Phase 4 — Deliverables
- The dedupe map — close X as duplicate of Y, with the info-merge notes.
- The label plan — using the repo's existing labels; propose new ones only if a real gap exists.
- Drafted replies — for every issue that needs one: needs-info requests that ask for specific missing details (not a generic template), fixed-in-commit closes that name the commit and version, gentle stale-closes that invite reopening with fresh info. Warm, brief, blameless — reporters are volunteers.
- The shortlist — the top ~5 issues worth fixing next, ranked by user impact × confirmation confidence × estimated effort, each with a one-line "why this one."
- Backlog health note — recurring themes the backlog reveals (one subsystem generating half the bugs, a missing doc that keeps causing the same question).
If approved to execute, apply exactly the approved subset — labels, closes, replies — and report what was done.
1---2name: triage3description: Triage a repository's issue backlog — dedupe, label, flag missing repro info, draft replies, and rank what's worth fixing. Use when a maintainer faces a pile of open issues and wants order restored without closing things rudely or blindly.4---56# Triage78An untriaged backlog punishes the reporters who did everything right. Your job is to restore signal: cluster the duplicates, name what each issue is, check it against the *current* code, and surface the handful actually worth fixing next. You draft; the maintainer sends. **Never post, close, or label anything without explicit approval — every action ships as a draft.**910## Phase 1 — Inventory1112Pull all open issues (forge CLI or API; if neither is authenticated, ask the user to export or paste). For each: number, title, age, last activity, labels, reporter, body gist. Note the shape of the backlog — a 40-issue backlog gets per-issue care; a 400-issue one gets clustering first and per-issue care for the survivors.1314## Phase 2 — Cluster1516Group issues describing the same underlying thing: same error text or stack signature, same feature area + symptom, same request in different words. For each cluster, pick the canonical (best repro info wins, not oldest) and mark the rest as duplicates of it. Merge information: a duplicate often contains the repro detail the canonical lacks — move it before closing.1718## Phase 3 — Classify each survivor1920- **Kind:** bug / feature request / question / docs / can't-tell.21- **Repro status:** has runnable repro / has partial info / vague. For bugs with repro, *check it against current code* — search for the error message, look at whether the involved path was since rewritten or the fix already landed (name the commit if so).22- **Status verdict:** `FIXED` (by commit X), `STALE` (refers to code that no longer exists), `NEEDS-INFO` (can't act without repro), `VALID` (confirmed against current code), `DISCUSS` (needs a maintainer decision, not a fix).2324## Phase 4 — Deliverables25261. **The dedupe map** — close X as duplicate of Y, with the info-merge notes.272. **The label plan** — using the repo's existing labels; propose new ones only if a real gap exists.283. **Drafted replies** — for every issue that needs one: needs-info requests that ask for *specific* missing details (not a generic template), fixed-in-commit closes that name the commit and version, gentle stale-closes that invite reopening with fresh info. Warm, brief, blameless — reporters are volunteers.294. **The shortlist** — the top ~5 issues worth fixing next, ranked by user impact × confirmation confidence × estimated effort, each with a one-line "why this one."305. **Backlog health note** — recurring themes the backlog reveals (one subsystem generating half the bugs, a missing doc that keeps causing the same question).3132If approved to execute, apply exactly the approved subset — labels, closes, replies — and report what was done.
tokyubevoxelverse