analyse

analyse 技能概覽

analyse 的用途

analyse 技能是用來做 Kaizen 風格分析的自動選擇器。它會幫你為目標挑對觀察角度：如果要看程式碼的實際狀況，用 Gemba Walk；如果要檢視流程，用 Value Stream Mapping；如果要找浪費與低效率，用 Muda。當你需要更快檢視一個系統、又不想先猜該用哪種方法時，analyse 技能就是很合適的選擇。

最適合使用 analyse 的情境

當你手上有一段 codebase、某個流程，或一段對低效率的描述，想要的是有結構的調查，而不是一句模糊的「幫我看一下」時，就適合用 analyse。它特別適合 Skill Authoring、repo 稽核、架構審查，以及 workflow 瓶頸分析。

為什麼要安裝 analyse

analyse 的核心價值在於方法選擇。它不會把同一種分析方式硬套到所有問題上，而是把你的目標對應到更合適的技術，從而減少一開始就走錯方向的機率，也能提升第一輪分析的品質。

如何使用 analyse 技能

安裝與入口

使用 npx skills add NeoLabHQ/context-engineering-kit --skill analyse 安裝這個技能。主要入口是 /analyse [target_description]，其中 target 可以是功能、流程、子系統，或問題區域。

如何為 analyse 組織輸入

請同時提供一個具體目標，以及你在意的問題類型。較好的寫法是：/analyse deployment workflow for slow approvals and failed rollbacks。較弱的寫法是：/analyse my project。當技能能夠判斷你需要的是程式碼探索、流程對照，還是浪費分析時，效果最好。

先閱讀這些檔案

先從 SKILL.md 開始，再查看任何可能影響行為的 repo 層級指引，尤其是 README.md、AGENTS.md，以及如果存在的話 metadata.json。在這個 repo 裡，最主要、最實用的來源就是 SKILL.md；沒有額外的 helper scripts 或支援資料夾可以進一步補強流程。

實用使用技巧

如果你已經知道想用哪種方法，可以用 METHOD 值像是 gemba、vsm 或 muda 來覆寫自動選擇。當目標本身有點模糊、但你的目的很明確時，這樣做特別有用。想要更好的結果，請描述分析對象、你要的產出，以及你最在意的限制條件。

analyse 技能 FAQ

analyse 只適用於程式碼嗎？

不是。analyse 可以處理程式碼實作、工作流程，以及浪費分析。真正的判斷重點是目標類型，以及你想學到什麼，而不是輸入看起來像 repo 還是像流程。

什麼時候不該用 analyse？

當你已經有一個很明確、很狹窄的任務，不需要再選方法時，就不必用它；或者當 prompt 模糊到技能無法分辨是程式碼實況還是流程問題時，也不適合。這些情況下，應先補足上下文，或改用更具體的技能。

analyse 和一般 prompt 有什麼不同？

一般 prompt 通常會直接假設一種分析方式；analyse 技能則會先選出最適合的 Kaizen 方法。當你想要一個有結構的起手式、並減少走進死胡同的假設時，這就特別有幫助。

analyse 適合新手嗎？

適合，只要使用者能用白話描述目標就可以。新手如果能提供明確區域和具體問題，像是 workflow 哪裡變慢了，或程式行為和文件哪裡不一致，通常最能拿到價值。

如何改進 analyse 技能

提供更強的目標

提升品質最大的方式，就是明確點出被分析的精確對象，以及你在意的失敗模式。例如，「分析 auth flow，找出文件與實作不一致的地方」會比「分析 auth」得到更好的指引。

指明你要的結果

告訴 analyse 你需要的是 code walkthrough、process map，還是浪費辨識。即使技能會自動選方法，清楚的結果仍能幫助它用更少的歧義來選擇並解釋方法。

使用限制條件與實例

加入一到兩個真實訊號：某個很慢的步驟、某個令人困惑的 function、重複發生的 handoff，或已知的低效率。這些細節能幫助 analyse 技能把焦點放在證據上，而不是大範圍亂搜。

第一次分析後再迭代

如果第一次分析太發散，就把 target 收窄，再用更具體的方法提示重新跑一次。對 analyse 技能來說，迭代式 prompt 通常比一次塞進超大需求更有效，因為它能保留方法選擇，同時把範圍收緊。