Issue Review - 系統化問題分析

あなたは Issue Review モードに入り、系統的な問題分析ワークフローを実行し、5つの専門エージェントを連携させます。

五つのエージェント協調アーキテクチャ

                    ┌────────────────────┐
                    │  problem-analyzer  │
                    │   (問題分析)        │
                    └─────────┬──────────┘
                              │
                 ┌────────────┼────────────┐
                 ↓            ↓            ↓
        ┌──────────────┐ ┌──────────┐ ┌──────────────┐
        │diff-analyzer │ │codebase- │ │log-analyzer  │
        │ (条件トリガー)   │ │investigator│ │ (条件トリガー)   │
        │ 最近の変更？    │ │ (必ず実行) │ │ ログがある？      │
        └──────────────┘ └──────────┘ └──────────────┘
                 │            │            │
                 └────────────┼────────────┘
                              ↓
                    ┌────────────────────┐
                    │  root-cause-finder │
                    │   (仮説検証)        │
                    └────────────────────┘

エージェントの役割

完全なワークフロー

ステップ 1：問題の説明を収集する

ユーザーが問題の説明を提供している場合は、直接ステップ 2 に進みます。

ユーザーがまだ提供していない場合は、以下を尋ねてください。

分析する問題について説明してください：

• 問題の現象は何ですか？
• どのような環境で発生していますか？
• エラーメッセージはありますか？
• 再現方法は？
• 最近発生し始めたものですか？

ステップ 2：problem-analyzer を起動する

問題の説明を受け取ったら、Task ツールを使用して problem-analyzer エージェントをすぐに起動します。

problem-analyzer エージェントを使用して、以下のタスクを実行します：

問題の説明を分析します：
[ユーザーが提供した問題の説明]

要求：
1. まず、`references/common-patterns.md` に一致する既知の問題パターンがあるかどうかを確認します。
2. すべての既知の情報（現象、環境、再現手順、エラーメッセージ）を抽出します。
3. 情報のギャップを特定します。
4. 問題の種類と重大度を分類します。
5. 3〜5個の初期仮説を、可能性の高い順に提案します。
6. **重要**：以下の条件を判断します。
   - [ ] 条件 A：問題が「最近発生した」または「アップデート後に発生した」
   - [ ] 条件 B：問題の説明にログ、エラーメッセージ、スタックトレースが含まれている
7. 構造化された問題分析レポートを出力します。

フェーズ完了後：

• ユーザーに「✅ フェーズ 1 完了：問題分析」を報告します。
• 主要な仮説と条件判断の結果を表示します。
• 条件に基づいて次のステップを決定します。

ステップ 2.5：補助エージェントを起動する（条件トリガー）

problem-analyzer の条件判断に基づいて：

条件 A がトリガー：diff-analyzer を起動する

diff-analyzer エージェントを使用して、以下のタスクを実行します：

Git履歴を分析して、問題を引き起こした可能性のある変更を見つけます。

問題が最初に報告された時間：[問題分析レポートから抽出]
関連ファイル/モジュール：[調査の方向性から抽出]

要求：
1. 最近1〜2週間の関連するコミットを確認します。
2. 疑わしい変更（コアロジックの変更、構成の変更、依存関係の更新）を特定します。
3. 変更のタイムラインを作成します。
4. 高リスクのコミットをマークします。

条件 B がトリガー：log-analyzer を起動する

log-analyzer エージェントを使用して、以下のタスクを実行します：

ログとエラーメッセージを分析します。

ログ/エラーの内容：
[問題の説明から抽出]

要求：
1. エラーの種類とスタックトレースを解析します。
2. エラーパターンと頻度を識別します。
3. 時間分布を分析します。
4. エラーの発生源と関連性を見つけます。

両方の条件がトリガーされた場合：Task ツールを使用して、2つのエージェントを並行して起動します。

フェーズ完了後：ユーザーに「✅ フェーズ 1.5 完了：補助調査」を報告し、主要な発見を表示します。

ステップ 3：codebase-investigator を起動する

すべての前のフェーズの出力を codebase-investigator に渡します。

codebase-investigator エージェントを使用して、以下のタスクを実行します：

問題分析の結果に基づいてコードベースを調査します：
[problem-analyzer の分析レポート]

補助分析の結果（ある場合）：
[diff-analyzer の発見]
[log-analyzer の発見]

要求：
1. 関連するコードのエントリポイントを特定します。
2. 実行フローを追跡します。
3. 5〜7個の考えられる原因を識別し、動的な重み付けスコアリング（0〜100）を使用します。
4. 補助エージェントの発見を統合します。
5. コードの位置とスニペットを提供します。
6. 可能性の高い順に出力します。

フェーズ完了後：ユーザーに「✅ フェーズ 2 完了：コード調査」を報告し、考えられる原因のリストを表示します。

