brainstorming

將點子腦力激盪成設計

透過自然的協作對話，協助將點子轉化為完整的設計與規格。

首先了解當前專案背景，然後一次問一個問題來逐步釐清點子。一旦你了解要建構什麼，就呈現設計並取得使用者核准。

<HARD-GATE>
在呈現設計並獲得使用者核准之前，不得呼叫任何實作技能、撰寫任何程式碼、建立任何專案或採取任何實作行動。這適用於每個專案，無論你認為多簡單。
</HARD-GATE>

反模式：「這太簡單了，不需要設計」

每個專案都必須經過這個流程。待辦清單、單一功能的工具程式、設定變更——全部都要。所謂「簡單」的專案，正是未經檢驗的假設造成最多浪費的地方。設計可以很短（對真正簡單的專案來說，幾句話即可），但你必須呈現設計並獲得核准。

檢查清單

你必須為以下每個項目建立任務，並依序完成：

1. 探索專案背景 — 檢查檔案、文件、最近的提交
2. 提供視覺輔助（如果主題會涉及視覺問題）— 這必須是獨立訊息，不要與釐清問題合併。請參閱下方的「視覺輔助」章節。
3. 提出釐清問題 — 一次一個，了解目的、限制、成功標準
4. 提出 2-3 種方法 — 附帶取捨與你的建議
5. 呈現設計 — 各章節的篇幅依複雜度調整，每個章節後取得使用者核准
6. 撰寫設計文件 — 儲存至 docs/superpowers/specs/YYYY-MM-DD-<topic>-design.md 並提交
7. 規格自我審查 — 快速內聯檢查是否有佔位符、矛盾、模糊不清、範圍問題（見下方）
8. 使用者審查書面規格 — 請使用者審查規格檔案後再繼續
9. 轉換到實作 — 呼叫 writing-plans 技能來建立實作計畫

流程圖

digraph brainstorming {
    "探索專案背景" [shape=box];
    "前方有視覺問題？" [shape=diamond];
    "提供視覺輔助\n(獨立訊息，不含其他內容)" [shape=box];
    "提出釐清問題" [shape=box];
    "提出 2-3 種方法" [shape=box];
    "呈現設計章節" [shape=box];
    "使用者核准設計？" [shape=diamond];
    "撰寫設計文件" [shape=box];
    "規格自我審查\n(內聯修正)" [shape=box];
    "使用者審查規格？" [shape=diamond];
    "呼叫 writing-plans 技能" [shape=doublecircle];

    "探索專案背景" -> "前方有視覺問題？";
    "前方有視覺問題？" -> "提供視覺輔助\n(獨立訊息，不含其他內容)" [label="是"];
    "前方有視覺問題？" -> "提出釐清問題" [label="否"];
    "提供視覺輔助\n(獨立訊息，不含其他內容)" -> "提出釐清問題";
    "提出釐清問題" -> "提出 2-3 種方法";
    "提出 2-3 種方法" -> "呈現設計章節";
    "呈現設計章節" -> "使用者核准設計？";
    "使用者核准設計？" -> "呈現設計章節" [label="否，修改"];
    "使用者核准設計？" -> "撰寫設計文件" [label="是"];
    "撰寫設計文件" -> "規格自我審查\n(內聯修正)";
    "規格自我審查\n(內聯修正)" -> "使用者審查規格？";
    "使用者審查規格？" -> "撰寫設計文件" [label="要求修改"];
    "使用者審查規格？" -> "呼叫 writing-plans 技能" [label="核准"];
}

最終狀態是呼叫 writing-plans。 請勿呼叫 frontend-design、mcp-builder 或任何其他實作技能。腦力激盪後唯一能呼叫的技能是 writing-plans。

流程

了解點子：

• 先查看當前專案狀態（檔案、文件、最近的提交）
• 在提出詳細問題之前，評估範圍：如果請求描述多個獨立子系統（例如「建立一個包含聊天、檔案儲存、計費和分析的平台」），請立即標記。不要花問題來釐清一個需要先拆解的專案細節。
• 如果專案太大無法用單一規格涵蓋，協助使用者拆解成子專案：哪些是獨立的部分？它們如何關聯？應該以什麼順序建構？然後透過正常的設計流程對第一個子專案進行腦力激盪。每個子專案都有自己的規格 → 計畫 → 實作循環。
• 對於範圍適當的專案，一次問一個問題來逐步釐清點子
• 盡可能偏好選擇題，但開放式問題也可以
• 每則訊息只問一個問題——如果某個主題需要更多探索，將其拆成多個問題
• 專注於了解：目的、限制、成功標準

探索方法：

• 提出 2-3 種不同的方法，附帶取捨
• 以對話方式呈現選項，附上你的建議與理由
• 先提出你建議的選項，並解釋原因

呈現設計：

