Triage a raw bug report into something a team can act on — clean repro steps, a defensible severity/priority, environment, likely area/owner, and duplicate check. Use when asked to triage this bug, set severity and priority, is this a P1, or clean up this bug report for the backlog. Produces the normalized repro, a severity and priority with the reasoning (impact × frequency × workaround), the environment/metadata, a suspected component and owner queue, and a duplicate/related-issue check — flagging when info is missing rather than guessing.
Start a fresh conversation. Replace the highlighted placeholders.
Use bug-triage-pack to triage [raw bug report] using [environment details] and [severity/priority scale and known issues], producing normalized repro steps, defensible severity and priority, routing, duplicate assessment, and missing-information flags.
Required inputs
[raw bug report]
[environment details]
[severity/priority scale and known issues]
User-approved starter prompt based on a pinned source version; check current skill requirements before running. Task evidence ↗
SKILL.md
name: bug-triage-packdescription: "Triage a raw bug report into something a team can act on — clean repro steps, a defensible severity/priority, environment, likely area/owner, and duplicate check. Use when asked to triage this bug, set severity and priority, is this a P1, or clean up this bug report for the backlog. Produces the normalized repro, a severity and priority with the reasoning (impact × frequency × workaround), the environment/metadata, a suspected component and owner queue, and a duplicate/related-issue check — flagging when info is missing rather than guessing."
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
Repro or it's not a bug yet. No reliable steps → the first action is "needs repro," not a severity.
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).
Score, don't feel. Impact (data loss > broken flow > cosmetic) × frequency (all users > edge case) × workaround (none > easy) → a defensible level.
Route it. Suspected component and the queue/owner it should go to — triage that doesn't route just moves the pile.
Dedupe. Check against known issues; a linked duplicate is worth more than a fifth copy.
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
… → Expected: … · Actual: …
Environment
| Version | Platform | User/role | First seen | Frequency |