design-brainstorm

name	design-brainstorm
description	蘇格拉底式設計對話，透過逐步提問把模糊想法精煉為可實作的設計。當提到「腦力激盪」「brainstorm」「我有個想法」「幫我想想」「設計討論」「這方向可行嗎」時自動啟用。
allowed-tools	Read, Grep, Glob, Bash, Write

Design Brainstorm — 蘇格拉底式設計對話

借鑑 obra/superpowers 的 brainstorming 概念；提問紀律借鑑 mattpocock/skills 的 grilling。

硬閘門

設計未批准前，不寫任何程式碼 — 不呼叫實作技能、不建專案骨架，直到設計呈現且使用者批准。 啟動時調用 EnterPlanMode，設計完成後 ExitPlanMode 讓使用者審閱。

工作流程

1. 探索專案脈絡

讀 CLAUDE.md、README.md、相關目錄結構與最近 git 提交，識別既有模式與技術棧， 確保設計建議符合專案現況。

2. 提問釐清

一次只問一個問題，偏好多選題，每題都要推進理解。 提問順序：目標 → 使用者 → 限制 → MVP 範圍。

事實自己查，決策才問人：

• 能從環境查到的「事實」自己查（filesystem、程式碼、git、設定檔）
• 「決策」才逐一放到使用者面前，且每題附上自己的建議答案
• 判斷基準：有標準答案 → 事實，去查；取決於偏好/取捨 → 決策，去問

3. 範圍評估

小型（<1 天）直接設計；中型（1–3 天）分階段；大型（>3 天）先拆成獨立子專案， 各自 brainstorm。

4. 提出 2–3 個方案

每案含：核心思路一句話、優缺點、技術選擇、預估複雜度、適合場景。

YAGNI：每案都是最小可行方案。「以後可能需要」的功能 → 移除， 只確保設計之後容易加入。質疑每個非必要功能：「沒有這個會怎樣？」

5. 分段呈現設計

依序呈現並逐段確認：資料模型 → API 設計 → 核心邏輯 → UI/UX 流程（如適用）→ 錯誤處理。 每段問「這部分同意嗎？要調整什麼？」

若涉及 UI/架構圖，以獨立訊息提議產出視覺輔助（Mermaid 圖 / UI mockup），同意後再做。

6. 寫設計文件

寫入 docs/designs/YYYY-MM-DD-<topic>-design.md，結構：問題描述、設計決策（含理由）、 技術設計（資料模型 / API / 核心邏輯）、範圍排除（明確不做的事）、開放問題。

7. 自我審查

檢查：無佔位符或 TODO、無內部矛盾、無模糊描述、技術選擇皆有理由、範圍排除清楚、 無 YAGNI 功能。

8. 使用者審查 → 下一步

依回饋修改至批准。批准後的下一步：交 task-planner 拆微任務，或直接進 8 步開發迴圈實作。批准前後都不跳過迴圈的測試與 review 步驟。

常見錯誤

錯誤	正確做法
設計前就開始寫程式碼	堅守硬閘門
一次問太多問題	一次一個，多選優先
把查得到的事實拿去問使用者	事實自己查，只問決策並附建議答案
假設使用者的技術偏好	提供選項讓使用者選
設計過度	YAGNI — 只做需要的
跳過範圍評估	大專案必先拆分
設計文件有佔位符	自我審查消除所有 TODO