用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
直接命令不会经过审查 Prompt；运行前请先检查来源。
npx skills add https://github.com/aiskillstore/marketplace --skill issue-review命令会保持在同一行。复制前请横向滚动并检查完整内容。
想先保存到本地？可下载 SkillsMP 当前能够提供的文件。
基于 SOC 职业分类
正在显示 SKILL.md
| name | issue-review |
| description | 系統化的問題分析專家技能，自動協調五個專門代理進行深度問題分析。 適用於： - 使用者或 PM 報告的線上問題 - 開發團隊反映的技術問題 - 測試發現的 bug - 生產環境告警和異常 |
你已進入 Issue Review 模式，將執行系統化的問題分析工作流程，協調五個專門代理。
┌────────────────────┐
│ problem-analyzer │
│ (問題分析) │
└─────────┬──────────┘
│
┌────────────┼────────────┐
↓ ↓ ↓
┌──────────────┐ ┌──────────┐ ┌──────────────┐
│diff-analyzer │ │codebase- │ │log-analyzer │
│ (條件觸發) │ │investigator│ │ (條件觸發) │
│ 最近變更? │ │ (必定執行) │ │ 有日誌? │
└──────────────┘ └──────────┘ └──────────────┘
│ │ │
└────────────┼────────────┘
↓
┌────────────────────┐
│ root-cause-finder │
│ (假設驗證) │
└────────────────────┘
| 代理 | 顏色 | 模型 | 角色 |
|---|---|---|---|
| problem-analyzer | 🟡 黃色 | Sonnet | 問題資訊提取、分類、初步假設 |
| codebase-investigator | 🔵 藍色 | Sonnet | 程式碼定位、流程追蹤、原因評分 |
| root-cause-finder | 🟣 紫色 | Opus | 假設驗證、因果鏈、根本原因確認 |
| diff-analyzer | 🟢 綠色 | Sonnet | Git 歷史分析、變更追蹤 |
| log-analyzer | 🟠 橙色 | Sonnet | 日誌解析、錯誤模式識別 |
如果用戶已提供問題描述，直接進入步驟 2。
如果用戶尚未提供，請詢問：
請描述您要分析的問題：
- 問題現象是什麼？
- 發生在什麼環境？
- 有錯誤訊息嗎？
- 如何重現？
- 是最近才開始發生的嗎？
收到問題描述後，立即使用 Task 工具啟動 problem-analyzer 代理：
使用 problem-analyzer 代理執行以下任務：
分析問題描述：
[用戶提供的問題描述]
要求：
1. 先檢查 `references/common-patterns.md` 是否有匹配的已知問題模式
2. 提取所有已知資訊（現象、環境、重現步驟、錯誤訊息）
3. 識別資訊缺口
4. 分類問題類型和嚴重程度
5. 提出 3-5 個初步假設，按可能性排序
6. **重要**：判斷以下條件
- [ ] 條件 A：問題「最近才發生」或「更新後出現」
- [ ] 條件 B：問題描述包含日誌、錯誤訊息、堆疊追蹤
7. 輸出結構化的問題分析報告
階段完成後：
根據 problem-analyzer 的條件判斷：
使用 diff-analyzer 代理執行以下任務：
分析 Git 歷史，找出可能引入問題的變更
問題首次報告時間：[從問題分析報告提取]
相關檔案/模組：[從調查方向提取]
要求：
1. 查看最近 1-2 週的相關提交
2. 識別可疑變更（核心邏輯修改、配置變更、依賴更新）
3. 建立變更時間線
4. 標記高風險提交
使用 log-analyzer 代理執行以下任務：
分析日誌和錯誤訊息
日誌/錯誤內容：
[從問題描述提取]
要求：
1. 解析錯誤類型和堆疊追蹤
2. 識別錯誤模式和頻率
3. 分析時間分佈
4. 找出錯誤源頭和關聯性
如果兩個條件都觸發：使用 Task 工具並行啟動兩個代理。
階段完成後：向用戶報告「✅ 階段 1.5 完成：輔助調查」並展示關鍵發現。
將所有前置階段的輸出傳遞給 codebase-investigator：
使用 codebase-investigator 代理執行以下任務：
基於問題分析結果調查程式碼庫：
[problem-analyzer 的分析報告]
輔助分析結果（如果有）：
[diff-analyzer 的發現]
[log-analyzer 的發現]
要求：
1. 定位相關程式碼進入點
2. 追蹤執行流程
3. 識別 5-7 個可能原因並使用動態權重評分 (0-100)
4. 整合輔助代理的發現
5. 提供程式碼位置和片段
6. 按可能性排序輸出
階段完成後：向用戶報告「✅ 階段 2 完成：程式碼調查」並展示可能原因列表。
從最高可能性假設開始驗證：
使用 root-cause-finder 代理執行以下任務：
驗證假設：[假設描述]
位置：[程式碼位置]
可能性評分：[XX/100]
輔助分析參考（如果有）：
[diff-analyzer 的可疑提交]
[log-analyzer 的錯誤模式]
要求：
1. 完整閱讀相關程式碼
2. 推演執行邏輯
3. 收集證據（支持/反駁）
4. 整合輔助分析的發現
5. 建立因果鏈
6. 判斷：確認/部分確認/排除
迭代邏輯：
階段完成後：向用戶報告「✅ 階段 3 完成：根本原因定位」
生成結構化的分析報告：
# 🎯 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]
[解釋修復的原因和預期效果]
分析完成時間：[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 [問題描述]` | 快速啟動完整五代理分析流程 |
| `/quick-analyze [問題描述]` | 快速診斷（適用於有明確錯誤訊息） |
---
## 開始分析
**請提供您要分析的問題描述**，我將立即啟動系統化的分析流程。
如果您已經在上方提供了問題描述，我將直接開始分析。