菜单
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.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
| name | bug-triage |
| description | 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. |
| argument-hint | [sprint | full | trend] |
| user-invocable | true |
| allowed-tools | Read, Glob, Grep, Write, Edit |
| model | sonnet |
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:
/team-qa completes and new bugs have been filedModes:
/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 reportGlob for bug reports in priority order:
production/qa/bugs/*.md — individual bug report files (preferred format)production/qa/bugs.md — single consolidated bug log (fallback)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.
Read the most recently modified file in production/sprints/ to understand:
If no sprint file exists: note "No sprint plan found — assigning to backlog only."
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.
For each bug, extract or infer:
| 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 | 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 |
For each P1/P2 bug in sprint mode:
Sprint: [current])Priority overflow — consider pulling from sprintFor full mode: assign all P1 to current sprint, P2 to next sprint estimate,
P3+ to backlog.
Flag bugs that suggest systematic problems:
After classifying all bugs, generate trend metrics:
# 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]
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:
/sprint-status to see current capacity."/smoke-check to re-gate."If user declined write: Verdict: BLOCKED — user declined write.
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.
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.
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.
Guided, section-by-section Art Bible authoring. Creates the visual identity specification that gates all asset production. Run after /brainstorm is approved and before /map-systems or any GDD authoring begins.
Audits game assets for compliance with naming conventions, file size budgets, format standards, and pipeline requirements. Identifies orphaned assets, missing references, and standard violations.
Generate per-asset visual specifications and AI generation prompts from GDDs, level docs, or character profiles. Produces structured spec files and updates the master asset manifest. Run after art bible and GDD/level design are approved, before production begins.