brainstorminglisted

# 把點子腦力激盪成設計 透過自然的協作對話，幫助把點子變成完整的設計與規格。 先理解目前的專案上下文，然後一次一個問題地提問，逐步精煉點子。一旦你了解要建構什麼，就呈現設計並取得使用者核准。 <HARD-GATE> 在你呈現設計且使用者核准之前，不要呼叫任何實作技能、撰寫任何程式碼、搭建任何專案、或採取任何實作行動。這適用於每個專案，無論它看似多麼簡單。 </HARD-GATE> ## 反模式：「這太簡單了，不需要設計」 每個專案都要走過這個流程。待辦清單、單一函式的工具、設定變更——全部都是。「簡單」的專案正是未經檢視的假設造成最多浪費工作的地方。設計可以很短（對真正簡單的專案而言，幾句話就夠），但你必須呈現它並取得核准。 ## 檢查清單 你必須為以下每一項建立一個任務，並依序完成它們： 1. **探索專案上下文** ——檢查檔案、文件、最近的 commits 2. **在適當時機提供視覺夥伴** ——不是在一開始。當某個問題確實「展示」會比「描述」更清楚時（首次出現時），在那時提供它（獨立一則訊息）；核准後它的瀏覽器分頁會為你開啟。若從未出現視覺問題，就永遠不要提供它。見下方「視覺夥伴」一節。 3. **提出釐清問題** ——一次一個，理解目的／約束／成功準則 4. **提出 2-3 種做法** ——附上取捨與你的建議 5. **呈現設計** ——以配合其複雜度的段落呈現，每個段落後取得使用者核准 6. **撰寫設計文件** ——儲存到 `docs/superpowers/specs/YYYY-MM-DD-<topic>-design.md` 並 commit 7. **規格自我審查** ——快速就地檢查佔位符、矛盾、歧義、範圍（見下方） 8. **使用者審查書面規格** ——繼續前請使用者審查規格檔案 9. **轉入實作** ——呼叫 writing-plans 技能以建立實作計畫 ## 流程圖 ```dot digraph brainstorming { "Explore project context" [shape=box]; "Ask clarifying questions" [shape=box]; "Propose 2-3 approaches" [shape=box]; "Present design sections" [shape=box]; "User approves design?" [shape=diamond]; "Write design doc" [shape=box]; "Spec self-review\n(fix inline)" [shape=box]; "User reviews spec?" [shape=diamond]; "Invoke writing-plans skill" [shape=doublecircle]; "Explore project context" -> "Ask clarifying questions"; "Ask clarifying questions" -> "Propose 2-3 approaches"; "Propose 2-3 approaches" -> "Present design sections"; "Present design sections" -> "User approves design?";