ousiass/bug-report

bug-report

非エンジニアでも利用可能。対話に答えるだけで適切なバグレポートが作成される。

前提条件

• Claude Code 環境
• gh CLI（GitHub Issue 出力時）

引数

• テキスト (例: /bug-report ログインできない): 初期情報として扱い、不足分をヒアリング
• 引数なし: 最初からヒアリングを開始

フェーズ1: ヒアリング

平易な日本語で質問し、技術用語は使わない。

1-1: 基本情報の収集

AskUserQuestion で以下をまとめて聞く（引数でわかっている情報はスキップ）：

1. 何が起きたか: どんな問題が発生しているか
2. どこで起きたか: どの画面・機能・ページか
3. エラーメッセージ: 画面やコンソールに表示されたか（スクリーンショットの依頼）

1-2: 状況に応じた追加質問

回答内容に応じて必要な情報だけ追加で聞く（最大3つ、回答から推測できることは聞かない）：

| 状況 | 追加で聞くこと | |------|-------------| | エラーメッセージあり | エラーの詳細、スクリーンショット | | 再現条件が不明 | 毎回か特定条件か | | 画面・UI の問題 | ブラウザ、デバイス、画面サイズ | | データの問題 | 特定データ・アカウントでのみか | | タイミングの問題 | いつから、直前の変更 | | 操作手順が不明確 | 具体的な操作手順 |

フェーズ2: コードベース調査

1. 関連コードの特定 — 画面名・機能名・エラーメッセージで Grep/Glob 検索。必要に応じて Explore エージェントで広範な調査
2. 原因箇所の推定 — エラーメッセージやスタックトレースから追跡。確度を明示（確実 / 可能性が高い / 要調査）
3. 影響範囲の確認 — 同じコードを使う他の機能、関連テストを確認
4. 再現の試行 — テストやコマンドで再現可能な場合のみ。テスト作成はしない

フェーズ3: 重複チェック

1. gh issue list --state open --search "<バグの要約>" で既存 Issue を検索
2. 類似 Issue あり → ユーザーに報告し、既存にコメント or 新規作成か確認

フェーズ4: プレビューと出力先の確認

1. 収集情報と調査結果から下書きを作成
2. ユーザーにプレビュー表示。必ず以下を含める：
   • タイトル（後述ルールに従う）
   • 付与ラベル一覧（新規作成が必要なものは (NEW) を明示）
   • 本文（技術的内容 + 平易な説明）
3. 修正があれば反映
4. AskUserQuestion で出力先を確認：
   • GitHub Issue（推奨）
   • ローカル MD ファイル

タイトル・ラベルの統一ルール（GitHub Issue 出力時）

タイトル形式

[Bug] <機能>: <症状> で固定。

• <機能> — バグ発生箇所の画面・機能・モジュール名を 1〜3 語で。コード調査で確認した実際の名前を優先する。日本語可。
• <症状> — 何が起きているかを簡潔に。終止形または体言止め。

例:

• [Bug] ログイン: 正しいパスワードでも認証に失敗する
• [Bug] 検索: 日本語入力で結果が0件になる
• [Bug] 注文確認画面: 合計金額が二重表示される

ラベル（必ず以下 4 種を付与）

1. bug — 固定
2. severity:<level> — フェーズ4 の重大度判定に対応:
   • 🔴 Critical → severity:critical
   • 🟠 High → severity:high
   • 🟡 Medium → severity:medium
   • 🟢 Low → severity:low
3. area:<領域> — 機能領域。コード調査で特定したモジュール名・ディレクトリ名を kebab-case 英小文字で。例: area:auth, area:search, area:checkout
4. type:<種類> — 次から 1 つ選ぶ:
   • type:ui — 画面表示・スタイル
   • type:api — API・バックエンド通信
   • type:data — データ・DB・状態管理
   • type:auth — 認証・認可
   • type:perf — パフォーマンス
   • type:logic — ビジネスロジック・計算
   • type:i18n — 国際化・ローカライズ

ラベル存在チェック

Issue 作成前に必ず実行：

gh label list --limit 200 --json name -q '.[].name'

• 存在する → そのまま使用
• 存在しない → プレビューで (NEW) マークを付けて表示し、ユーザー承認を得てから gh label create <name> で作成。承認なしに作成しない

フェーズ5: レポート出力

GitHub Issue

1. 「タイトル・ラベルの統一ルール」に従ってタイトル・ラベル 4 種を確定
2. 不足ラベルがあればユーザー承認後に gh label create で先に作成
3. 次の形で Issue 作成:

   gh issue create \
     --title "[Bug] <機能>: <症状>" \
     --label bug \
     --label "severity:<level>" \
     --label "area:<領域>" \
     --label "type:<種類>" \
     --body-file <本文>
   

4. 本文テンプレートは templates/issue.md を参照
5. URL をユーザーに報告

ローカル MD

• bug-report-<要約(kebab-case)>.md を生成
• パスをユーザーに報告

重大度の基準

| 重大度 | 基準 | 例 | |-------|------|-----| | 🔴 Critical | サービス停止、データ損失、セキュリティリスク | ログインできない、データが消える | | 🟠 High | 主要機能が使えない、回避策なし | 検索が動かない、保存できない | | 🟡 Medium | 機能は使えるが不便、回避策あり | 表示崩れ、動作が遅い | | 🟢 Low | 軽微、使用に支障なし | 誤字、色のずれ |

ルール

• ヒアリングでは技術用語を使わない。ユーザーが使った場合のみ同じ言葉で返す
• 質問は最小限。回答から推測できることは聞かない
• コード調査は推測ではなく実際のコードを確認
• 原因推定の確度は正直に示す
• Issue 作成前に必ずプレビューしてユーザー承認を得る
• コードを修正しない。成果物は Issue のみ
• 修正が必要な場合は /bug-fix #<Issue番号> を案内する