---
name: custom-skills-plan-analyze
description: |
  分析計畫、報告或變更提案的完整性與對專案的影響評估。
  Use when: 使用者提供一份文件（計畫書、技術債評估、修改方案、RFC、ADR、資安報告等）並要求分析其品質、完整性或潛在風險。
  觸發方式: /custom-skills-plan-analyze @文件路徑
  Keywords: 計畫分析, 報告評估, 影響分析, 風險評估, 完整性檢查, plan review, impact analysis, risk assessment, change analysis, 技術債, RFC review
---

# Plan Analyze — 計畫與報告影響分析

## 使用方式

```
/custom-skills-plan-analyze @path/to/document.md
```

接收一份文件，執行系統化的多維度分析，輸出結構化的評估報告。

---

## 分析流程

### 階段 0：文件識別與上下文建立

0. 若文件包含 YAML frontmatter 且有 `type` 欄位，直接採用作為文件類型，跳到步驟 2；若無，繼續步驟 1 從內容推斷。
1. 讀取目標文件，識別文件類型：
   - 技術債評估 / 資安報告
   - 功能變更提案 / RFC
   - 修復方案 / Hotfix 計畫
   - 架構決策紀錄 (ADR)
   - 測試計畫 / 部署計畫
   - 其他（標註類型）

2. 識別文件涉及的專案與檔案：
   - 若文件提及具體檔案路徑，嘗試讀取以獲得完整上下文
   - 若文件關聯其他報告（如 REPORT-008 → REPORT-009），提示使用者是否需要一併分析

### 階段 1：分析評估完善度

評估文件本身的分析品質：

| 檢查項 | 說明 |
|--------|------|
| 問題定義 | 問題是否清楚定義？是否有重現條件或觸發場景？ |
| 範圍界定 | 影響範圍是否明確？是否遺漏相關模組或檔案？ |
| 根因分析 | 是否追溯到根本原因，而非僅描述症狀？ |
| 證據支撐 | 結論是否有程式碼片段、日誌、數據佐證？ |
| 風險量化 | 風險等級是否有明確的判定標準？是否過度樂觀或悲觀？ |
| 邊界案例 | 是否考慮了邊界條件、異常輸入、併發場景？ |
| 遺漏檢測 | 是否存在「應該分析但未提及」的面向？ |

輸出格式：
```
### 1. 分析評估完善度

| 項目 | 評級 | 說明 |
|------|------|------|
| 問題定義 | [充分/部分/不足] | ... |
| ... | ... | ... |

**遺漏項**: [列出未涵蓋但應考慮的面向]
```

### 階段 2：功能設計完整性

評估提案的修改或設計是否完整：

| 檢查項 | 說明 |
|--------|------|
| 修改範圍 | 所有需要修改的位置是否都已列出？ |
| 向下相容 | 修改是否保持 API / 資料格式的向下相容？ |
| 資料遷移 | 是否需要資料庫遷移？遷移方案是否完整？ |
| 配置變更 | 是否需要修改配置檔、環境變數或部署設定？ |
| 依賴影響 | 是否影響上下游模組或第三方整合？ |
| 錯誤處理 | 異常情境的處理是否完善？ |
| 回滾方案 | 若修改失敗，是否有回滾策略？ |

輸出格式：
```
### 2. 功能設計完整性

| 項目 | 評級 | 說明 |
|------|------|------|
| 修改範圍 | [完整/部分/不足] | ... |
| ... | ... | ... |

**缺失項**: [列出設計中未涵蓋的必要元素]
```

### 階段 3：既有流程影響評估

分析修改是否破壞現有功能：

1. **識別受影響的業務流程**
   - 列出修改涉及的所有業務流程（如：結帳流程、訂單建立、付款確認）
   - 每個流程標註：[無影響 / 低影響 / 中影響 / 高影響]

2. **呼叫鏈追蹤**
   - 若可讀取原始碼，追蹤修改函式的呼叫者與被呼叫者
   - 識別是否有隱含的耦合關係

3. **狀態與資料流分析**
   - 修改是否改變了資料的格式、類型或流向？
   - 是否影響快取、Session、Cookie 等狀態存儲？

4. **併發與時序影響**
   - 修改是否影響併發處理邏輯？
   - 是否可能產生競態條件？

