design-brainstorm · diff
git:20260723.f8d9161 to git:20260723.ee57bf2
39 added, 216 removed. Audit A to A.
---
name: design-brainstorm
- description: 蘇格拉底式設計對話，透過逐步提問精煉想法為可實作的設計。當提到「腦力激盪」「brainstorm」「我有個想法」「幫我想想」「設計討論」「explore ideas」時自動啟用。不適用於已有明確需求的正式開發流程（用 /dd-start）。
+ description: 蘇格拉底式設計對話，透過逐步提問把模糊想法精煉為可實作的設計。當提到「腦力激盪」「brainstorm」「我有個想法」「幫我想想」「設計討論」「這方向可行嗎」時自動啟用。
allowed-tools: Read, Grep, Glob, Bash, Write
---
# Design Brainstorm — 蘇格拉底式設計對話
- 借鑑 obra/superpowers 的 `brainstorming` 概念，適配 DD Pipeline 風格。
-
- ## 核心原則
-
- **設計未批准前，不得寫任何程式碼。**
-
- > 這是硬閘門。不要呼叫任何實作技能、不要寫程式碼、不要建立專案骨架，
- > 直到你呈現了設計方案並且使用者已批准。
-
- **啟動時調用 `EnterPlanMode`**，確保 Plan 模式的讀取限制生效。
- 設計完成後調用 `ExitPlanMode`，讓使用者審閱。
-
- ## 觸發條件
-
- **關鍵詞：**
- - 「腦力激盪」「brainstorm」「brain storm」
- - 「我有個想法」「我在想」「我想做」
- - 「幫我想想」「一起想」「討論一下」
- - 「設計討論」「explore ideas」
- - 「這個方向對嗎」「可行嗎」
-
- **場景觸發：**
- - 使用者有模糊的想法想要精煉
- - 新功能的初步探索
- - 技術方案尚未確定
- - 需要在多個方案間做選擇
-
- **與 `/dd-start` 的區別：**
-
- | 特性 | design-brainstorm | /dd-start (RDD) |
- |-----|------------------|-----------------|
- | **適用階段** | 想法探索、尚未成形 | 需求已初步明確 |
- | **互動風格** | 蘇格拉底對話、逐步引導 | 結構化需求分析 |
- | **產出** | 設計文件 + 進入 task-planner | 正式需求文件 + 進入 DD Pipeline |
- | **流程彈性** | 高（隨時調整方向） | 中（遵循 RDD 框架） |
-
- ## 9 步工作流程
-
- ### Step 1: 探索專案脈絡
+ 借鑑 obra/superpowers 的 `brainstorming` 概念；提問紀律借鑑 mattpocock/skills 的 `grilling`。
- 在開始對話前，先了解背景：
+ ## 硬閘門
- 1. 讀取 `CLAUDE.md`、`README.md`、`package.json` 等專案文件
- 2. 瀏覽相關目錄結構
- 3. 查看最近的 git 提交了解開發方向
- 4. 識別現有模式、慣例、和技術棧
+ **設計未批准前，不寫任何程式碼** — 不呼叫實作技能、不建專案骨架，直到設計呈現且使用者批准。
+ 啟動時調用 `EnterPlanMode`，設計完成後 `ExitPlanMode` 讓使用者審閱。
- **目的**：確保設計建議符合現有專案脈絡。
+ ## 工作流程
- ### Step 2: 提問釐清
+ ### 1. 探索專案脈絡
- **規則：一次只問一個問題。**
+ 讀 `CLAUDE.md`、`README.md`、相關目錄結構與最近 git 提交，識別既有模式與技術棧，
+ 確保設計建議符合專案現況。
- - 不要一次丟出問題清單（會壓倒使用者）
- - 偏好多選題而非開放式問題
- - 每個問題都應該推進理解
+ ### 2. 提問釐清
- **規則：事實自己查，決策才問人。**（借鑑 mattpocock/skills 的 `grilling`）
+ **一次只問一個問題**，偏好多選題，每題都要推進理解。
+ 提問順序：目標 → 使用者 → 限制 → MVP 範圍。
- - 能從環境查到的「事實」自己查（filesystem、程式碼、git、設定檔），不拿去問使用者
+ **事實自己查，決策才問人：**
+ - 能從環境查到的「事實」自己查（filesystem、程式碼、git、設定檔）
- 「決策」才逐一放到使用者面前，且每題附上自己的建議答案
- - 判斷基準：這題有標準答案嗎？有 → 事實，去查；取決於偏好/取捨 → 決策，去問
-
- **提問順序：**
- 1. **目標**：「你想解決什麼問題？」或「你希望達成什麼效果？」
- 2. **使用者**：「誰會使用這個功能？」
- 3. **限制**：「有什麼技術限制或時間壓力嗎？」
- 4. **範圍**：「MVP 需要包含哪些部分？」
-
- **範例（多選偏好）：**
- ```
- 你的主要目標是哪個？
- A) 提高使用者體驗
- B) 改善系統效能
- C) 減少技術債
- D) 新增商業功能
- ```
-
- ### Step 3: 範圍評估
-
- 在深入設計前，評估專案規模：
-
- - **小型**（< 1 天）：可以直接進入設計
- - **中型**（1-3 天）：需要分階段設計
- - **大型**（> 3 天）：**標記需要拆分為子專案**
-
- 如果是大型專案，先幫使用者拆分為獨立的子專案，每個子專案分別進行 brainstorm。
-
- ### Step 4: 提出 2-3 個方案
-
- 每個方案包含：
-
- ```markdown
- ## 方案 A: [名稱]
-
- **核心思路**：[一句話描述]
-
- **優點**：
- - ...
-
- **缺點**：
- - ...
-
- **技術選擇**：[框架/工具]
-
- **預估複雜度**：低/中/高
-
- **適合場景**：[什麼情況下選這個]
- ```
-
- **YAGNI 原則**：
- - 每個方案都應該是最小可行方案
- - 如果某個功能「以後可能需要」但現在不需要 → 移除
- - 質疑每一個非必要的功能：「沒有這個會怎樣？」
-
- ### Step 5: 分段呈現設計
-
- 不要一次呈現完整設計。分段呈現，每段確認：
-
- 1. **資料模型** → 確認
- 2. **API 設計** → 確認
- 3. **核心邏輯** → 確認
- 4. **UI/UX 流程**（如適用）→ 確認
- 5. **錯誤處理** → 確認
-
- 每段結束後詢問：「這部分你同意嗎？有什麼要調整的？」
-
- **視覺輔助**：若涉及 UI/架構圖，主動提議呼叫 `senior-architect`（Mermaid/PlantUML/依賴圖）或 `frontend-design`（UI mockup）產出視覺輔助。以獨立訊息詢問，使用者同意後再呼叫。
-
- ### Step 6: 寫設計文件
-
- 將批准的設計寫入文件：
-
- **檔案位置**：`docs/designs/YYYY-MM-DD-<topic>-design.md`
-
- **文件結構**：
- ```markdown
- # [功能名稱] 設計文件
-
- ## 問題描述
- [要解決的問題]
-
- ## 設計決策
- [選擇的方案及理由]
-
- ## 技術設計
- ### 資料模型
- ### API 設計
- ### 核心邏輯
-
- ## 範圍排除
- [明確不做的事情]
-
- ## 開放問題
- [尚未決定的事項]
- ```
-
- ### Step 7: 自我審查
-
- 寫完設計文件後，自我檢查：
+ - 判斷基準：有標準答案 → 事實，去查；取決於偏好/取捨 → 決策，去問
- - [ ] 沒有佔位符或 TODO
- - [ ] 沒有內部矛盾
- - [ ] 沒有模糊不清的描述
- - [ ] 所有技術選擇都有明確理由
- - [ ] 範圍排除清楚列出
- - [ ] 不包含 YAGNI 功能
+ ### 3. 範圍評估
- ### Step 8: 使用者審查
+ 小型（<1 天）直接設計；中型（1–3 天）分階段；大型（>3 天）先拆成獨立子專案，
+ 各自 brainstorm。
- 請使用者審查設計文件：
- - 「請閱讀設計文件，有什麼需要修改的嗎？」
- - 根據反饋修改，直到使用者批准
+ ### 4. 提出 2–3 個方案
- ### Step 9: 進入下一步
+ 每案含：核心思路一句話、優缺點、技術選擇、預估複雜度、適合場景。
- 設計批准後，**唯一合法的下一步**是：
+ **YAGNI**：每案都是最小可行方案。「以後可能需要」的功能 → 移除，
+ 只確保設計之後容易加入。質疑每個非必要功能：「沒有這個會怎樣？」
- 1. **進入 task-planner**：將設計拆分為微任務
- 2. **進入 /dd-start**：如果使用者想走正式 DD Pipeline
+ ### 5. 分段呈現設計
- **禁止直接開始寫程式碼。**
+ 依序呈現並逐段確認：資料模型 → API 設計 → 核心邏輯 → UI/UX 流程（如適用）→ 錯誤處理。
+ 每段問「這部分同意嗎？要調整什麼？」
- ---
+ 若涉及 UI/架構圖，以獨立訊息提議產出視覺輔助（Mermaid 圖 / UI mockup），同意後再做。
- ## 關鍵規則
+ ### 6. 寫設計文件
- ### 一次一個問題
- ```
- # 錯誤 ❌
- 你想用什麼框架？資料庫呢？需要認證嗎？API 風格偏好？
+ 寫入 `docs/designs/YYYY-MM-DD-<topic>-design.md`，結構：問題描述、設計決策（含理由）、
+ 技術設計（資料模型 / API / 核心邏輯）、**範圍排除**（明確不做的事）、開放問題。
- # 正確 ✅
- 你想用什麼框架？
- A) Next.js（全端、SSR）
- B) React + Express（前後端分離）
- C) 其他（請說明）
- ```
+ ### 7. 自我審查
- ### YAGNI 執行
- ```
- # 使用者說：「以後可能需要多語言支援」
- # 正確回應：
- 「現在的 MVP 需要多語言嗎？如果不需要，我們先不做，
- 但設計時會確保之後容易加入。」
- ```
+ 檢查：無佔位符或 TODO、無內部矛盾、無模糊描述、技術選擇皆有理由、範圍排除清楚、
+ 無 YAGNI 功能。
- ### 設計隔離
- ```
- # 複雜系統應拆分為獨立單元
- 每個單元應有：
- - 明確的職責（做什麼）
- - 清楚的介面（怎麼互動）
- - 獨立的測試策略
- ```
+ ### 8. 使用者審查 → 下一步
- ### 遵循現有模式
- ```
- # 在已有 codebase 中
- - 先了解現有的架構模式
- - 新設計應與現有模式一致
- - 如果需要偏離，明確說明理由
- ```
+ 依回饋修改至批准。批准後的下一步：交 `task-planner` 拆微任務，或直接進
+ 6 步開發迴圈實作。**批准前後都不跳過迴圈的測試與 review 步驟。**
## 常見錯誤
| 錯誤 | 正確做法 |
|------|---------|
| 設計前就開始寫程式碼 | 堅守硬閘門 |
- | 一次問太多問題 | 一次一個 |
- | 把查得到的事實拿去問使用者 | 事實自己查（Read/Grep/git），只問決策並附建議答案 |
+ | 一次問太多問題 | 一次一個，多選優先 |
+ | 把查得到的事實拿去問使用者 | 事實自己查，只問決策並附建議答案 |
| 假設使用者的技術偏好 | 提供選項讓使用者選 |
- | 設計過度（over-engineering） | YAGNI — 只做需要的 |
- | 跳過範圍評估 | 大專案必須先拆分 |
+ | 設計過度 | YAGNI — 只做需要的 |
+ | 跳過範圍評估 | 大專案必先拆分 |
| 設計文件有佔位符 | 自我審查消除所有 TODO |
-
- ## 與其他技能的協作
-
- ```
- design-brainstorm → task-planner → subagent-orchestrator
- → /dd-start → DD Pipeline 正式流程
- ```
-
- - **design-brainstorm** 負責：從模糊想法到清晰設計
- - **task-planner** 負責：從設計到可執行的微任務
- - **/dd-start** 負責：正式需求分析（如果要走 DD Pipeline）