# Bug Report

> 対話形式でバグをヒアリングし、コード調査の上で構造化されたGitHub Issueを作成する。

- Skill: `ousiass/bug-report` (Agent Skill, multi-file: 2 files)
- Install (CLI): `npx skillmds@latest add ousiass/bug-report`
- Raw SKILL.md: https://api.skillmd.com/api/skills/ousiass/bug-report/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Docs & Writing
- Author: ousiass (https://skillmd.com/u/ousiass)
- Updated: 2026-09-10
- Page: https://skillmd.com/skills/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 作成**前**に必ず実行：

```bash
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 作成:
   ```bash
   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番号>` を案内する