brainstorming

brainstorming skill 概覽

brainstorming skill 的用途是什麼

brainstorming skill 是一套在動手實作前使用的結構化前置流程，目的是把還很模糊的想法，先整理成經過確認的設計，再進入寫程式階段。它的核心功能不是抽象地「發想點子」，而是先把範圍、假設、需求與設計取捨攤開來，藉此降低後續重工。

哪些人適合安裝這個 brainstorming skill

這個 brainstorming skill 特別適合那種常常從「我們應該做 X」直接跳到實作的人。尤其適用於：

• 功能規劃
• 元件設計
• 行為變更
• 內部工具提案
• 用 brainstorming 做 Requirements Planning

如果你本來就有嚴謹的 spec 流程，這個 skill 仍然有價值，因為它可以作為進入正式流程前的一個輕量前置步驟。

它和一般 prompt 最大的差別在哪裡

最關鍵的差異在 SKILL.md 裡的硬性關卡：agent 在提出設計並取得批准之前，不應該直接實作、起 scaffold 或寫任何程式碼。這聽起來很簡單，但它會明顯改變行為模式。一般「幫我做這個」類型的 prompt，助手往往會直接跳進解法；這個 skill 則強制先把設計說清楚。

使用者在安裝前真正關心的事

多數人在安裝前，通常會先想快速確認三件事：

1. 這會不會拖慢我？
2. 它問的問題會不會有料，而不是很空泛？
3. 它能不能幫我討論視覺設計？

答案是：它確實是刻意加入流程成本，但如果想法本身很小，增加的負擔其實也不大。這個 skill 明確主張，即使是「看起來很簡單」的工作，也值得先做一輪簡短設計，因為最容易造成昂貴錯誤的，往往就是那些一開始沒被說破的隱含假設。

如何使用 brainstorming skill

brainstorming skill 的安裝與設定

要從 repository 加入這個 skill，請使用：
npx skills add https://github.com/obra/superpowers --skill brainstorming

安裝後，建議先看這幾個檔案：

• skills/brainstorming/SKILL.md
• skills/brainstorming/visual-companion.md
• skills/brainstorming/spec-document-reviewer-prompt.md

如果你預期會用到視覺探索，也建議一併查看：

• skills/brainstorming/scripts/start-server.sh
• skills/brainstorming/scripts/frame-template.html

這個 brainstorming skill 預設的核心工作流程

這個 brainstorming 的使用方式有明確偏好，流程通常是：

1. 先探索專案脈絡
2. 視情況提供 visual companion
3. 一次只問一個釐清問題
4. 整理並提出設計
5. 取得明確批准
6. 然後才進入規劃或實作

如果你的 agent 從想法直接跳到寫 code，那它其實沒有真正照這個 skill 的方式運作。

想讓 brainstorming skill 用得更好，該提供什麼輸入

這個 skill 在你提供的不只是功能名稱時，效果會最好。好的起始輸入通常會包含：

• 要解決的問題
• 使用者是誰
• 目前系統或 repo 的脈絡
• 限制條件
• 「完成」的定義
• 已知的不做項目

一個比較弱的輸入：

Add notifications.

一個比較強的輸入：

Add in-app notifications for failed background imports. Users are operations staff, not end customers. We already have email alerts, but they are too slow for live triage. Keep scope to the admin dashboard only. Do not add mobile push or user preference management in v1.

第二種寫法，能讓 brainstorming skill 有足夠結構去追問更精準的後續問題。

如何把模糊想法整理成更強的第一個 prompt

這是一個實用的 brainstorming prompt 範本：

Use the brainstorming skill for Requirements Planning.
Context: [project/repo/product]
Problem: [what is happening now]
Target user: [who is affected]
Constraints: [timeline, stack, compliance, UX, compatibility]
Non-goals: [what not to solve]
Please ask clarifying questions one at a time, then present a proposed design for approval before any implementation.

這種寫法能貼合 skill 原本設計的流程，也能降低它問出空泛問題的機率。

釐清問題在 brainstorming 流程裡應該怎麼問

