Mmcp.market

bug-triage skill

by Donchitos·Donchitos/Claude-Code-Game-Studios·25k stars·MIT

Re-evaluate open bugs — priority vs severity, assign to sprints, surface systemic trends. Run when the count grows.

A100/100content scan

Is the bug-triage skill safe?

Clean: nothing in its files matched our rules. We read 1 file in the folder on 2026-09-28.

No findings.

Install the bug-triage skill

A skill is a folder. Copy it into your agent's skills folder and the agent loads it when the task matches its description.

git clone --depth 1 https://github.com/Donchitos/Claude-Code-Game-Studios.git /tmp/Claude-Code-Game-Studios
mkdir -p ~/.claude/skills
cp -r /tmp/Claude-Code-Game-Studios/.claude/skills/bug-triage ~/.claude/skills/bug-triage
available in every project

In the Claude apps, zip the folder and upload it from the Skills settings. The folder on GitHub

The instructions your agent would load

SKILL.md as published, without the frontmatter. Read it on GitHub

!bash "${CLAUDESKILLDIR}/../../hooks/yaml-helper.sh" resolve_config --keys automation

Automation mode: Resolve modes.automation (project.local.yaml → project.yaml → default collaborative). Every AskUserQuestion call and every file write follows .claude/docs/automation-modes.md (collaborative asks always · guided major-only · autonomous logs and proceeds; automationalwaysask categories always prompt).

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:

to the sprint backlog; defer the rest

  • /bug-triage sprint — triage against the current sprint; assign fixable bugs
  • /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.

In trend mode, do not read full bug bodies. Trend metrics (volume, severity mix, by-system, by-date) are computable from the header fields alone:

Grep pattern="\*\*(Severity|Priority|Status|System|Category|Reported)\*\*" glob="production/qa/bugs/*.md" output_mode="content"

(Bug-report fields are bolded — Severity:, - System: — so match the field form, not a bare line-start Field:.) Full bug bodies are needed only for the priority-vs-severity re-evaluation in sprint/full modes; trend is a read-only report and skips it. (The one deviation check that needs a story's status — "bug filed against a Complete story" — is a targeted story-status grep either way, not a bug-body read.)

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)

Priority (urgency of the fix)

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:

implementation quality issue in [system]"

  • 3+ bugs from the same system in the same sprint → "Potential design or

re-reviewed before shipping"

  • 2+ S1/S2 bugs in the same story → "Story may need to be reopened and

story should be re-opened in sprint tracking"

  • Bug filed against a story marked Complete → "Regression in completed story —

4. Trend Analysis

After classifying all bugs, generate trend metrics:

Volume trends

  • Total open bugs: [N]
  • Opened this sprint: [N]
  • Closed this sprint: [N]
  • Net change: [+N / -N]

System hot spots

  • Which system has the most open bugs?
  • Which system has the highest S1/S2 ratio?

Age analysis

  • How many bugs are older than 2 sprints?
  • Are any S1/S2 bugs un-assigned (sprint = none)?

Regression indicator

  • Any bugs filed against previously-completed stories?
  • Count: [N] regression bugs (story reopened implied)

5. Generate Triage Report

# Bug Triage Report

> **Date**: [date]
> **Mode**: [sprint | full | trend]
> **Generated by**: /bug-triage
> **Open bugs processed**: [N]
> **Sprint in scope**: [sprint name, or "N/A"]

---

## Triage Summary

| Priority | Count | Notes |
|----------|-------|-------|
| P1 — Fix this sprint | [N] | [N] assigned to sprint, [N] overflow |
| P2 — Fix soon | [N] | Scheduled for next sprint |
| P3 — Backlog | [N] | Deferred |
| P4 — Won't fix | [N] | Accepted risk |

**Critical (S1/S2) unfixed count**: [N]

---

## P1 Bugs — Fix This Sprint

| ID | System | Severity | Summary | Assigned to | Story |
|----|--------|----------|---------|-------------|-------|
| BUG-NNN | [system] | S[1-4] | [one-line description] | [sprint] | [story path] |

---

## P2 Bugs — Fix Soon

| ID | System | Severity | Summary | Target Sprint |
|----|--------|----------|---------|---------------|
| BUG-NNN | [system] | S[1-4] | [one-line description] | Sprint [N+1] |

---

## P3/P4 Bugs — Backlog / Won't Fix

| ID | System | Severity | Summary | Disposition |
|----|--------|----------|---------|-------------|
| BUG-NNN | [system] | S4 | [one-line description] | Backlog |

---

## Systemic Issues Flagged

[List a

6. Write and Gate

Present the report in conversation, then ask:

More skills from Donchitos/Claude-Code-Game-Studios

  • AadoptBrownfield audit — do existing artifacts actually work? Numbered migration plan. Unlike /project-stage-detect, checks compliance not existence.
  • Aarchitecture-decisionCreate an ADR documenting a technical decision: context, alternatives considered, consequences.
  • Aarchitecture-reviewTraceability matrix mapping GDD requirements to ADRs. Finds gaps, cross-ADR conflicts, engine compatibility. PASS/CONCERNS/NOT ASSESSED/FAIL.
  • Aart-bibleAuthor the Art Bible — visual identity gating asset production. Run before /map-systems.
  • Aasset-auditAudit assets against naming conventions, file size budgets, format standards. Finds orphaned assets, missing references.
  • Aasset-specPer-asset visual specs plus AI generation prompts from GDDs and character profiles. After the art bible.
  • Abalance-checkFind balance outliers, broken progressions, degenerate strategies, economy imbalances in formulas and data. 'Check game balance'.
  • AbrainstormGuided concept ideation using professional studio techniques, player psychology, creative exploration.
  • Abug-reportStructured bug report from a description, or analyze code for potential bugs. Reproduction steps, severity.
  • AchangelogAuto-generate a changelog from git commits and sprint data. Internal and player-facing versions.
  • Acode-reviewArchitectural code review — coding standards, SOLID, testability, performance concerns.
  • Aconsistency-checkScan GDDs against the entity registry for cross-document conflicts. Grep-first approach targets conflicting sections, different stats.

All agent skills → · MCP servers