think

think skill 概覽

think skill 的用途

think 是一個決策支援 skill，專門把模糊的想法整理成清楚、可被核准的方案，之後才進入寫 code。它最適合用在功能設計、架構選擇、取捨分析，以及「這件事到底該不該做？」這類主要需要判斷、而不是直接實作的問題。

誰適合安裝

如果你經常需要在 repo-first 工作流程中協助做產品決策、技術方向判斷，或是有範圍的規劃，就很適合安裝 think skill。當需求一開始是「先規劃這個」、「最佳做法是什麼」、「這個要不要保留」這類帶有價值判斷的問題時，它特別有用。

它的不同之處

這個 skill 很有立場：它會推你做出具體建議，指出哪些證據會改變結論，並避免太早進入 code。當你需要的是一個可直接拿去決策的結果時，think for Decision Support 會比一般的腦力激盪 prompt 更強。

如何使用 think skill

安裝並觸發

用 npx skills add tw93/Waza --skill think 安裝。接著在任務屬於「選方向、定方向、驗證方向」而不是修已知缺陷時使用它。think install 這一步很簡單，但輸出品質取決於你有沒有提供真正的決策情境。

提供正確的輸入形式

好的 think usage prompt 應該包含目標、限制、受眾，以及實際上有哪些選擇還沒定案。例如：「我們需要為 SMB 管理員設計更快的 onboarding 流程；這個 sprint 只能改 UI，不能加 backend 工作，而且我們需要一份帶有取捨分析的建議。」

先讀對的檔案

先從 SKILL.md 開始，因為這個 repo 刻意做得很精簡，沒有 rules/、references/ 或 resources/ 資料夾。真正實用的指引都在 skill 本體裡：lightweight mode、evaluation mode，以及在核准前不要碰 implementation 的規則。

把工作流程當成決策漏斗

一個好的 think guide 流程是：先說明要做的決策、列出限制、要求最佳路徑，然後只有在必要時才補上風險與替代方案。如果你不確定要用 lightweight mode 還是 full mode，就描述問題是否已經被定義；這一點會大幅改變輸出結果。

think skill 常見問答

think 只適合新功能嗎？

不是。它也適合架構決策、產品價值判斷、有明確取捨的重構，以及「這件事值不值得做？」這類問題。對於簡單 bug 修正或小改動、而且答案已經很明顯的情況，它就不是最適合的選擇。

它和一般 prompt 有什麼不同？

一般 prompt 常常只會產出模糊的選項。think skill 的設計目標是逼出一個決策：明確的推薦路線、清楚的取捨，以及在核准前不進入 coding 的界線。當你需要一份可以交給隊友或利害關係人審閱的方案時，它會更好用。

think 適合新手嗎？

適合，只要使用者能用白話描述目標就可以。新手只要提供問題、限制和希望達成的結果，哪怕不熟技術名詞，也能得到最大的價值。

什麼情況下不該用 think？

當你已經知道怎麼修、只是需要執行時，就不要用它；或是任務很窄，直接修改比分析更快時，也不需要。若你其實沒有真正要做決策，只是想快速改寫內容，它帶來的價值也會比較有限。

如何改善 think skill

提供足以做決策的情境

最好的 think skill 輸入會包含現況、目標狀態、不可妥協的限制，以及成功長什麼樣子。例如：「我們需要把設定時間從 10 分鐘降到 2 分鐘、保留目前 backend、而且不能新增依賴」會比「改善 onboarding」產生更好的建議。

要求的是決策，不只是點子

如果你想讓 think usage 更有效，就不要只要靈感清單，而是要求一個帶理由的建議。好的問法是：「請在這些限制下選一個方案，並解釋它為什麼會勝出。」較弱的問法是：「給我一些點子。」

把你在意的取捨說清楚

告訴 skill 什麼最重要：速度、可維護性、成本、UX、風險，還是團隊產能。這能幫助 think for Decision Support 產出符合你優先順序的方案，而不是一份泛用的最佳實務答案。

用更精準的限制逐步收斂

如果第一次結果太寬泛，就用一個 follow-up 把範圍縮小：補上截止時間、禁止使用的 dependency、目標使用者，或必須保留的元件。讓隱含假設變成明確限制，再要求下一版方案，通常是最快改善輸出的方式。