ousiass bug-report
非エンジニアでも利用可能。対話に答えるだけで適切なバグレポートが作成される。
前提条件
- Claude Code 環境
ghCLI（GitHub Issue 出力時）
引数
- テキスト (例:
/bug-report ログインできない): 初期情報として扱い、不足分をヒアリング - 引数なし: 最初からヒアリングを開始
フェーズ1: ヒアリング
平易な日本語で質問し、技術用語は使わない。
1-1: 基本情報の収集
AskUserQuestion で以下をまとめて聞く（引数でわかっている情報はスキップ）：
- 何が起きたか: どんな問題が発生しているか
- どこで起きたか: どの画面・機能・ページか
- エラーメッセージ: 画面やコンソールに表示されたか（スクリーンショットの依頼）
1-2: 状況に応じた追加質問
回答内容に応じて必要な情報だけ追加で聞く（最大3つ、回答から推測できることは聞かない）：
| 状況 | 追加で聞くこと |
|---|---|
| エラーメッセージあり | エラーの詳細、スクリーンショット |
| 再現条件が不明 | 毎回か特定条件か |
| 画面・UI の問題 | ブラウザ、デバイス、画面サイズ |
| データの問題 | 特定データ・アカウントでのみか |
| タイミングの問題 | いつから、直前の変更 |
| 操作手順が不明確 | 具体的な操作手順 |
フェーズ2: コードベース調査
- 関連コードの特定 — 画面名・機能名・エラーメッセージで
Grep/Glob検索。必要に応じてExploreエージェントで広範な調査 - 原因箇所の推定 — エラーメッセージやスタックトレースから追跡。確度を明示（確実 / 可能性が高い / 要調査）
- 影響範囲の確認 — 同じコードを使う他の機能、関連テストを確認
- 再現の試行 — テストやコマンドで再現可能な場合のみ。テスト作成はしない
フェーズ3: 重複チェック
gh issue list --state open --search "<バグの要約>"で既存 Issue を検索- 類似 Issue あり → ユーザーに報告し、既存にコメント or 新規作成か確認
フェーズ4: プレビューと出力先の確認
- 収集情報と調査結果から下書きを作成
- ユーザーにプレビュー表示。必ず以下を含める：
- タイトル（後述ルールに従う）
- 付与ラベル一覧（新規作成が必要なものは
(NEW)を明示） - 本文（技術的内容 + 平易な説明）
- 修正があれば反映
AskUserQuestionで出力先を確認：- GitHub Issue（推奨）
- ローカル MD ファイル
タイトル・ラベルの統一ルール（GitHub Issue 出力時）
タイトル形式
[Bug] <機能>: <症状> で固定。
<機能>— バグ発生箇所の画面・機能・モジュール名を 1〜3 語で。コード調査で確認した実際の名前を優先する。日本語可。<症状>— 何が起きているかを簡潔に。終止形または体言止め。
例:
[Bug] ログイン: 正しいパスワードでも認証に失敗する[Bug] 検索: 日本語入力で結果が0件になる[Bug] 注文確認画面: 合計金額が二重表示される
ラベル（必ず以下 4 種を付与）
bug— 固定severity:<level>— フェーズ4 の重大度判定に対応:- 🔴 Critical →
severity:critical - 🟠 High →
severity:high - 🟡 Medium →
severity:medium - 🟢 Low →
severity:low
- 🔴 Critical →
area:<領域>— 機能領域。コード調査で特定したモジュール名・ディレクトリ名を kebab-case 英小文字で。例:area:auth,area:search,area:checkouttype:<種類>— 次から 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
- 「タイトル・ラベルの統一ルール」に従ってタイトル・ラベル 4 種を確定
- 不足ラベルがあればユーザー承認後に
gh label createで先に作成 - 次の形で Issue 作成:
gh issue create \ --title "[Bug] <機能>: <症状>" \ --label bug \ --label "severity:<level>" \ --label "area:<領域>" \ --label "type:<種類>" \ --body-file <本文> - 本文テンプレートは
templates/issue.mdを参照 - URL をユーザーに報告
ローカル MD
bug-report-<要約(kebab-case)>.mdを生成- パスをユーザーに報告
重大度の基準
| 重大度 | 基準 | 例 |
|---|---|---|
| 🔴 Critical | サービス停止、データ損失、セキュリティリスク | ログインできない、データが消える |
| 🟠 High | 主要機能が使えない、回避策なし | 検索が動かない、保存できない |
| 🟡 Medium | 機能は使えるが不便、回避策あり | 表示崩れ、動作が遅い |
| 🟢 Low | 軽微、使用に支障なし | 誤字、色のずれ |
ルール
- ヒアリングでは技術用語を使わない。ユーザーが使った場合のみ同じ言葉で返す
- 質問は最小限。回答から推測できることは聞かない
- コード調査は推測ではなく実際のコードを確認
- 原因推定の確度は正直に示す
- Issue 作成前に必ずプレビューしてユーザー承認を得る
- コードを修正しない。成果物は Issue のみ
- 修正が必要な場合は
/bug-fix #<Issue番号>を案内する