Bug Triage
Re-prioritize open QA/production bugs, assign them to sprints, and publish a dated triage report when the backlog grows or a new sprint starts.
Overview
Bug Triage is an agent skill most often used in Operate (also Ship testing) that turns open production/qa/bugs markdown into a prioritized, sprint-assigned triage report with trend notes.
Install
npx skills add https://github.com/donchitos/claude-code-game-studios --skill bug-triageWhat is this skill?
- Glob-loads bug reports from production/qa/bugs/*.md and writes production/qa/bug-triage-[date].md
- Three modes: sprint (current sprint assignment), full (entire backlog), trend (read-only systemic analysis)
- Explicit severity-vs-priority re-evaluation with sprint backlog vs defer decisions
- Systemic trend surfacing across the open bug set
- Default mode: sprint when a current sprint exists, otherwise full
- 3 triage modes: sprint, full, trend
- Trigger when open bug count crosses 10+ items
- Output file: production/qa/bug-triage-[date].md
Adoption & trust: 1 installs on skills.sh; 21.2k GitHub stars; 3/3 security scanners passed (skills.sh audits); trending (+100% hot-view momentum).
What problem does it solve?
You have a growing pile of open bug markdown files and no consistent way to separate severity from priority or slot fixes into the current sprint.
Who is it for?
Indie builders using a production/qa/bugs/*.md convention who run sprints and need a repeatable start-of-sprint or post-QA triage ritual.
Skip if: Teams without on-disk bug reports under production/qa/bugs/ or anyone who only wants a one-off debug of a single crash without backlog management.
When should I use this skill?
Sprint start, after /team-qa completes and new bugs are filed, or when open bug count grows enough to need re-prioritization (10+).
What do I get? / Deliverables
You get production/qa/bug-triage-[date].md with reassigned priorities, sprint vs backlog placement, and systemic trends so critical bugs are not dropped before the next QA or release cycle.
- production/qa/bug-triage-[date].md prioritization and assignment report
- Severity vs priority labels per open bug
- Sprint vs backlog placement and systemic trend summary
Recommended Skills
Journey fit
Spans multiple journey phases - primary shelf plus alternate fits below.
Bug backlog grooming is a recurring production-health ritual—canonical shelf is Operate because it manages open defects after QA and in live environments. Errors is the right subphase: the skill reads bug reports, separates severity from priority, and prevents critical defects from slipping between sprints.
Where it fits
At sprint start you re-rank ten open gameplay defects so only P0/P1 land in the current sprint capacity.
Right after QA files new markdown bugs you run sprint mode to attach fixes to the active milestone.
You run trend mode to see whether crashes cluster on one build flavor before planning the next patch.
You use full mode mid-milestone to defer noisy low-impact bugs and keep the roadmap honest.
How it compares
Use instead of manually skimming bug files in the editor when you need severity/priority separation and sprint assignment in one report.
Common Questions / FAQ
Who is bug-triage for?
Solo and small-team builders—especially game-studio style repos—who file bugs as markdown under production/qa/bugs/ and run sprint-based delivery.
When should I use bug-triage?
At sprint start to assign open bugs; after QA completes and new reports land; when open count is high (the skill calls out 10+); or in Ship testing review before you commit sprint capacity.
Is bug-triage safe to install?
It is constrained to Read, Glob, Grep, Write, and Edit on your repo—review the Security Audits panel on this page before trusting it with production paths.
SKILL.md
READMESKILL.md - Bug Triage
# Bug Triage This skill processes the open bug backlog into a prioritised, sprint-assigned action list. It distinguishes between **severity** (how bad is the impact?) and **priority** (how urgently must we fix it?), detects systemic trends, and ensures no critical bug is lost between sprints. **Output:** `production/qa/bug-triage-[date].md` **When to run:** - Sprint start — assign open bugs to the new sprint or backlog - After `/team-qa` completes and new bugs have been filed - When the bug count crosses 10+ open items --- ## 1. Parse Arguments **Modes:** - `/bug-triage sprint` — triage against the current sprint; assign fixable bugs to the sprint backlog; defer the rest - `/bug-triage full` — full triage of all bugs regardless of sprint scope - `/bug-triage trend` — trend analysis only (no assignment); read-only report - No argument — run sprint mode if a current sprint exists, else full mode --- ## 2. Load Bug Backlog ### Step 2a — Discover bug files Glob for bug reports in priority order: 1. `production/qa/bugs/*.md` — individual bug report files (preferred format) 2. `production/qa/bugs.md` — single consolidated bug log (fallback) 3. Any `production/qa/qa-plan-*.md` "Bugs Found" table (last resort) If no bug files found: > "No bug files found in `production/qa/bugs/`. If bugs are tracked in a > different location, adjust the glob pattern. If no bugs exist yet, there is > nothing to triage." Stop and report. Do not proceed if no bugs exist. ### Step 2b — Load sprint context Read the most recently modified file in `production/sprints/` to understand: - Current sprint number / name - Stories in scope (for assignment target) - Sprint capacity constraints (if noted) If no sprint file exists: note "No sprint plan found — assigning to backlog only." ### Step 2c — Load severity reference Read `.claude/docs/coding-standards.md` for severity/priority definitions if they exist. If they do not exist, use the standard definitions in Step 3. --- ## 3. Classify Each Bug For each bug, extract or infer: ### Severity (impact of the bug) | Severity | Definition | |----------|-----------| | **S1 — Critical** | Game crashes, data loss, or complete feature failure. Cannot proceed past this point. | | **S2 — High** | Major feature broken but game is still playable. Significant wrong behaviour. | | **S3 — Medium** | Feature degraded but a workaround exists. Minor wrong behaviour. | | **S4 — Low** | Visual glitch, cosmetic issue, typo. No gameplay impact. | ### Priority (urgency of the fix) | Priority | Definition | |----------|-----------| | **P1 — Fix this sprint** | Blocks QA, blocks release, or is regression from last sprint | | **P2 — Fix soon** | Should be resolved before the next major milestone | | **P3 — Backlog** | Would be good to fix, but no active blocking impact | | **P4 — Won't fix / Deferred** | Accepted risk or out of scope for current product scope | ### Assignment For each P1/P2 bug in `sprint` mode: - Identify which story or epic the fix belongs to - Check whether the current sprint has remaining capacity - If capacity exists: assign to sprint (`Sprint: [current]`) - If capacity is full: flag as `Priority overflow — consider pulling from sprint` For `full` mode: assign all P1 to current sprint, P2 to next sprint estimate, P3+ to backlog. ### Deviation check Flag bugs that suggest **systematic problems**: - 3+ bugs from the same system in the same sprint → "Potential design or implementation quality issue in [system]" - 2+ S1/S2 bugs in the same story → "Story may need to be reopened and re-reviewed before