custom-skills-plan-analyze

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，需重新修訂方案
不建議執行	存在根本性設計缺陷或嚴重安全風險

風險等級定義

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

---

注意事項

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