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

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

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

## 硬閘門

**設計審查通過前，不寫任何程式碼** — 不呼叫實作技能、不建專案骨架，直到設計呈現並經 `plan-review` 審過。
啟動時調用 `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 步寫進檔的就是審過的這份。
這裡的「同意嗎」是設計對話裡的決策題，不是最終批准，保留；但使用者只回「同意」的段落不標成「使用者決定」，
只有使用者自己選的選項或自己提的修改才標 —— 不然整份設計都會被當成使用者決定而免審。

### 6. 寫設計文件

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

### 7. 自我審查

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

### 8. 下一步

設計已經在 `plan-review` 與 `ExitPlanMode` 過了關，寫好、自我審查完就接下一步，不再等使用者批准。
第 7 步只修形式（佔位、措辭）；查到要改設計內容時，照實告訴使用者改了哪裡，接續輪次回 `plan-review` 再送一輪。
要跨好幾輪迴圈才做得完的，交 `task-planner` 拆成功能段落（進度表寫回這份設計文件；它會對段落草稿再跑一次 `plan-review`，輪次從頭算）；
一輪做得完的，直接進 8 步開發迴圈實作，審過的設計就是計畫，不再另審。**都不跳過迴圈的測試與 review 步驟。**

## 常見錯誤

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