| 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：文件識別與上下文建立
-
若文件包含 YAML frontmatter 且有 type 欄位，直接採用作為文件類型，跳到步驟 2；若無，繼續步驟 1 從內容推斷。
-
讀取目標文件，識別文件類型：
- 技術債評估 / 資安報告
- 功能變更提案 / RFC
- 修復方案 / Hotfix 計畫
- 架構決策紀錄 (ADR)
- 測試計畫 / 部署計畫
- 其他（標註類型）
-
識別文件涉及的專案與檔案：
- 若文件提及具體檔案路徑，嘗試讀取以獲得完整上下文
- 若文件關聯其他報告（如 REPORT-008 → REPORT-009），提示使用者是否需要一併分析
階段 1：分析評估完善度
評估文件本身的分析品質：
| 檢查項 | 說明 |
|---|
| 問題定義 | 問題是否清楚定義？是否有重現條件或觸發場景？ |
| 範圍界定 | 影響範圍是否明確？是否遺漏相關模組或檔案？ |
| 根因分析 | 是否追溯到根本原因，而非僅描述症狀？ |
| 證據支撐 | 結論是否有程式碼片段、日誌、數據佐證？ |
| 風險量化 | 風險等級是否有明確的判定標準？是否過度樂觀或悲觀？ |
| 邊界案例 | 是否考慮了邊界條件、異常輸入、併發場景？ |
| 遺漏檢測 | 是否存在「應該分析但未提及」的面向？ |
輸出格式：
### 1. 分析評估完善度
| 項目 | 評級 | 說明 |
|------|------|------|
| 問題定義 | [充分/部分/不足] | ... |
| ... | ... | ... |
**遺漏項**: [列出未涵蓋但應考慮的面向]
階段 2：功能設計完整性
評估提案的修改或設計是否完整：
| 檢查項 | 說明 |
|---|
| 修改範圍 | 所有需要修改的位置是否都已列出？ |
| 向下相容 | 修改是否保持 API / 資料格式的向下相容？ |
| 資料遷移 | 是否需要資料庫遷移？遷移方案是否完整？ |
| 配置變更 | 是否需要修改配置檔、環境變數或部署設定？ |
| 依賴影響 | 是否影響上下游模組或第三方整合？ |
| 錯誤處理 | 異常情境的處理是否完善？ |
| 回滾方案 | 若修改失敗，是否有回滾策略？ |
輸出格式：
### 2. 功能設計完整性
| 項目 | 評級 | 說明 |
|------|------|------|
| 修改範圍 | [完整/部分/不足] | ... |
| ... | ... | ... |
**缺失項**: [列出設計中未涵蓋的必要元素]
階段 3：既有流程影響評估
分析修改是否破壞現有功能：
-
識別受影響的業務流程
- 列出修改涉及的所有業務流程（如：結帳流程、訂單建立、付款確認）
- 每個流程標註：[無影響 / 低影響 / 中影響 / 高影響]
-
呼叫鏈追蹤
- 若可讀取原始碼，追蹤修改函式的呼叫者與被呼叫者
- 識別是否有隱含的耦合關係
-
狀態與資料流分析
- 修改是否改變了資料的格式、類型或流向？
- 是否影響快取、Session、Cookie 等狀態存儲？
-
併發與時序影響
- 修改是否影響併發處理邏輯？
- 是否可能產生競態條件？
輸出格式：
### 3. 既有流程影響評估
**受影響流程**:
| 流程 | 影響程度 | 說明 | 是否已處理 |
|------|----------|------|------------|
| ... | ... | ... | [是/否/不適用] |
**呼叫鏈風險**: [描述或「無額外風險」]
階段 4：潛在異常與副作用
識別修改可能引發的非預期問題：
| 檢查面向 | 說明 |
|---|
| 效能影響 | 新增查詢、迴圈、I/O 是否影響效能？ |
| 安全性 | 是否引入新的攻擊面？是否遵循最小權限原則？ |
| 可觀測性 | 修改後的行為是否可透過日誌/監控偵測異常？ |
| 測試覆蓋 | 修改是否有對應的測試？既有測試是否需要更新？ |
| 部署風險 | 是否需要特殊的部署順序或停機維護？ |
| 文件同步 | API 文件、使用者文件是否需要同步更新？ |
輸出格式：
### 4. 潛在異常與副作用
| 面向 | 風險等級 | 說明 | 建議 |
|------|----------|------|------|
| ... | [無/低/中/高] | ... | ... |
階段 5：綜合評估與建議
### 5. 綜合評估
**整體評級**: [通過 / 有條件通過 / 需修改 / 不建議執行]
**關鍵發現**:
1. ...
2. ...
**建議行動**:
| 優先級 | 行動 | 理由 |
|--------|------|------|
| P0 (阻擋) | ... | ... |
| P1 (重要) | ... | ... |
| P2 (建議) | ... | ... |
**結論**: [一段話總結]
階段 6：回饋與補充
分析完成後，詢問使用者：
以上分析中有發現一些原始文件未涵蓋的項目。是否要將這些新發現補充到原始計畫/報告中？
若使用者同意：
- 讀取原始文件
- 將新發現以適當格式附加或整合到文件中（保留原始內容，以「補充分析」區塊新增）
若產出獨立的補充分析文件（而非附加到原始文件），檔名套用
YYYYMMDDhh-NN-標題.md 格式。
- 確認修改後的內容
關聯 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，需重新修訂方案 |
| 不建議執行 | 存在根本性設計缺陷或嚴重安全風險 |
風險等級定義
| 等級 | 定義 |
|---|
| 高 | 可能導致資料遺失、安全漏洞或服務中斷 |
| 中 | 可能導致功能異常或效能下降，但有緩解途徑 |
| 低 | 影響有限，可在後續迭代中處理 |
| 無 | 無可識別的風險 |
注意事項
- 若無法讀取文件提及的原始碼，在評估中標註
[未驗證：無法存取原始碼]，基於文件描述做推斷並明確標示推斷依據
- 若文件引用其他報告，提示使用者是否提供關聯文件以提升分析精度
- 分析應保持客觀，避免因文件寫作品質良好就放鬆技術審查標準
- 每個結論必須有對應的證據或推理鏈，不做無依據的斷言
