analyse-problem
作者 NeoLabHQanalyse-problem 是一個 A3 問題分析技能，能把雜亂的問題整理成一頁式簡報，內容涵蓋背景、現況、根因分析、對策、執行計畫與後續追蹤。當你在策略規劃、營運、產品或工程情境中，需要一個可直接拿來決策的問題定義時，它特別有用。
這個技能得分 76/100，代表它是 Agent Skills Finder 中一個不錯但不到頂級的項目。目錄使用者可以看到一個明確觸發的 A3 問題分析流程，結構也足夠完整，能比通用提示降低摸索成本；但它缺少支援檔案與更深入的導入指引，因此在安裝決策上仍有一些判斷空間。
- 可透過 `/analyse-problem [problem_description]` 明確觸發，並提供清楚的變數預設值
- 營運結構完整：Background、Current Condition、Goal、Root Cause Analysis、Countermeasures、Implementation Plan、Follow-up
- 技能內容量足夠，且沒有 placeholder 標記，顯示這不是空殼，而是有實際工作流程的內容
- 沒有支援檔、腳本或參考資料，因此使用者必須主要依賴 `SKILL.md` 本身
- 沒有安裝指令或 repo／檔案參照，較難判斷它是否已準備好與更廣泛的系統整合
analyse-problem 技能概覽
analyse-problem 是用來做什麼的
analyse-problem 技能會把雜亂的問題整理成一份結構化的 A3 問題簡報：背景、現況、目標狀態、根因分析、對策、執行計畫與後續追蹤。它特別適合策略規劃、營運、產品與工程場景，當你需要的不是腦力激盪，而是一份可以直接拿來做決策的問題陳述時，就很適合用它。
誰適合安裝
如果你經常需要把問題講清楚、對齊利害關係人，或是從症狀往根因推進，就值得安裝 analyse-problem。它很適合需要固定格式的人，例如事故檢討、流程改善、專案阻塞分析或規劃會議。
它的不同之處在哪裡
它的價值不在於「讓 AI 寫更多」，而在於「加上限制」。analyse-problem 會逼模型把問題濃縮在一頁內、區分事實與假設，並且最後一定要落到行動與驗證。這讓它比一般用在策略規劃的 analyse-problem 提示詞更實用，因為它強迫你把決策框架收緊。
如何使用 analyse-problem 技能
安裝並觸發 analyse-problem
先用你的 skills manager 走安裝流程，接著用一段簡短的問題陳述來呼叫 analyse-problem 技能。這個 repo 的使用模式是 /analyse-problem [problem_description]，而且這個技能預設支援可選的問題描述與 markdown 輸出。如果你的環境是用不同方式對應 skills，也請傳入同樣的意圖：簡潔、具體的問題描述。
給 analyse-problem 正確的輸入
好的輸入會清楚說明問題、範圍與證據。例如：“Customer onboarding completion dropped 18% this month in enterprise accounts; analyze causes and propose countermeasures.” 像 “improve onboarding” 這種弱輸入，會讓模型猜目標、負責人和成功指標。使用 analyse-problem 時，請包含：
- 症狀
- 受影響的流程或團隊
- 任何數據點、例子或時間線
- 期望結果或限制條件
先看這些 repository 部分
先從 SKILL.md 開始，再查看 README.md、AGENTS.md、metadata.json 中連結的說明，以及若存在的 rules/、resources/、references/ 或 scripts/ 等資料夾。對這個 repo 來說，主要內容集中在 plugins/kaizen/skills/analyse-problem，所以不需要花太多時間追其他零散設定。
調整提示詞，讓輸出更好
一個好的 analyse-problem 提示詞，應該要夠具體，能填滿 A3 的每個區塊。例如：
“Use analyse-problem to document why release delays increased in Q2. Include baseline metrics, likely root causes, 3 countermeasures ranked by impact and effort, and a 30-day follow-up plan.”
這樣產出的結果，會比單純要求泛泛的分析更有用，因為它提供了模型可以整理的事實，也明確指出它要支援哪個決策。
analyse-problem 技能 FAQ
analyse-problem 只適合策略規劃嗎？
不是。只要是需要把問題定義清楚、釐清原因並分配行動的情境，都很有用：產品問題、營運瓶頸、團隊流程失靈，或是策略規劃回顧都可以。A3 格式本身適用範圍很廣，但這個技能在輸出要拿去跟其他人共享時最有價值。
這跟一般提示詞有什麼不同？
一般提示詞也可以要求分析，但 analyse-problem 技能提供的是可重複使用的結構與輸出紀律。當你需要根因、對策與後續追蹤都一致覆蓋，而不是自由發揮的敘述時，這一點就很重要。
新手也能用得好嗎？
可以，只要輸入夠具體。新手通常卡在問題太模糊，所以請把你知道的資訊都給出來：觀察到的症狀、範圍、時間點，以及大致目標。這個技能能幫你整理不完整的想法，但它不能安全地憑空補出缺失的事實。
什麼情況下不該用它？
如果你只需要快速摘要、狀態更新，或是創意發想會議，就不適合用 analyse-problem。當問題的穩定範圍還沒定下來時，也不建議直接用；先把問題界定清楚，再要求結構化分析會更好。
如何改進 analyse-problem 技能
給它證據，不要只給結論
品質提升最大的關鍵，是提供具體輸入：數據、例子、事故時間戳、使用者引言，或流程備註。如果你已經懷疑某個根因，請把它標成假設，而不是事實，這樣分析才能去驗證它，而不是只是重複你的判斷。
要求能直接用來做決策的輸出
對 analyse-problem 來說，應該要求的是能幫團隊採取行動的內容：排序過的原因、對應根因的對策、負責人、相依關係，以及驗證計畫。如果你想要的是策略規劃價值，就請它寫出影響與成本的取捨，而不是長篇敘述。
留意常見失敗模式
最常見的失誤，是把症狀講太多，卻沒有把目標狀態說清楚。另一種是把多個問題塞進同一頁。請把互不相關的議題拆開，讓一次分析只聚焦一個決策、一位負責人，以及一個可量化的結果。
在第一版之後再迭代
先用第一版輸出檢查是否有缺口：缺資料、因果鏈薄弱，或行動與根因不對應。接著再用新事實與限制條件修正提示詞，例如預算、截止日、團隊容量，或主管審閱所需的格式。