• 一旦你認為了解要建構的內容，就呈現設計
• 每個章節的篇幅依複雜度調整：簡單的話幾句話，複雜的話最多 200-300 字
• 每個章節後詢問是否正確
• 涵蓋：架構、元件、資料流程、錯誤處理、測試
• 準備好在某個部分不合理時回頭釐清

為隔離與清晰而設計：

• 將系統拆分成較小的單元，每個單元有單一明確目的，透過定義良好的介面溝通，且能獨立理解與測試
• 對於每個單元，你應該能回答：它做什麼？如何使用？它依賴什麼？
• 有人能在不閱讀內部實作的情況下理解一個單元的功能嗎？你能在不破壞使用者的情況下更改內部實作嗎？如果不能，邊界需要調整。
• 較小、邊界明確的單元也更容易讓你處理——你對能一次掌握在上下文中的程式碼推理得更好，而且當檔案專注時，你的編輯更可靠。當檔案變大時，通常表示它做得太多。

在現有程式碼庫中工作：

• 在提出變更之前，先探索現有結構。遵循現有模式。
• 如果現有程式碼有影響工作的問題（例如檔案太大、邊界不明確、責任糾纏），將有針對性的改進納入設計——就像優秀開發者改善他們正在處理的程式碼一樣。
• 不要提出不相關的重構。專注於服務當前目標。

設計之後

文件化：

• 將驗證過的設計（規格）寫入 docs/superpowers/specs/YYYY-MM-DD-<topic>-design.md
  • （使用者對規格位置的偏好會覆蓋此預設值）
• 如果可用，使用 elements-of-style:writing-clearly-and-concisely 技能
• 將設計文件提交到 git

規格自我審查：
撰寫規格文件後，以全新眼光檢視：

1. 佔位符掃描： 是否有任何「待決定」、「待辦事項」、不完整的章節或模糊的需求？修正它們。
2. 內部一致性： 是否有章節互相矛盾？架構是否符合功能描述？
3. 範圍檢查： 這是否足夠專注於單一實作計畫，還是需要拆解？
4. 模糊性檢查： 是否有任何需求可以被解釋成兩種不同方式？如果是，選擇一種並明確說明。

內聯修正任何問題。無需重新審查——只需修正並繼續。

使用者審查關卡：
在規格審查循環通過後，請使用者審查書面規格後再繼續：

「規格已撰寫並提交至 <path>。請審查，並讓我知道在我們開始撰寫實作計畫之前是否需要任何修改。」

等待使用者回應。如果他們要求修改，進行修改並重新執行規格審查循環。只有在使用者核准後才能繼續。

實作：

• 呼叫 writing-plans 技能來建立詳細的實作計畫
• 請勿呼叫任何其他技能。writing-plans 是下一步。

關鍵原則

• 一次一個問題 — 不要用多個問題讓使用者不知所措
• 偏好選擇題 — 在可能的情況下，比開放式問題更容易回答
• 嚴格遵循 YAGNI — 從所有設計中移除不必要的功能
• 探索替代方案 — 在確定之前，總是提出 2-3 種方法
• 漸進式驗證 — 呈現設計，在繼續前取得核准
• 保持彈性 — 當某個部分不合理時，回頭釐清

視覺輔助

一個基於瀏覽器的輔助工具，用於在腦力激盪期間展示模型、圖表和視覺選項。作為工具提供——而非模式。接受輔助表示它可用於需要視覺處理的問題；這不表示每個問題都透過瀏覽器進行。

提供輔助： 當你預期接下來的問題會涉及視覺內容（模型、版面、圖表）時，提供一次以取得同意：

「我們正在處理的某些部分，如果我能透過網頁瀏覽器展示給您看，可能會更容易解釋。我可以隨著進度製作模型、圖表、比較和其他視覺內容。這項功能仍在開發中，且可能消耗較多 token。想試試看嗎？（需要開啟本機 URL）」

此提供必須是獨立訊息。 不要將其與釐清問題、背景摘要或任何其他內容合併。訊息中應只包含上述提供內容，沒有其他內容。等待使用者回應後再繼續。如果他們拒絕，則以純文字方式進行腦力激盪。

每個問題的決定： 即使使用者接受，也要針對每個問題決定使用瀏覽器還是終端機。判斷標準：使用者透過觀看是否比閱讀更能理解這個問題？

• 使用瀏覽器處理視覺性內容——模型、線框圖、版面比較、架構圖、並排視覺設計
• 使用終端機處理文字性內容——需求問題、概念選擇、取捨清單、A/B/C/D 文字選項、範圍決定

關於 UI 主題的問題不自動等於視覺問題。「在這個情境下，『個性』是什麼意思？」是概念性問題——使用終端機。「哪個精靈版面比較好？」是視覺問題——使用瀏覽器。

如果他們同意使用輔助，請在繼續前閱讀詳細指南：
skills/brainstorming/visual-companion.md