有一個細節很重要：這個 skill 預期問題是一次一題，而不是丟出一整份超長探索問卷。原因在於，前一題的回答通常會改變下一題應該怎麼問。如果你的 agent 一次倒出 15 個問題，就會失去這份 brainstorming 指南想建立的互動式收斂過程。

什麼情況下該用 visual companion

這個 repository 內建一個瀏覽器式的 visual companion。當使用者「看見選項」會比只讀文字更容易理解時，就很適合使用，例如：

• wireframes
• 版面比較
• UI 流程
• 架構圖
• 狀態或關係圖示

但不要只因為主題提到 UI 就自動啟用。像「這個應該做成 wizard 還是 modal？」這類概念性問題，用文字討論通常就夠了；但像「這兩種 wizard 版型哪一種更清楚？」就非常適合走視覺路徑。

visual companion 實際上是怎麼提供的

這個視覺輔助不只是說明文件而已；repository 裡其實有可以啟動本機 session 的腳本：

• scripts/start-server.sh
• scripts/stop-server.sh
• scripts/server.cjs
• scripts/helper.js

start-server.sh 會在隨機的高位 port 啟動本機 server，並可把 session 檔案存放在 /tmp，或是像 .superpowers/brainstorm/ 這類專案目錄中。若你希望 mockup 能跨 session 保留，這點就很實用。

在依賴視覺流程前，先注意這些環境細節

這套視覺流程預設你所在的環境可以透過瀏覽器存取。如果你是在 remote container、VM，或 SSH 工作流中使用，就要特別注意：

• --host
• --url-host
• session 目錄是否可持久保存

如果只是本機使用，預設設定通常很直覺；但如果是共享環境或遠端環境，最好在把整個流程建立在瀏覽器回饋之前，先把網路存取細節規劃好。

想快速上手 brainstorming skill，最值得先讀哪些檔案

如果你想用最短路徑把使用品質拉到實際可用，建議按這個順序閱讀：

1. SKILL.md：先理解行為契約
2. visual-companion.md：了解什麼情況下瀏覽器支援真的有幫助
3. spec-document-reviewer-prompt.md：掌握什麼叫做「已經夠清楚，可以開始實作」
4. scripts/start-server.sh：如果你需要視覺化流程，再看這個

這樣的閱讀順序會先讓你掌握決策邏輯，再看選配工具。

好的 brainstorming 輸出應該長什麼樣子

一次成功的 brainstorming session，最後應該收斂成一份足夠具體、可以被審查的設計，至少包含：

• 目標與使用者
• 範圍邊界
• 關鍵決策
• 尚未排除的風險或假設
• 足夠具體到可以開始規劃實作

如果輸出只是一份鬆散的點子清單，那通常代表 session 停得太早了。

如何用 brainstorming skill 做 Requirements Planning

如果你要用 brainstorming 做 Requirements Planning，可以把它當成寫 spec 之前的前置步驟：

1. 先釐清問題與限制
2. 草擬設計或需求輪廓
3. 取得批准
4. 撰寫 spec
5. 有需要的話，再跑一次 spec reviewer prompt template

這是這個 skill 最強的使用情境之一，因為它能在規劃正式定案前，就先抓出 scope drift 與模糊地帶。

brainstorming skill 常見問題

brainstorming skill 只適合大型專案嗎？

不是。這個 skill 明確反對「小東西可以跳過設計」這種想法。對非常小的改動來說，所需的設計也許可以很短，但設計這一步本身仍然重要。很多時候，它在那些表面上很簡單、其實假設很多的變更上，價值反而最高。

這比一般的 brainstorming prompt 更好嗎？

通常是，前提是你的真正目標是得到可以執行的清晰度，而不是單純追求點子數量。一般 brainstorming prompt 也許能生成很多選項；但如果你需要的是收斂式思考——理解脈絡、縮小選擇範圍、產出一份經批准的設計——這個 brainstorming skill 通常更合適。

brainstorming skill 對新手友善嗎？

是，尤其適合單打獨鬥、還沒養成規劃習慣的人。這套結構剛好能補足一種常見新手失誤：還沒釐清需求與取捨，就直接實作第一個看起來可行的想法。

什麼情況下 brainstorming 不太適合？

