본문으로 건너뛰기
cccskills
무료GitHub에 공개

bug-triage

Read all open bugs in production/qa/bugs/, re-evaluate priority vs. severity, assign to sprints, surface systemic trends, and produce a triage report. Run at sprint start or when the bug count grows enough to need re-prioritization.

한국어 요약은 준비 중입니다. 원문 설명을 표시하고 있습니다.

설치 방법 보기

포함된 파일(1)

  • SKILL.md7.7 KB

SKILL.md(원문)

설치하기 전에 에이전트에게 전달되는 지시 내용을 확인할 수 있습니다.

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 docs/framework/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)

SeverityDefinition
S1 — CriticalGame crashes, data loss, or complete feature failure. Cannot proceed past this point.
S2 — HighMajor feature broken but game is still playable. Significant wrong behaviour.
S3 — MediumFeature degraded but a workaround exists. Minor wrong behaviour.
S4 — LowVisual glitch, cosmetic issue, typo. No gameplay impact.

Priority (urgency of the fix)

PriorityDefinition
P1 — Fix this sprintBlocks QA, blocks release, or is regression from last sprint
P2 — Fix soonShould be resolved before the next major milestone
P3 — BacklogWould be good to fix, but no active blocking impact
P4 — Won't fix / DeferredAccepted 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 shipping"
  • Bug filed against a story marked Complete → "Regression in completed story — story should be re-opened in sprint tracking"

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 any patterns from Step 3 deviation check, or "None identified."]

---

## Trend Analysis

**Volume**: [N] open / [+N] net change this sprint
**Hot spot**: [system with most bugs]
**Regressions**: [N] bugs against completed stories
**Aged bugs (>2 sprints old)**: [N]

[If N aged S1/S2 bugs > 0:]
> ⚠️ [N] high-severity bugs have been open for more than 2 sprints without
> assignment. These represent accepted risk that should be explicitly reviewed.

---

## Recommended Actions

1. [Most urgent action — usually "fix P1 bugs before QA hand-off"]
2. [Second action — usually "investigate [hot spot system] quality"]
3. [Third action — optional improvement]

6. Write and Gate

Present the report in conversation, then ask:

"May I write this triage report to production/qa/bug-triage-[date].md?"

Write only after approval.

After writing:

  • If any S1 bugs are unassigned: "S1 bugs must be assigned before the sprint can be considered healthy. Run /sprint-status to see current capacity."
  • If regression bugs exist: "Regressions found — consider re-opening the affected stories in sprint tracking and running /smoke-check to re-gate."
  • If no P1 bugs exist: "No P1 bugs — build is in good shape for QA hand-off." Verdict: COMPLETE — triage report written.

If user declined write: Verdict: BLOCKED — user declined write.


Collaborative Protocol

  • Never close or mark bugs Won't Fix without user approval — surface them as P4 candidates and ask: "Are these acceptable as Won't Fix?"
  • Never auto-assign to a sprint at capacity — flag overflow and let the sprint owner decide what to pull
  • Severity is objective; priority is a team decision — present severity classifications as recommendations, not mandates
  • Trend data is informational — do not block work on trend findings alone; surface them as observations

리뷰

아직 리뷰가 없습니다. 사용해 본 소감을 남겨 주세요.

댓글

로그인 없이 쓸 수 있습니다. 사용 후기, 질문, 작동하지 않은 환경 등을 편하게 남겨 주세요.

아직 댓글이 없습니다. 첫 댓글을 남겨 보세요.

보내면 바로 공개됩니다. 이메일 주소나 전화번호 같은 개인 정보는 쓰지 마세요. URL은 2개까지입니다.

0 / 1,000자

이 양식은 reCAPTCHA로 보호되며 Google 개인정보처리방침 및 서비스 약관이 적용됩니다.

같은 저장소의 스킬

adopt

무료

Brownfield onboarding — audits existing project artifacts for template format compliance (not just existence), classifies gaps by impact, and produces a numbered migration plan. Run this when joining an in-progress project or upgrading from an older template version. Distinct from /project-stage-detect (which checks what exists) — this checks whether what exists will actually work with the template's skills.

한국어 요약은 준비 중입니다. 원문 설명을 표시하고 있습니다.

striderZA/OpenCodeGameStudios992026년 10월 7일 업데이트

Creates an Architecture Decision Record (ADR) documenting a significant technical decision, its context, alternatives considered, and consequences. Every major technical choice should have an ADR.

한국어 요약은 준비 중입니다. 원문 설명을 표시하고 있습니다.

striderZA/OpenCodeGameStudios992026년 10월 7일 업데이트

Validates completeness and consistency of the project architecture against all GDDs. Builds a traceability matrix mapping every GDD technical requirement to ADRs, identifies coverage gaps, detects cross-ADR conflicts, verifies engine compatibility consistency across all decisions, and produces a PASS/CONCERNS/FAIL verdict. The architecture equivalent of /design-review.

한국어 요약은 준비 중입니다. 원문 설명을 표시하고 있습니다.

striderZA/OpenCodeGameStudios992026년 10월 7일 업데이트

art-bible

무료

Guided, section-by-section Art Bible authoring. Creates the visual identity specification that gates all asset production. Run after /concept-brainstorm is approved and before /map-systems or any GDD authoring begins.

한국어 요약은 준비 중입니다. 원문 설명을 표시하고 있습니다.

striderZA/OpenCodeGameStudios992026년 10월 7일 업데이트

Generates placeholder .aseprite files from asset specs using the Aseprite MCP. Reads asset specs and art bible, creates sprites with correct dimensions/palette/layers, exports PNGs. Run after /asset-spec has produced specs and /art-bible exists.

한국어 요약은 준비 중입니다. 원문 설명을 표시하고 있습니다.

striderZA/OpenCodeGameStudios992026년 10월 7일 업데이트

Audits game assets for compliance with naming conventions, file size budgets, format standards, and pipeline requirements. Identifies orphaned assets, missing references, and standard violations.

한국어 요약은 준비 중입니다. 원문 설명을 표시하고 있습니다.

striderZA/OpenCodeGameStudios992026년 10월 7일 업데이트

striderZA의 스킬 모두 보기

이 스킬의 문제 신고