bug-triage-pack

Bug Triage Pack

A bug backlog is only as good as its triage — and most bugs arrive as "it's broken" with no repro, a panicked severity, and no idea who should look. This turns a raw report into a triaged item: reproducible steps, a severity and priority you can defend (not vibes), the environment that matters, a suspected area and owner queue, and a check for whether it's a duplicate — asking for what's missing instead of inventing it.

What This Skill Produces

• Normalized repro — clear, numbered steps; expected vs. actual; the minimal path to reproduce
• Severity & priority — each with reasoning (impact × frequency × workaround availability), not a gut number
• Environment & metadata — version, platform, browser/OS, user/role, first-seen, frequency
• Suspected area & owner queue — where it likely lives and who should take it next
• Duplicate/related check — is this the same as a known issue, and what to link
• Missing-info flags — what the reporter must supply before it's actionable

Required Inputs

Ask for these if not provided:

• The raw report — whatever came in (a Slack message, a customer ticket, a screenshot description)
• Your severity/priority scale — what P0–P3 / S1–S4 mean here (else a sensible default is used and labelled)
• Environment details — version, platform, who hit it, how often
• Known issues (optional) — a list to dedupe against

Framework: Triage You Can Defend

1. Repro or it's not a bug yet. No reliable steps → the first action is "needs repro," not a severity.
2. Severity ≠ priority. Severity is how bad the impact is; priority is when we fix it (a rare-but-catastrophic bug and a constant-but-cosmetic one differ on both axes).
3. Score, don't feel. Impact (data loss > broken flow > cosmetic) × frequency (all users > edge case) × workaround (none > easy) → a defensible level.
4. Route it. Suspected component and the queue/owner it should go to — triage that doesn't route just moves the pile.
5. Dedupe. Check against known issues; a linked duplicate is worth more than a fifth copy.
6. Flag gaps, don't guess. Missing environment or repro is a request to the reporter, not an assumption.

Output Format

Bug: [title] · Severity [Sx] · Priority [Px]

Why this level: impact [x] × frequency [y] × workaround [z].

Repro

1. … → Expected: … · Actual: …

Environment

| Version | Platform | User/role | First seen | Frequency |

Routing

• Suspected area: [component] · Suggested queue/owner: [team].

Duplicate / related

• [links, or "no known duplicate"].

⚠ Missing before it's actionable

• [what the reporter must add].

Quality Checks

• [ ] Repro steps are clear and include expected vs. actual (or "needs repro" is the flagged first action)
• [ ] Severity and priority are distinct and each justified by impact × frequency × workaround
• [ ] Environment/metadata is captured (or flagged missing)
• [ ] A suspected area and owner queue are proposed
• [ ] A duplicate/related check is done
• [ ] Missing information is requested, not invented

Anti-Patterns

• A severity with no reasoning — "this is a P1" because it feels urgent.
• Conflating severity and priority — they answer different questions.
• Assigning a level without repro — triage a phantom and you fix nothing.
• No routing — a triaged bug with no owner queue is still stuck.
• Inventing environment/repro the reporter never gave.

Example Trigger Phrases

• "Triage this bug and set severity and priority: [paste]"
• "Is this a P1? Here's the report."
• "Clean up this bug for the backlog with repro steps and an owner."
• "Normalize this customer bug report and check if it's a duplicate."