--- user-invocable: true description: "[バグ対応] 3. トラブルシューティング修正策で仮説→合理的な修正策の列挙" --- # [バグ対応] 3. トラブルシューティング修正策で仮説→合理的な修正策の列挙 (引数:Issue番号) ## 入力 - `$ARGUMENTS` : 対象のバグIssue番号 - 例: `#123` または `123` --- ## 🎯 目的 - 既存Issue内の **「考えられる原因(仮説)」** を起点に、**実行前の修正策候補一覧** を作成する - 出典ポリシーは `CLAUDE.md` の原則、および `doc/guide/ai_guidelines.md` の「情報源・引用(出典)ポリシー(詳細)」に従い、**根拠を伴う対応策** を整理する - 修正はまだ行わず、**合理性・現実性・影響範囲・検証手順** を明記した計画としてIssueコメントに追記する --- ## GitHub連携の前提 ### 必要な権限 以下の `gh` コマンドが実行可能であること: - `gh issue view` / `gh issue edit` - `gh issue comment` --- ## 手順 ### 1. Issue内容を取得 ```bash gh issue view {ISSUE_NUMBER} --json title,body,labels ``` 以下を抽出: - 「問題の概要」「再現手順」「期待する動作(理想状態)」「ギャップ」「考えられる原因(仮説)」 ### 2. 各仮説ごとに修正方針を探索 - 優先度:①公式Doc → ②公式GitHub(issue/PR) → ③英語圏Stack Overflow - 詳細は `doc/guide/ai_guidelines.md` を参照 ### 3. 修正策をIssueコメントで提案 ```bash gh issue comment {ISSUE_NUMBER} --body "📋 修正策提案 ## 修正策(候補一覧) ### 仮説A: {仮説の要約} #### 修正案1(推奨度: 高) - **概要**: {提案の要点} - **期待効果**: {どのギャップをどう埋めるか} - **影響範囲**: {関係モジュール/サービス/ユーザー影響} - **リスク**: {副作用、既知の相性問題、ダウンタイム等} - **前提条件**: {バージョン/設定/権限など} - **手順**: 1. {実施手順1} 2. {実施手順2} - **検証方法**: {再現テスト/ユニット/E2E/メトリクス等} - **ロールバック**: {戻し方・確認ポイント} #### 修正案2(推奨度: 中) ...(同様) ### 仮説B: {仮説の要約} ...(同様) --- ## 参考資料(出典) - [公式Doc] {タイトル} — {URL} - [公式GitHub Issue/PR] {番号/タイトル} — {URL} - [Stack Overflow] {スレッドタイトル} — {URL} --- ## 次のアクション \`/bug-fix {ISSUE_NUMBER}\` で修正案を実行 " ``` ### 4. 解決状況を更新 Issue本文の「解決状況」を `🟠 対応中` に更新する ```bash gh issue edit {ISSUE_NUMBER} --body "{解決状況を🟠対応中に更新した本文}" ``` --- ## 出力(GitHub) - **Issueコメント**: 修正策候補一覧と参考資料 - **Issue本文**: 解決状況を「🟠 対応中」に変更 --- ## 検索・評価ポリシー(参照) 詳細は `doc/guide/ai_guidelines.md` の「情報源・引用(出典)ポリシー(詳細)」に従う(= `CLAUDE.md` の原則を具体化)。 --- ## 品質チェックリスト - [ ] **各仮説に対して複数案** を提示している(決め打ち回避) - [ ] **出典が公式中心** で整理され、URLとタイトルが明記されている - [ ] **手順・検証・ロールバック** が揃っており、実運用を想定している - [ ] **影響範囲/リスク** を明示し、採用判断材料になる情報がある - [ ] **バージョン整合** と互換性の確認ができている - [ ] **二次情報の採用理由**(裏付け・妥当性)が記述されている - [ ] 解決状況が「🟠 対応中」に更新されている --- ## 自己評価 - **成功自信度**: (1-10) - **一言理由**: {短く理由を記載。例: 「公式PRでfix方針が確立、影響範囲も軽微」}