user-invocable: true description: "[バグ対応] 1. トラブルシューティングログ生成"
[バグ対応] 1. トラブルシューティングログ生成コマンド (引数：問題内容やエラー分・解決したいこと)
入力
$ARGUMENTS: 問題概要・エラー文、または関連ファイル/ディレクトリのパス
🎯 目的
- 問題解決型思考に基づき、現状把握を徹底する
- AIがエラーや問題に直面した際、原因候補・調査方針・対処計画を修正前に整理する
- GitHub Issue として記録し、後から実際の解決プロセスを追記・更新できるようにする
- 問題を再現・調査・解決する履歴を Issueコメントで時系列に残し、再利用性を高める
GitHub連携の前提
必要な権限
以下の gh コマンドが実行可能であること：
gh issue create/gh issue viewgh issue edit/gh issue comment
手順（問題解決型思考に基づく流れ）
-
現状把握（As-Isの分析）
$ARGUMENTSの内容（問題概要・エラー文など）を精査する- 環境・再現条件・発生状況をできる限り詳細に書き出す
- 「何が起きているか」を客観的に記録する（まだ原因や対処に飛ばない）
-
理想状態の確認（To-Beの明確化）
- 本来期待される動作や、正常時の状態を定義する
-
ギャップ特定（問題の定義）
- 現状と理想の差分を明確化し、「何が問題なのか」を定義する
-
原因仮説の列挙
- 考えられる原因を複数洗い出し、決め打ちを避ける
- 技術的要因 / 環境要因 / 設定要因などに分けてもよい
-
調査・対処計画の立案
- 仮説を検証するための調査手順を箇条書きで列挙
- 恒久対応策・暫定対応策を分けて整理する
- ⚠️ 修正作業はまだ実行せず、計画までをまとめる
出力手順
GitHub Issue作成
gh issue create \
--title "🐛 {短いタイトル}" \
--body "$(cat <<'EOF'
## 問題の概要（現状把握）
{簡潔に・事実ベースで記載}
## 再現手順
1. {環境・操作手順をステップ形式で}
2. ...
## 期待する動作（理想状態）
{本来の挙動}
## ギャップ（問題の定義）
{現状と理想の差}
## 考えられる原因（仮説）
- [ ] 仮説A: {原因候補1}
- [ ] 仮説B: {原因候補2}
- [ ] 仮説C: {原因候補3}
## 調査・対処計画
### 検証方針
- {仮説Aの検証方法}
- {仮説Bの検証方法}
### 暫定対応
- {あれば記載}
### 恒久対応
- {あれば記載}
## 関連ファイル
- `src/...`
- `doc/...`
## 解決状況
🔴 未対応
EOF
)" \
--label "bug"
出力（GitHub）
- Issue: ラベル
bugで作成 - Issue番号をメモし、後続の
/bug-investigateで使用
品質チェックリスト
- 現状把握が 事実ベース で十分に書かれている
- 理想状態（期待する動作）が明確化されている
- 現状と理想の差分（ギャップ）が定義されている
- 仮説が複数挙がっている（単一原因に決め打ちしない）
- 調査・対処計画が明示されている（暫定/恒久を分ける）
- 関連ファイルやコード断片が紐づいている
- GitHub Issueが作成されている
自己評価
- 成功自信度: (1-10)
- 一言理由: {短く理由を記載}