bug-triage

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Bug Triage

Bug分诊处理

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

该技能会将未解决的Bug待办清单处理为一份已划分优先级、分配至对应sprint的行动列表。它会区分severity（严重程度）（影响有多恶劣？）和priority（优先级）（修复的紧急程度如何？），识别系统性趋势，并确保关键Bug不会在迭代之间被遗漏。

输出：

production/qa/bug-triage-[date].md

运行时机：

迭代开始时——将未解决Bug分配至新迭代或待办清单
```
/team-qa
```
完成且新Bug提交后
未解决Bug数量超过10个时

1. Parse Arguments

1. 解析参数

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

模式：

```
/bug-triage sprint
```
—— 针对当前迭代进行分诊；将可修复的Bug分配至迭代待办清单；其余Bug延后处理
```
/bug-triage full
```
—— 对所有Bug进行全面分诊，不受迭代范围限制
```
/bug-triage trend
```
—— 仅进行趋势分析（不分配）；生成只读报告
无参数 —— 若存在当前迭代则运行sprint模式，否则运行full模式

2. Load Bug Backlog

2. 加载Bug待办清单

Step 2a — Discover bug files

步骤2a —— 查找Bug文件

Glob 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)
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.

按优先级顺序查找Bug报告：

```
production/qa/bugs/*.md
```
—— 单个Bug报告文件（首选格式）
```
production/qa/bugs.md
```
—— 单个整合式Bug日志（备选）
任何
```
production/qa/qa-plan-*.md
```
中的“发现的Bug”表格（最后手段）

若未找到Bug文件：

"未在
production/qa/bugs/
中找到Bug文件。若Bug在其他位置追踪，请调整全局匹配模式。若当前无Bug，则无需进行分诊。"

停止操作并报告。若无Bug存在，则无需继续。

Step 2b — Load sprint context

步骤2b —— 加载迭代上下文

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."

读取

production/sprints/

中最近修改的文件，以了解：

当前迭代编号/名称
范围内的用户故事（作为分配目标）
迭代容量限制（如有标注）

若不存在迭代文件：记录“未找到迭代计划——仅分配至待办清单。”

Step 2c — Load severity reference

步骤2c —— 加载严重程度参考

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.

若

.claude/docs/coding-standards.md

中存在严重程度/优先级定义，则读取该文件。若不存在，则使用步骤3中的标准定义。

3. Classify Each Bug

3. 对每个Bug进行分类

For each bug, extract or infer:

针对每个Bug，提取或推断以下信息：

Severity (impact of the bug)

Severity（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.

Severity	定义
S1 — Critical	游戏崩溃、数据丢失或功能完全失效。无法继续操作。
S2 — High	主要功能损坏但游戏仍可运行。存在严重错误行为。
S3 — Medium	功能降级但存在替代方案。存在轻微错误行为。
S4 — Low	视觉故障、外观问题或拼写错误。对游戏玩法无影响。

Priority (urgency of the fix)

Priority（修复的紧急程度）

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

Priority	定义
P1 — Fix this sprint	阻塞QA、阻塞发布或为上一版本的回归问题
P2 — Fix soon	应在下一个重要里程碑前解决
P3 — Backlog	修复会更好，但无主动阻塞影响
P4 — Won't fix / Deferred	已接受风险或超出当前产品范围

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.

对于

sprint

模式下的每个P1/P2级Bug：

确定修复所属的用户故事或史诗
检查当前迭代是否有剩余容量
若有剩余容量：分配至当前迭代（
```
Sprint: [current]
```
）
若容量已满：标记为
```
Priority overflow — consider pulling from sprint
```
（优先级溢出——考虑从迭代中移除部分任务）

对于

full

模式：将所有P1级Bug分配至当前迭代，P2级Bug分配至预计的下一个迭代，P3及以上级别Bug分配至待办清单。

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"

标记显示系统性问题的Bug：

同一迭代中同一系统出现3个及以上Bug → "潜在的[系统]设计或实现质量问题"
同一用户故事中出现2个及以上S1/S2级Bug → "该用户故事可能需要重新打开并在发布前重新评审"
针对已标记为完成的用户故事提交的Bug → "已完成用户故事中的回归问题——应在迭代追踪中重新打开该用户故事"