以下情況可以跳過，或至少大幅縮短：

• 任務純粹是機械性工作，而且規格已經完整明確
• 你根本不是在做設計或行為決策
• 使用者已經批准了詳細 spec，現在只需要執行

即使如此，仍要先確認這個硬性關卡不會和你的工作流程衝突。這個 skill 本來就是刻意設計得比較嚴格。

這個 skill 會產生程式碼嗎？

不會，而且這是刻意的。brainstorming skill 的設計就是要在取得批准前停在實作之前。如果你需要 code generation，做法應該是先用這個 skill，把設計定下來，接著再交給規劃或實作型 skill。

一定要用 visual companion 才有價值嗎？

不需要。瀏覽器路徑是選用，不是必須。就算只用文字做 brainstorming，對需求、範圍與技術取捨的討論，仍然能拿到大部分價值。視覺工具最有用的時候，是決策本身本來就高度依賴畫面表達。

如何把 brainstorming skill 用得更好

給 brainstorming skill 更完整的專案脈絡

提升結果品質最快的方法，就是讓討論有真實脈絡可依附：

• 相關檔案或資料夾
• 現有行為
• 最近的變更
• 已知技術限制
• 受影響的使用者

這個 skill 本身就要求 agent 先探索專案脈絡。你可以更進一步，直接指出那些脈絡存在於哪裡。

盡早說清楚限制與 non-goals

很多品質不高的 brainstorming 輸出，都是因為邊界沒有被定義清楚。請直接告訴這個 skill 哪些東西必須保留、哪些不能碰：

• backward compatibility
• 效能上限
• 法規遵循或安全需求
• 時程或人力限制
• 明確不在範圍內的功能

這樣比較容易產出範圍更聚焦、也更有決策價值的設計。

要求它交付設計，不只是想法

如果你想要的是可以銜接實作的輸出，就要直接說。你可以要求 brainstorming skill 最後收斂成：

• 一份 proposed design
• 假設條件
• 尚未解決的問題
• 明確的 approval checkpoint

這會把 session 從無止盡發想，拉回到可使用的產出物。

視覺化 brainstorming 要用更強的 prompt

如果是視覺工作，不要只說「show mockups」。要明確指定畫面需要比較的是什麼：

Show two dashboard layout options for failed import alerts: one optimized for fast triage, one optimized for detail review. Keep the existing navigation shell. Highlight which option better supports keyboard-heavy operators.

像這種 prompt，才能幫 visual companion 產出可供決策的內容，而不是只做出好看的畫面。

注意最常見的失敗模式：太早跳進解法

這個 skill 最大的失敗模式，就是在問題還沒被真正理解前，就先跳去談實作細節。如果發生這種情況，請把 session 拉回來：

Pause implementation thinking. What assumptions are we making about the user workflow, edge cases, and scope boundaries?

這能讓 brainstorming 指南重新對齊它最核心的用途。

用一輪 review 把第一版輸出修到更好

初版設計出來後，與其整個重來，不如要求一次有焦點的修訂：

• 哪裡有歧義？
• 哪裡過度設計？
• 哪些地方會拖累實作規劃？
• 哪些內容還不足以獲得批准？

這時 repository 裡的 spec-document-reviewer-prompt.md 很有用，因為它檢查的是會實際卡住規劃的問題，而不是只做表面修飾。

讓 brainstorming 產出保持精簡，但決策資訊要完整

常見錯誤之一，是把設計文件膨脹成不必要的長篇內容。更好的 brainstorming，不等於更長的 brainstorming。對簡單工作來說，只要幾段扎實文字，涵蓋目的、範圍、限制、做法與批准條件，通常就夠了。標準不是文件長度，而是下一步能不能在更少猜測下繼續往前走。

把 brainstorming 與 spec review 流程搭配使用

如果你是認真要把這個 skill 納入工作流，最好再搭配一次對產出 spec 或設計的後續審查。內附的 reviewer template 會檢查：

• placeholders
• 前後矛盾
• 模糊需求
• 過度寬泛的範圍
• 沒被要求的複雜度

這樣一來，brainstorming skill 就不只是聊天時好用，而是真的能接進實際交付流程。