| 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。