| name | oc-brainstorm |
| description | Use when the user has an idea or feature request and wants to explore implementation approaches, or says 'brainstorm', '腦力激盪', '想辦法', 'explore idea', '有個想法', '可不可以做', 'how would we', '怎麼實現'. |
oc-brainstorm
核心原則：誠實優先
以下原則凌駕所有步驟，在每個階段都適用：
- 不可行就說不可行，解釋原因
- 可行但代價高就量化代價
- 不確定就說不確定，標記待驗證假設
- 不把「理論上可行但沒人做過」包裝成「可行」
- 每個方案都必須列出缺點
A. 釐清想法
確認使用者有提供 idea。如果沒有，用 AskUserQuestion 詢問：「想探索什麼想法？」
將 idea 拆解為三個面向，不明確就問，不假設：
- 目標 — 想達成什麼
- 動機 — 為什麼想做
- 範圍 — 影響哪些部分（config、workspace、RPi4 服務、外部整合等）
用一段摘要向使用者確認理解是否正確，再進入研究。
B. 研究
執行環境：LOCAL
同時進行兩條研究路線（盡量用 parallel tool calls），再整合結果：
1. OpenClaw 官方文件
用 oc-openclaw agent（或直接用 Context7 MCP：resolve-library-id → query-docs）查詢：
- 相關功能/欄位是否存在
- Config 語法和可用選項
- 已知限制或注意事項
2. ClawHub 市集
執行 /oc-clawhub 搜尋相關 skill 或社群實作。
3. 整合研究摘要
將兩個來源的結果整合為一段摘要，標注資訊來源：
📖 官方文件：...
🏪 ClawHub：...
如果兩個來源都沒有相關資訊，誠實告知。
C. 可行性評估
根據研究結果，從四個軸向評估：
| 軸 | 等級 |
|---|
| 技術可行性 | ✅ 可行 / ⚠️ 有條件 / ❌ 不可行 |
| 實施複雜度 | 低 / 中 / 高 |
| 維護成本 | 低 / 中 / 高 |
| 風險 | 低 / 中 / 高 |
必須標注以下任何一項（如果存在）：
- 🚫 硬限制 — 技術上無法繞過的限制（例：Telegram Bot API 不送 bot-to-bot 訊息）
- ⚠️ 待驗證假設 — 研究未能確認、需要實測才知道的部分
- 📌 前置條件 — 必須先完成才能開始的事項
不可行 → 直接告知並結束。 不硬湊方案。可以：
- 建議替代方向（如果有的話）
- 建議
/oc-park 暫存等待條件成熟
- 記錄不可行原因到 MEMORY.md（如果是跨 session 有用的教訓）
- 如果 session 即將結束，建議
/oc-retro 記錄結論
D. 方案比較
提出至少 2 個方案（除非確實只有一條路，需說明原因）。
每個方案包含：
- 名稱 — 簡短辨識用
- 概述 — 2-3 句說明做法
- 優點
- 缺點（必填） — 不可省略
- 涉及變更 — 哪些檔案/config/服務會改動
- 預估工作量 — 簡單（< 30 分鐘）/ 中等 / 大型
呈現比較表：
| | 方案 A | 方案 B |
|---|--------|--------|
| 技術可行性 | ... | ... |
| 複雜度 | ... | ... |
| 維護成本 | ... | ... |
| 風險 | ... | ... |
| 推薦度 | ⭐⭐⭐ | ⭐⭐ |
用 AskUserQuestion 讓使用者選擇方案（或提出其他想法）。
E. 收斂
根據使用者選擇：
- 選定方案 → 使用 EnterPlanMode 展開具體執行步驟。Plan 中視需要引用
/oc-deploy、/oc-sync 等 skill。
- 發現 blocker → 建議
/oc-park 暫存，記錄 blocker 和恢復條件。
- 不可行 → 記錄原因。如果是跨 session 有用的教訓，更新 MEMORY.md。
