/analyze-issue

description: 系統化分析問題並定位根本原因，支援五代理深度分析流程
allowedTools:
  - Task
  - Read
  - Glob
  - Grep
  - Bash
  - TodoWrite
  - WebSearch

/analyze-issue - 問題分析命令

你將執行系統化的問題分析流程，協調五個專門代理從問題描述到根本原因定位。

問題描述

$ARGUMENTS

自動化分析流程

請按以下順序執行分析，根據問題特徵動態選擇代理組合：

階段 1：問題分析

使用 **problem-analyzer** 代理分析問題：

任務：分析以下問題描述，提取關鍵資訊並制定調查方向

問題描述：
$ARGUMENTS

要求：
1. 檢查是否匹配 `references/common-patterns.md` 中的已知問題模式
2. 提取所有可用資訊（現象、環境、重現步驟、錯誤訊息）
3. 識別資訊缺口
4. 分類問題（類型、嚴重程度、緊急程度）
5. 提出 3-5 個初步假設，並按可能性排序
6. 制定具體的調查方向
7. **重要**：判斷問題特徵，標記以下條件：
   - [ ] 條件 A：問題「最近才發生」或「更新後出現」→ 需要 diff-analyzer
   - [ ] 條件 B：問題描述包含日誌、錯誤訊息、堆疊追蹤 → 需要 log-analyzer

輸出格式：結構化的問題分析報告，包含條件判斷結果

**階段 1 完成後**：向用戶報告進度，並根據條件判斷進入階段 1.5 或階段 2。

---

階段 1.5：輔助調查（條件觸發）

根據階段 1 的條件判斷，**並行**啟動輔助代理：

條件 A 觸發：使用 diff-analyzer

任務：分析 Git 歷史，找出可能引入問題的變更

問題首次報告時間：[從階段 1 提取]
相關檔案/模組：[從階段 1 的調查方向提取]

要求：
1. 查看最近 1-2 週的相關提交
2. 識別可疑的變更（修改核心邏輯、配置變更、依賴更新）
3. 建立變更時間線
4. 標記高風險提交
5. 輸出：可疑提交列表及分析

條件 B 觸發：使用 log-analyzer

任務：分析日誌和錯誤訊息

日誌/錯誤訊息：
[從問題描述提取的日誌內容]

要求：
1. 解析錯誤類型和堆疊追蹤
2. 識別錯誤模式和頻率
3. 分析時間分佈
4. 找出錯誤源頭和關聯性
5. 輸出：日誌分析報告

**如果兩個條件都觸發**：並行執行兩個代理，等待結果後進入階段 2。

**如果沒有條件觸發**：直接進入階段 2。

---

階段 2：程式碼庫調查

使用 **codebase-investigator** 代理調查程式碼：

任務：基於階段 1（及階段 1.5）的分析結果，調查程式碼庫

輸入：
- 問題分析報告（階段 1）
- Git 歷史分析（如果有，來自 diff-analyzer）
- 日誌分析報告（如果有，來自 log-analyzer）

要求：
1. 定位相關程式碼的進入點（API、事件處理器）
2. 追蹤完整的執行流程
3. 識別 5-7 個可能的問題原因
4. 為每個原因評分（0-100），使用動態權重：
   - 配置問題：症狀 20 + 邏輯 20 + 歷史 20 + 環境 40
   - 最近出現問題：症狀 25 + 邏輯 25 + 歷史 30 + 環境 20
   - 效能問題：症狀 30 + 邏輯 35 + 歷史 15 + 環境 20
   - 一般問題：症狀 30 + 邏輯 30 + 歷史 20 + 環境 20
5. 整合輔助代理的發現（如果有）
6. 按可能性排序

輸出格式：程式碼地圖 + 執行流程 + 可能原因列表（整合所有來源）

---

階段 3：根本原因定位（迭代）

使用 **root-cause-finder** 代理驗證假設：

任務：從最高可能性的假設開始，逐一深入驗證

輸入：
- 可能原因列表（來自 codebase-investigator）
- 輔助分析結果（如果有，來自 diff-analyzer / log-analyzer）

驗證流程：
1. 完整閱讀相關程式碼
2. 推演執行邏輯
3. 收集支持/反駁證據
4. 整合輔助代理的發現（如果有）
5. 建立因果鏈
6. 做出判斷：
   - ✅ 確認 (Root Cause Found) → 進入報告階段
   - ❓ 部分確認 (Probable) → 記錄，繼續下一假設
   - ❌ 排除 (Ruled Out) → 繼續下一假設

停止條件：找到確認的 Root Cause 或已驗證前 3 個假設

---

階段 4：生成最終報告

完成分析後，生成結構化報告：

# 🎯 Issue Review 分析報告

## 執行摘要
- **問題**：[一句話描述]
- **Root Cause**：[根本原因]
- **位置**：[檔案:行號]
- **信心度**：[XX%]
- **使用代理**：[列出實際使用的代理]

## 分析過程

### 問題分析（problem-analyzer）
[階段 1 的關鍵發現]

### 輔助調查（如果有）

#### Git 歷史分析（diff-analyzer）
[可疑提交和變更時間線]

#### 日誌分析（log-analyzer）
[錯誤模式和時間分佈]

### 程式碼調查（codebase-investigator）
[程式碼地圖和可能原因列表]

## 根本原因詳解
[完整的因果鏈分析]

## 修復建議
[包含程式碼的修復方案]

## 驗證方法
[如何確認修復有效]

## 其他發現
[次要問題和技術債務]

---

執行指示

1. **立即開始**：不要詢問用戶，直接從階段 1 開始執行 2. **條件判斷**：階段 1 完成後，根據問題特徵決定是否執行階段 1.5 3. **並行執行**：如果需要執行多個輔助代理，使用 Task 工具並行啟動 4. **資訊整合**：每個階段都要整合前面階段的發現 5. **階段轉換**：每個階段完成後，簡要報告進度，然後繼續下一階段 6. **迭代控制**：階段 3 最多驗證 3 個假設 7. **最終報告**：務必生成結構化的最終報告，標明使用了哪些代理

---

錯誤處理

如果某個代理執行失敗或返回不完整結果：

1. **重試一次**（使用更明確的指示） 2. **降級處理**：

• 如果 diff-analyzer/log-analyzer 失敗 → 跳過，繼續主流程
• 如果 codebase-investigator 失敗 → 使用 problem-analyzer 的假設直接驗證
• 如果 root-cause-finder 失敗 → 輸出 codebase-investigator 的分析結果作為初步結論

3. **告知用戶**：說明哪個階段遇到問題，建議手動調查

現在開始執行分析流程。