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 カテゴリでは常に確認します）。

バグトリアージ

このスキルは、未解決のバグバックログを優先順位付けし、スプリントを割り当てた アクションリストに整理します。重大度（影響はどの程度深刻か？）と 優先度（どれだけ急いで修正すべきか？）を区別し、システム全体の傾向を検出して、 スプリント間で重大なバグが見失われないようにします。

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

実行するタイミング：

• スプリント開始時 — 未解決のバグを新しいスプリントまたはバックログに割り当てます
• /team-qa の完了後、新しいバグが登録されたとき
• 未解決のバグが10件以上になったとき

---

1. 引数を解析する

モード：

• /bug-triage sprint — 現在のスプリントを対象にトリアージします。修正可能なバグを スプリントのバックログに割り当て、残りは後回しにします
• /bug-triage full — スプリントの範囲にかかわらず、すべてのバグを完全にトリアージします
• /bug-triage trend — 傾向分析のみを行います（割り当てなし）。読み取り専用レポートです
• 引数なし — 現在のスプリントがあれば sprint モード、なければ full モードを実行します

---

2. バグバックログを読み込む

ステップ2a — バグファイルを特定する

優先順位に従って、バグレポートを glob で検索します。

1. production/qa/bugs/*.md — 個別のバグレポートファイル（推奨形式）
2. production/qa/bugs.md — 単一の統合バグログ（代替）
3. production/qa/qa-plan-*.md の「Bugs Found」テーブル（最終手段）

バグファイルが見つからない場合：

"production/qa/bugs/ にバグファイルが見つかりません。バグを別の場所で管理している場合は、 glob パターンを調整してください。まだバグがない場合、トリアージするものは ありません。"

停止して報告します。バグが存在しない場合は処理を続行しないでください。判定：完了 — production/qa/bugs/ にバグファイルがなく、トリアージするものはありません。

trend モードでは、バグ本文全体を読み込まないでください。 傾向指標（件数、重大度の 内訳、システム別、日付別）はヘッダーフィールドだけで算出できます。

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

（バグレポートのフィールドは太字で記述されています — **Severity**:、- **System**: — したがって、行頭に単独である Field: 形式ではなく、**field** 形式に一致させてください。） バグ本文全体が必要なのは、sprint／full モードで優先度と重大度を 再評価する場合だけです。trend は読み取り専用レポートのため、本文の読み込みを 省略します。（ストーリーのステータスが必要な唯一の逸脱チェックである「Complete ストーリーに対して登録されたバグ」は、いずれの場合もバグ本文を読むのではなく、対象を絞った ストーリーステータスの grep で確認します。）

ステップ2b — スプリントの状況を読み込む

production/sprints/ 内で最終更新日時が最も新しいファイルを読み込み、以下を確認します。

• 現在のスプリント番号／名前
• 対象ストーリー（割り当て先）
• スプリントの容量制約（記載されている場合）

スプリントファイルがない場合は、「スプリント計画が見つかりません — バックログにのみ割り当てます。」と記録します。workflow: minimal では設計上スプリントがないため、その旨を伝え、ブリーフの構築順で次のストーリーより先に修正する P1 バグを挙げます。

ステップ2c — 重大度の基準を読み込む

.claude/docs/coding-standards.md が存在する場合は、重大度／優先度の定義を読み込みます。 存在しない場合は、ステップ3の標準定義を使用します。

---

3. 各バグを分類する

各バグについて、以下の情報を抽出または推定します。

重大度（バグの影響）

重大度	定義
S1 — 致命的	ゲームがクラッシュする、データが失われる、または機能が完全に動作しない。この時点から先に進めません。
S2 — 高	主要機能が壊れていますが、ゲームのプレイは可能です。動作に重大な誤りがあります。
S3 — 中	機能が劣化していますが、回避策があります。動作に軽微な誤りがあります。
S4 — 低	表示上の不具合、見た目の問題、誤字。ゲームプレイへの影響はありません。

優先度（修正の緊急度）

優先度	定義
P1 — 今スプリントで修正	QA を妨げている、リリースを妨げている、または前回のスプリントからのリグレッション
P2 — 早急に修正	次の主要なマイルストーンまでに解決する必要がある
P3 — バックログ	修正が望ましいものの、現在、作業を妨げる影響はない
P4 — 修正しない／延期	許容されるリスク、または現在のプロダクトの対象範囲外

割り当て

sprint モードでは、P1/P2 の各バグについて：

• 修正がどのストーリーまたはエピックに属するかを特定します
• 現在のスプリントに残りのキャパシティがあるかを確認します
• キャパシティがある場合：スプリントに割り当てます（Sprint: [current]）
• キャパシティが満杯の場合：Priority overflow — consider pulling from sprint としてフラグを付けます

full モードでは、すべての P1 を現在のスプリントに割り当て、P2 は次のスプリントでの見積もり対象とし、P3 以上はバックログに入れます。

逸脱の確認

体系的な問題を示唆するバグにフラグを付けます：

• 同じスプリントで、同じシステムから3件以上のバグが発生 → 「[system] で設計または実装品質に問題がある可能性があります」
• 同じストーリーに S1/S2 のバグが2件以上ある → 「リリース前にストーリーを再オープンし、再レビューする必要がある可能性があります」
• Complete とマークされたストーリーに対して起票されたバグ → 「完了済みストーリーでリグレッションが発生しています — スプリントの追跡でストーリーを再オープンする必要があります」

---

4. 傾向分析

すべてのバグを分類した後、傾向の指標を生成します：

件数の傾向

• オープン中のバグの合計：［N］
• 今スプリントで起票されたバグ：［N］
• 今スプリントでクローズされたバグ：［N］
• 純増減：［+N / -N］

システムの注目箇所

• オープン中のバグが最も多いシステムはどれですか？
• S1/S2 の割合が最も高いシステムはどれですか？

経過期間の分析

• 2スプリントを超えて経過したバグはいくつありますか？
• 割り当てられていない S1/S2 バグ（sprint = none）はありますか？

リグレッションの指標

• 以前に完了したストーリーに対して起票されたバグはありますか？
• 件数：［N］件のリグレッションバグ（ストーリーの再オープンが必要と推測）

---

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. 作成と承認確認

レポートを会話内で提示します。P4 候補のバグがある場合は、まず 「これらを修正しないものとして受け入れてよいですか？」と質問し、ユーザーが回答するまで処置を P4 candidate のままにします。その後、次のように質問します：

「このトリアージレポートを production/qa/bug-triage-[date].md に書き込んでもよいですか？」

承認を得てから書き込みます。

書き込み後：

• 割り当てられていない S1 バグがある場合：「S1 バグは、スプリントが健全と見なされる前に割り当てる必要があります。現在のキャパシティを確認するには /sprint-status を実行してください。」
• リグレッションバグがある場合：「リグレッションが見つかりました — スプリントの追跡で該当するストーリーを再オープンし、再度ゲートを実施するために /smoke-check を実行することを検討してください。」
• P1 バグがない場合：「P1 バグはありません — QA への引き継ぎに向けてビルドは良好な状態です。」

その後、P1 バグの有無にかかわらず、判定：COMPLETE — トリアージレポートを書き込みました。

ユーザーが書き込みを拒否した場合：判定：BLOCKED — ユーザーが書き込みを拒否しました。

---

協働プロトコル

• ユーザーの承認なしに、バグをクローズしたり修正しないものとしてマークしたりしないでください — P4 候補として提示し、「これらを修正しないものとして受け入れてよいですか？」と質問します
• キャパシティが満杯のスプリントに自動で割り当てないでください — オーバーフローにフラグを付け、何をスプリントから外すかはスプリントオーナーに判断してもらいます
• 重大度は客観的ですが、優先度はチームの判断です — 重大度の分類は指示ではなく推奨として提示します
• 傾向データは参考情報です — 傾向の調査結果だけを理由に作業を妨げず、観察事項として提示します