4. Trend Analysis

4. 趋势分析

After classifying all bugs, generate trend metrics:

对所有Bug分类完成后，生成趋势指标：

Volume trends

数量趋势

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

未解决Bug总数：[N]
本迭代新增：[N]
本迭代已关闭：[N]
净变化：[+N / -N]

System hot spots

系统热点

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

哪个系统的未解决Bug最多？
哪个系统的S1/S2级Bug占比最高？

Age analysis

时长分析

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

存在超过2个迭代的Bug有多少？
是否存在未分配的S1/S2级Bug（sprint = none）？

Regression indicator

回归指标

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

是否存在针对已完成用户故事的Bug？
数量：[N]个回归Bug（意味着需重新打开用户故事）

5. Generate Triage Report

5. 生成分诊报告

markdown

undefined

markdown

undefined

Bug Triage Report

Bug分诊处理报告

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

日期: [date] 模式: [sprint | full | trend] 生成者: /bug-triage 处理的未解决Bug数量: [N] 涉及迭代: [迭代名称，或"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]

Priority	数量	备注
P1 — Fix this sprint	[N]	[N]个已分配至迭代，[N]个溢出
P2 — Fix soon	[N]	计划分配至下一个迭代
P3 — Backlog	[N]	延后处理
P4 — Won't fix	[N]	已接受风险

未修复的严重（S1/S2）Bug数量: [N]

P1 Bugs — Fix This Sprint

P1级Bug —— 本迭代修复

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

ID	系统	Severity	摘要	分配至	用户故事
BUG-NNN	[system]	S[1-4]	[单行描述]	[sprint]	[用户故事路径]

P2 Bugs — Fix Soon

P2级Bug —— 尽快修复

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

ID	系统	Severity	摘要	目标迭代
BUG-NNN	[system]	S[1-4]	[单行描述]	Sprint [N+1]

P3/P4 Bugs — Backlog / Won't Fix

P3/P4级Bug —— 待办清单 / 不修复

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

ID	系统	Severity	摘要	处理方式
BUG-NNN	[system]	S4	[单行描述]	待办清单

Systemic Issues Flagged

标记的系统性问题

[List any patterns from Step 3 deviation check, or "None identified."]

[列出步骤3偏差检查中的任何模式，或"未识别到系统性问题。"]

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.

数量: [N]个未解决 / 本迭代净变化[+N] 热点: [Bug数量最多的系统] 回归问题: [N]个针对已完成用户故事的Bug 长期Bug（超过2个迭代）: [N]

[若存在N个超过2个迭代的S1/S2级Bug:]

⚠️ [N]个高严重程度Bug已存在超过2个迭代但未分配。这些代表已接受的风险，应进行明确评审。

Recommended Actions

建议行动

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

---

[最紧急行动——通常为"在QA交接前修复P1级Bug"]
[次要行动——通常为"调查[热点系统]的质量问题"]
[第三项行动——可选改进]

---

6. Write and Gate

6. 写入与确认

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.

在对话中展示报告，然后询问：

"是否允许我将这份分诊报告写入

production/qa/bug-triage-[date].md

？"

仅在获得批准后写入。

写入完成后：

若存在未分配的S1级Bug："S1级Bug必须分配后，迭代才能视为健康状态。运行
```
/sprint-status
```
查看当前容量。"
若存在回归Bug："发现回归问题——考虑在迭代追踪中重新打开受影响的用户故事，并运行
```
/smoke-check
```
重新验证。"
若不存在P1级Bug："无P1级Bug——构建状态良好，可进行QA交接。" 结论：COMPLETE——分诊报告已写入。

若用户拒绝写入：结论：BLOCKED——用户拒绝写入。

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

未经用户批准，不得关闭或标记Bug为Won't Fix——将其列为P4候选并询问："这些Bug是否可接受为Won't Fix？"
不得自动将Bug分配至已满容量的迭代——标记溢出情况，由迭代负责人决定移除哪些任务
Severity是客观的；priority是团队决策——将严重程度分类作为建议呈现，而非强制要求
趋势数据仅作参考——不得仅因趋势发现而阻塞工作；将其作为观察结果呈现