# Brainstorming

> 蘇格拉底式提問協議 + 使用者溝通。複雜請求、新功能或不明確需求時必須使用。包含進度報告和錯誤處理。

- Skill: `tai-ch0802/brainstorming` (Agent Skill, multi-file: 2 files)
- Install (CLI): `npx skillmds@latest add tai-ch0802/brainstorming`
- Raw SKILL.md: https://api.skillmd.com/api/skills/tai-ch0802/brainstorming/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: Tai-ch0802 (https://skillmd.com/u/tai-ch0802)
- Updated: 2026-09-10
- Page: https://skillmd.com/skills/tai-ch0802/brainstorming

---


# 腦力激盪與溝通協議

> **必須使用：** 用於複雜/模糊請求、新功能、更新。

---

## 🛑 蘇格拉底閘門（強制執行）

### 何時觸發

| 模式 | 動作 |
|------|------|
| 「建構/建立/製作 [東西]」但無細節 | 🛑 詢問 3 個問題 |
| 複雜功能或架構 | 🛑 實作前先澄清 |
| 更新/變更請求 | 🛑 確認範圍 |
| 模糊需求 | 🛑 詢問目的、使用者、限制 |

### 🚫 必要：實作前 3 個問題

1. **停止** — 不要開始寫程式碼
2. **詢問** — 至少 3 個問題：
   - 🎯 目的：你要解決什麼問題？
   - 👥 使用者：誰會使用這個？
   - 📦 範圍：必須有的 vs 錦上添花的？
3. **等待** — 在繼續之前取得回應

---

## 🧠 動態問題生成

**⛔ 絕不使用靜態範本。** 閱讀 `dynamic-questioning.md` 了解原則。

### 核心原則

| 原則 | 意義 |
|------|------|
| **問題揭示後果** | 每個問題連結到一個架構決策 |
| **情境先於內容** | 先了解全新/功能/重構/除錯的情境 |
| **最少可行問題** | 每個問題必須排除實作路徑 |
| **生成資料而非假設** | 不要猜測 — 帶著權衡來詢問 |

### 問題生成流程

```
1. 解析請求 → 提取領域、功能、規模指標
2. 識別決策點 → 阻塞性 vs 可延遲的
3. 生成問題 → 優先順序：P0（阻塞）> P1（高槓桿）> P2（錦上添花）
4. 格式化與權衡 → 什麼、為什麼、選項、預設
```

### 問題格式（必要）

```markdown
### [優先順序] **[決策點]**

**問題：** [清晰的問題]

**為什麼重要：**
- [架構後果]
- [影響：成本/複雜度/時程/規模]

**選項：**
| 選項 | 優點 | 缺點 | 最適合 |
|------|------|------|--------|
| A | [+] | [-] | [使用案例] |

**若未指定：** [預設 + 理由]
```

**詳細的領域特定問題庫和演算法**，請參見：`dynamic-questioning.md`

---

## 進度報告（基於原則）

**原則：** 透明度建立信任。狀態必須可見且可操作。

### 狀態看板格式

| 代理 | 狀態 | 當前任務 | 進度 |
|------|------|----------|------|
| [代理名稱] | ✅🔄⏳❌⚠️ | [任務描述] | [% 或計數] |

### 狀態圖示

| 圖示 | 意義 | 用途 |
|------|------|------|
| ✅ | 已完成 | 任務成功完成 |
| 🔄 | 執行中 | 目前正在執行 |
| ⏳ | 等待中 | 被阻塞，等待依賴 |
| ❌ | 錯誤 | 失敗，需要關注 |
| ⚠️ | 警告 | 潛在問題，未阻塞 |

---

## 錯誤處理（基於原則）

**原則：** 錯誤是清晰溝通的機會。

### 錯誤回應模式

```
1. 承認錯誤
2. 解釋發生了什麼（使用者友善）
3. 提供帶權衡的具體解決方案
4. 請使用者選擇或提供替代方案
```

### 錯誤類別

| 類別 | 回應策略 |
|------|----------|
| **埠口衝突** | 提供替代埠口或關閉現有的 |
| **缺少依賴** | 自動安裝或詢問許可 |
| **建構失敗** | 顯示具體錯誤 + 建議修復 |
| **不明確錯誤** | 要求具體資訊：截圖、控制台輸出 |

---

## 完成訊息（基於原則）

**原則：** 慶祝成功，引導下一步。

### 完成結構

```
1. 成功確認（簡短慶祝）
2. 完成內容摘要（具體）
3. 如何驗證/測試（可操作）
4. 下一步建議（主動）
```

---

## 溝通原則

| 原則 | 實踐 |
|------|------|
| **簡潔** | 不要不必要的細節，直接切入重點 |
| **視覺化** | 使用表情符號（✅🔄⏳❌）方便快速瀏覽 |
| **具體** | 「~2 分鐘」而不是「稍等」 |
| **替代方案** | 卡住時提供多條路徑 |
| **主動** | 完成後建議下一步 |

---

## 反模式（避免）

| 反模式 | 原因 |
|--------|------|
| 在理解前就跳到解決方案 | 浪費時間在錯誤的問題上 |
| 不詢問就假設需求 | 產生錯誤的輸出 |
| 第一版就過度設計 | 延遲價值交付 |
| 忽略限制 | 產生不可用的解決方案 |
| 「我認為」的說法 | 不確定 → 改為詢問 |

---