bug-triage

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

自动化模式：解析 modes.automation（project.local.yaml → project.yaml → 默认值 collaborative）。每次调用 AskUserQuestion 和 每次文件写入都遵循 .claude/docs/automation-modes.md （collaborative 模式始终询问 · guided 模式仅对重大事项询问 · autonomous 模式记录并继续； automation_always_ask 类别始终提示）。

Bug 分类

此技能会将未解决的 Bug 积压项整理为按优先级排序、分配到冲刺的行动清单。它会区分严重程度（影响有多严重？）和优先级（修复的紧迫程度如何？），检测系统性趋势，并确保没有关键 Bug 在冲刺之间被遗漏。

输出： production/qa/bug-triage-[date].md

运行时机：

• 冲刺开始时 — 将未解决的 Bug 分配到新冲刺或积压列表
• /team-qa 完成并提交新 Bug 后
• 未解决 Bug 数量达到 10 个或更多时

---

1. 解析参数

模式：

• /bug-triage sprint — 针对当前冲刺进行分类；将可修复的 Bug 分配到冲刺积压列表；其余的延后处理
• /bug-triage full — 对所有 Bug 进行完整分类，不受冲刺范围限制
• /bug-triage trend — 仅分析趋势（不进行分配）；生成只读报告
• 无参数 — 若存在当前冲刺，则运行 sprint 模式；否则运行 full 模式

---

2. 加载 Bug 积压项

步骤 2a — 查找 Bug 文件

按优先级对 Bug 报告进行 glob 匹配：

1. production/qa/bugs/*.md — 单个 Bug 报告文件（首选格式）
2. production/qa/bugs.md — 单个合并 Bug 日志（备用）
3. 任何 production/qa/qa-plan-*.md 中的“Bugs Found”表格（最后手段）

如果未找到 Bug 文件：

"在 production/qa/bugs/ 中未找到 Bug 文件。如果 Bug 记录在其他位置，请调整 glob 模式。如果目前没有 Bug，则无需分类。"

停止并报告。如果不存在 Bug，不要继续。结论：完成 — production/qa/bugs/ 中没有 Bug 文件；无需分类。

在 trend 模式下，不要读取完整的 Bug 正文。 趋势指标（数量、严重程度分布、 按系统分类、按日期分类）仅凭标题字段即可计算：

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

（Bug 报告字段使用粗体标记 — **Severity**:、- **System**: — 因此应匹配 **字段** 格式，而不是行首的裸字段名 字段:。） 只有在 sprint/full 模式下重新评估优先级与严重程度时，才需要读取完整 Bug 正文； trend 是只读报告，会跳过此操作。（唯一需要故事状态的偏差检查 —“针对已完成 故事提交 Bug” — 无论哪种模式，都只需定向 grep 故事状态，无需读取 Bug 正文。）

步骤 2b — 加载冲刺背景信息

读取 production/sprints/ 中最近修改的文件，以了解：

• 当前冲刺编号／名称
• 范围内的故事（用于确定分配目标）
• 冲刺容量限制（如果有记录）

如果不存在冲刺文件：注明“未找到冲刺计划 — 仅分配到积压列表。”在 workflow: minimal 模式下，冲刺按设计不存在 — 应改为说明这一点，并根据简介中的构建顺序，将 P1 Bug 列为下一步要修复的事项，优先于下一个故事。

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

如果 .claude/docs/coding-standards.md 存在，读取其中的严重程度／优先级定义。如果文件不存在，则使用步骤 3 中的标准定义。

---

3. 为每个 Bug 分类

对于每个 Bug，提取或推断：

严重程度（Bug 的影响）

严重程度	定义
S1 — 严重	游戏崩溃、数据丢失或功能完全失效。无法继续进行。
S2 — 高	主要功能失效，但游戏仍可玩。行为明显错误。
S3 — 中	功能受损，但存在变通方案。行为略有错误。
S4 — 低	视觉异常、外观问题、拼写错误。对游戏玩法没有影响。

优先级（修复紧迫程度）

优先级	定义
P1 — 本冲刺修复	阻碍 QA、阻碍发布，或是上个冲刺引入的回归
P2 — 尽快修复	应在下一个重要里程碑前解决
P3 — 待办	修复会更好，但目前没有实际阻碍影响
P4 — 不予修复／延期	已接受的风险，或超出当前产品范围

分配

对于 sprint 模式下的每个 P1/P2 Bug：

• 确定修复所属的故事或 Epic
• 检查当前冲刺是否还有剩余容量
• 如果有容量：分配到冲刺（Sprint: [current]）
• 如果容量已满：标记为 Priority overflow — consider pulling from sprint

对于 full 模式：将所有 P1 分配到当前冲刺，P2 按预计分配到下一个冲刺， P3 及以上优先级分配到待办。

偏差检查

标记可能反映系统性问题的 Bug：

• 同一冲刺中来自同一系统的 Bug 达到 3 个或以上 → “[system] 可能存在设计或实现质量问题”
• 同一故事中有 2 个或以上 S1/S2 Bug → “故事可能需要重新打开，并在发布前重新评审”
• Bug 归属的故事已标记为 Complete → “已完成故事出现回归 — 应在冲刺跟踪中重新打开该故事”

---

4. 趋势分析

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

数量趋势

• 未解决 Bug 总数：[N]
• 本冲刺新建：[N]
• 本冲刺已关闭：[N]
• 净变化：[+N / -N]

系统热点

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

时长分析

• 有多少 Bug 的存在时间超过 2 个冲刺？
• 是否有未分配的 S1/S2 Bug（sprint = none）？

回归指标

• 是否有 Bug 归属于之前已完成的故事？
• 数量：[N] 个回归 Bug（意味着故事已重新打开）

---

5. 生成分诊报告

# 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-NNNN | [system] | S[1-4] | [one-line description] | [sprint] | [story path] |

---

## P2 Bugs — Fix Soon

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

---

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

| ID | System | Severity | Summary | Disposition |
|----|--------|----------|---------|-------------|
| BUG-NNNN | [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. 撰写并把关

在对话中呈现报告。如果有任何 Bug 可能属于 P4，先询问 “这些可以接受为不予修复吗？”，并在用户回答前将其处置状态保持为 P4 candidate。然后询问：

“我可以将这份分诊报告写入 production/qa/bug-triage-[date].md 吗？”

仅在获得批准后写入。

写入后：

• 如果有任何 S1 Bug 未分配：“S1 Bug 必须先完成分配，才能认为冲刺状态良好。运行 /sprint-status 查看当前容量。”
• 如果存在回归 Bug：“发现回归 — 请考虑在冲刺跟踪中重新打开受影响的故事，并运行 /smoke-check 重新把关。”
• 如果不存在 P1 Bug：“没有 P1 Bug — 构建状态良好，可以交接给 QA。”

无论是否存在 P1 Bug，之后均给出结论：COMPLETE — 分诊报告已写入。

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

---

协作协议

• 未经用户批准，绝不关闭 Bug 或将其标记为不予修复 — 将其列为 P4 候选项，并询问：“这些可以接受为不予修复吗？”
• 冲刺容量已满时，绝不自动分配到该冲刺 — 标记容量溢出，并由冲刺负责人决定从冲刺中移出哪些事项
• 严重程度是客观的；优先级由团队决定 — 将严重程度分类作为建议提出，而不是强制要求
• 趋势数据仅供参考 — 不要仅因趋势发现而阻碍工作；将其作为观察结果提出