# Triage

> 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.

- Skill: `tokyubevoxelverse/triage` (Agent Skill, multi-file: 3 files)
- Install (CLI): `npx skillmds@latest add tokyubevoxelverse/triage`
- Raw SKILL.md: https://api.skillmd.com/api/skills/tokyubevoxelverse/triage/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Product & Planning
- Author: tokyubevoxelverse (https://skillmd.com/u/tokyubevoxelverse)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/tokyubevoxelverse/triage

---


# 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

1. **The dedupe map** — close X as duplicate of Y, with the info-merge notes.
2. **The label plan** — using the repo's existing labels; propose new ones only if a real gap exists.
3. **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.
4. **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."
5. **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.