輸出格式：
```
### 3. 既有流程影響評估

**受影響流程**:
| 流程 | 影響程度 | 說明 | 是否已處理 |
|------|----------|------|------------|
| ... | ... | ... | [是/否/不適用] |

**呼叫鏈風險**: [描述或「無額外風險」]
```

### 階段 4：潛在異常與副作用

識別修改可能引發的非預期問題：

| 檢查面向 | 說明 |
|----------|------|
| 效能影響 | 新增查詢、迴圈、I/O 是否影響效能？ |
| 安全性 | 是否引入新的攻擊面？是否遵循最小權限原則？ |
| 可觀測性 | 修改後的行為是否可透過日誌/監控偵測異常？ |
| 測試覆蓋 | 修改是否有對應的測試？既有測試是否需要更新？ |
| 部署風險 | 是否需要特殊的部署順序或停機維護？ |
| 文件同步 | API 文件、使用者文件是否需要同步更新？ |

輸出格式：
```
### 4. 潛在異常與副作用

| 面向 | 風險等級 | 說明 | 建議 |
|------|----------|------|------|
| ... | [無/低/中/高] | ... | ... |
```

### 階段 5：綜合評估與建議

```
### 5. 綜合評估

**整體評級**: [通過 / 有條件通過 / 需修改 / 不建議執行]

**關鍵發現**:
1. ...
2. ...

**建議行動**:
| 優先級 | 行動 | 理由 |
|--------|------|------|
| P0 (阻擋) | ... | ... |
| P1 (重要) | ... | ... |
| P2 (建議) | ... | ... |

**結論**: [一段話總結]
```

### 階段 6：回饋與補充

分析完成後，詢問使用者：

> 以上分析中有發現一些原始文件未涵蓋的項目。是否要將這些新發現補充到原始計畫/報告中？

若使用者同意：
1. 讀取原始文件
2. 將新發現以適當格式附加或整合到文件中（保留原始內容，以「補充分析」區塊新增）
   若產出獨立的補充分析文件（而非附加到原始文件），檔名套用 `YYYYMMDDhh-NN-標題.md` 格式。
3. 確認修改後的內容

---

## 關聯 Skill 引用

分析過程中，根據發現的問題類型，主動建議使用者搭配專業 Skill 做深入分析：

| 觸發條件 | 建議 Skill | 引用時機 |
|----------|------------|----------|
| 文件為規格提案且結構不完整 | `/spec-driven-dev` | 階段 1 — 建議先通過結構驗證再做影響分析 |
| 需求描述模糊或缺少驗收標準 | `/requirement-assistant` | 階段 1 — 需求品質不足時引導改善 |
| 階段 4 識別安全風險為「中」或「高」 | `/security-scan` | 階段 4 — 建議深入安全審查 |
| 修改涉及重構或技術債清理 | `/refactoring-assistant` | 階段 2/3 — 建議評估重構策略 |
| 階段 4 識別測試覆蓋不足 | `/test-coverage-assistant` | 階段 4 — 建議評估測試完整性 |
| 修改已實作完成、準備提交 | `/code-review-assistant` | 階段 5 — 建議進入程式碼審查 |

引用格式（嵌入在對應階段的輸出中）：
```
> **建議**：本分析識別到 [問題類型]，建議使用 `/skill-name` 進行深入評估。
```

---

## 評級標準

### 整體評級判定

| 評級 | 條件 |
|------|------|
| **通過** | 所有面向均為「充分/完整」，無 P0/P1 項目 |
| **有條件通過** | 存在 P1 項目但無 P0，可在補充後執行 |
| **需修改** | 存在 P0 項目或多個 P1，需重新修訂方案 |
| **不建議執行** | 存在根本性設計缺陷或嚴重安全風險 |

### 風險等級定義

| 等級 | 定義 |
|------|------|
| **高** | 可能導致資料遺失、安全漏洞或服務中斷 |
| **中** | 可能導致功能異常或效能下降，但有緩解途徑 |
| **低** | 影響有限，可在後續迭代中處理 |
| **無** | 無可識別的風險 |

---

## 注意事項

- 若無法讀取文件提及的原始碼，在評估中標註 `[未驗證：無法存取原始碼]`，基於文件描述做推斷並明確標示推斷依據
- 若文件引用其他報告，提示使用者是否提供關聯文件以提升分析精度
- 分析應保持客觀，避免因文件寫作品質良好就放鬆技術審查標準
- 每個結論必須有對應的證據或推理鏈，不做無依據的斷言