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

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

硬閘門

設計審查通過前，不寫任何程式碼 — 不呼叫實作技能、不建專案骨架，直到設計呈現並經 plan-review 審過。 plan-review 第 3 輪或確認輪仍不通過、或確認輪沒跑成，使用者選照改好的計畫繼續，或第 1–3 輪沒跑成、使用者選「不審直接交」，也算過了這一關 —— 接著一樣送 ExitPlanMode， 第 6 步在設計文件的開放問題寫明 plan-review 第 3 步標「未經審查」的改法（第 3 輪與確認輪的重大缺失，含「需要外部查證」裡重大的；小事；因使用者答案改的地方）、之後因 ExitPlanMode 被拒的回饋改的地方，與每條重大的現況（照 plan-review 回報的原樣，含確認輪的註記；寫進前照 plan-review 那條重判，之後改過的拿掉註記；確認輪跑了但沒跑成也寫明），或「沒經過 plan-review」。之後 ExitPlanMode 被拒、改到內容時，選過「不審直接交」或已到第 3 輪（含確認輪）就不再送審（見下方被拒那條）。 還沒送 ExitPlanMode 時使用者在 plan-review 選停下：不送 ExitPlanMode、不寫設計文件，留在 plan mode，把改好的設計與每條重大的現況交給使用者，結束本 skill。 啟動時調用 EnterPlanMode。順序：第 5 步逐段確認 → plan-review 審整份設計 → ExitPlanMode → 第 6 步寫設計文件 —— plan mode 由 harness 擋住所有寫入，還在 plan mode 裡就跑第 6 步的 Write，那次寫檔會被擋下來。 ExitPlanMode 是 harness 的批准，拿不掉，使用者按一次。

• plan mode 裡照樣派 general-purpose 的裁決者：plan mode 的系統提示會說規劃階段只用 Explore subagent， 那是文字指示、不擋（2026-10-24 用 claude -p --permission-mode plan 實測巢狀派工成功），而 Explore 不能再派審查者
• ExitPlanMode 被拒 → 留在 plan mode 照回饋改；改到設計內容就接續原本的輪次回 plan-review 再送一輪； 已經是第 3 輪（含確認輪）、或先前選了「不審直接交」就不再送，把「因為你的回饋改了哪裡」列給使用者後再送 ExitPlanMode。只改措辭就直接再送 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 步的結構組好（含設計決策理由、範圍排除、開放問題、預估 N 個功能段落）， 一字不改交 plan-review（順序見硬閘門）；第 6 步寫進檔的就是審過的這份（第 3 輪之後的改法照硬閘門那條標明未經審查）。 這裡的「同意嗎」是設計對話裡的決策題，不是最終批准，保留；但使用者只回「同意」的段落不標成「使用者決定」， 只有使用者自己選的選項或自己提的修改才標 —— 不然整份設計都會被當成使用者決定而免審。

6. 寫設計文件

寫入 docs/designs/YYYY-MM-DD-<topic>-design.md，結構：問題描述、設計決策（含理由）、 技術設計（資料模型 / API / 核心邏輯）、範圍排除（明確不做的事）、開放問題、預估 N 個功能段落。 plan-review 通過那條路上，最終計畫標了未經審查的改法或「沒改」的重大時，一樣寫進開放問題。

7. 自我審查

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

8. 下一步

設計已經在 plan-review 與 ExitPlanMode 過了關，寫好、自我審查完就接下一步，不再等使用者批准。 第 7 步只修形式（佔位、措辭）；查到要改設計內容時，照實告訴使用者改了哪裡，接續輪次回 plan-review 再送一輪，照採納的意見改檔； 已經是第 3 輪（含確認輪）、或先前使用者選了「不審直接交」，就不再送，改了哪裡照實列給使用者，也補進開放問題的未經審查清單。這時已經離開 plan mode， 這一輪沒通過或沒跑成就照 plan-review 第 3、5 步問使用者，不再送 ExitPlanMode；這時選停下，就把這一輪改的地方與每條重大的現況（照 plan-review 回報的原樣）補進開放問題的未經審查清單、列給使用者， 結束本 skill（不交 task-planner、不開工）。 要跨好幾輪迴圈才做得完的，交 task-planner 拆成功能段落（進度表寫回這份設計文件；它會對段落草稿再跑一次 plan-review，輪次從頭算）； 一輪做得完的，直接進 8 步開發迴圈實作，走過 plan-review 的設計（含使用者選「不審直接交」）就是計畫，不再另審。都不跳過迴圈的測試與 review 步驟。

常見錯誤