ステップ 4：root-cause-finder を起動する（反復）

最も可能性の高い仮説から検証を開始します。

root-cause-finder エージェントを使用して、以下のタスクを実行します：

仮説を検証します：[仮説の説明]
場所：[コードの位置]
可能性スコア：[XX/100]

補助分析の参照（ある場合）：
[diff-analyzer の疑わしいコミット]
[log-analyzer のエラーパターン]

要求：
1. 関連するコードを完全に読みます。
2. 実行ロジックを推論します。
3. 証拠を収集します（支持/反駁）。
4. 補助分析の発見を統合します。
5. 因果関係を確立します。
6. 判断：確認/部分確認/排除

反復ロジック：

• ✅ 確認：反復を停止し、ステップ 5 に進みます。
• ❓ 部分確認：記録し、次の仮説の検証を続行します。
• ❌ 排除：次の仮説の検証を続行します。
• 最大3つの仮説を検証します。

フェーズ完了後：ユーザーに「✅ フェーズ 3 完了：根本原因の特定」を報告します。

ステップ 5：最終レポートを生成する

構造化された分析レポートを生成します。

# 🎯 Issue Review 分析レポート

## 実行サマリー

| 項目 | 内容 |
|------|------|
| 問題 | [一言で説明] |
| Root Cause | [根本原因] |
| 位置 | `file:line` |
| 信頼度 | XX% |
| 優先度 | P0/P1/P2 |
| 使用エージェント | [実際に使用されたエージェントのリスト] |

## 分析プロセス

### フェーズ 1：問題分析（problem-analyzer）
[主要な発見と初期仮説]

### フェーズ 1.5：補助調査（実行された場合）

#### Git 履歴分析（diff-analyzer）
[疑わしいコミットと変更のタイムライン]

#### ログ分析（log-analyzer）
[エラーパターンと時間分布]

### フェーズ 2：コード調査（codebase-investigator）
[コードマップと考えられる原因のリスト]

### フェーズ 3：根本原因の検証（root-cause-finder）
[検証プロセスと結論]

## 根本原因

### 問題の位置
**ファイル**：`path/to/file.ext`
**行番号**：XX-YY
**関数**：`functionName()`

### 問題の説明
[問題の本質を詳細に説明]

### 完全な因果関係

[根本原因] ↓ 導致 [中間影響] ↓ 導致 [直接原因] ↓ 表現為 [表面症狀]

### コード分析
```[language]
// 問題のあるコード
[code snippet]

修復の提案

推奨される修復

// 修復後のコード
[fixed code]

修復の説明

[修復の理由と予想される効果を説明]

検証方法

1. コードレビュー：[検証手順]
2. テスト検証：[テスト方法]
3. 監視確認：[監視指標]

その他の発見

二次的な問題

• [問題 1] - 優先度: P2
• [問題 2] - 優先度: P3

技術的負債

• [負債 1]
• [負債 2]

分析完了時間：[timestamp] 使用エージェント：problem-analyzer → [補助エージェント] → codebase-investigator → root-cause-finder

---

## エラー処理

### エージェントの実行失敗

エージェントの実行が失敗した場合、または不完全な結果が返された場合：

1. **もう一度試す**（より明確な指示を使用）
2. **ダウングレード処理**：
   - diff-analyzer/log-analyzer が失敗 → スキップして、メインフローを続行します。
   - codebase-investigator が失敗 → problem-analyzer の仮説を使用して直接検証します。
   - root-cause-finder が失敗 → codebase-investigator の分析結果を出力します。
3. **ユーザーに通知**：どのフェーズで問題が発生したかを説明します。

### 確定的な Root Cause が見つからない

すべての仮説を確認できない場合：
1. 「部分的に確認された」仮説を集計します。
2. 必要な追加情報を説明します。
3. 現在の分析に基づいて一時的な提案を提供します。

### 複数の Root Causes

複数の確認された原因が見つかった場合：
1. 各 Root Cause を個別に説明します。
2. それらの関係（独立/共同作用）を分析します。
3. それぞれの修復提案と優先度を提供します。

### 情報不足

問題の説明が短すぎる場合は、以下を尋ねてください。
- ブラウザの開発者ツールのネットワーク/コンソールのスクリーンショット
- サーバーログ
- 詳細な再現手順
- 最近発生し始めたものかどうか

---

## 利用可能なコマンド

このスキルに加えて、以下も使用できます。

| コマンド | 用途 |
|------|------|
| `/analyze-issue [問題の説明]` | 完全な5つのエージェント分析フローをすばやく開始します。 |
| `/quick-analyze [問題の説明]` | 簡単な診断（明確なエラーメッセージがある場合に適しています）。 |

---

## 分析を開始する

**分析する問題の説明を提供してください**。すぐに系統的な分析プロセスを開始します。

すでに上記で問題の説明を提供している場合は、直接分析を開始します。