從想法到設計
透過自然的協作對話，將想法轉化為完整的設計與規格。
首先了解當前專案脈絡，接著一次一個問題逐步釐清想法。一旦你理解要建構的內容，就呈現設計並取得使用者核准。
反模式：「這個太簡單了，不需要設計」
每個專案都必須經歷此流程。待辦清單、單一功能的工具程式、設定變更 — 全部都需要。 「簡單」的專案正是未經檢驗的假設造成最多浪費工作的地方。設計可以很短（對於真正簡單的專案，可能只需幾句話），但你必須呈現它並取得核准。
檢查清單
你必須為以下每個項目建立一個任務，並依序完成它們：
- 探索專案脈絡 — 檢查檔案、文件、最近的提交記錄
- 提出釐清問題 — 一次一個，了解目的、限制條件、成功標準
- 提出 2-3 種方法 — 附帶取捨分析與你的建議
- 呈現設計 — 根據複雜度調整各節篇幅，每節後取得使用者核准
- 撰寫設計文件 — 儲存至
docs/superpowers/specs/YYYY-MM-DD-<topic>-design.md並提交 - 規格自我審查 — 快速內嵌檢查：預留文字、矛盾、模糊、範圍
- 使用者審查書面規格 — 在繼續之前請使用者審查規格檔案
- 過渡到實作 — 呼叫寫作計畫技能以建立實作計畫
流程圖
flowchart TD
A[探索專案脈絡] --> B[提出釐清問題]
B --> C[提出 2-3 種方法]
C --> D[呈現設計各節]
D --> E{使用者核准設計？}
E -- 否，修訂 --> D
E -- 是 --> F[撰寫設計文件]
F --> G[規格自我審查<br/>內嵌修正]
G --> H{使用者審查規格？}
H -- 要求變更 --> F
H -- 核准 --> I[呼叫寫作計畫技能]
最終狀態是呼叫寫作計畫。 請勿呼叫任何實作技能。此流程後唯一可呼叫的技能是寫作計畫。
流程
理解想法：
- 首先檢視當前專案狀態（檔案、文件、最近的提交記錄）
- 在提出詳細問題之前，先評估範圍：如果請求描述多個獨立的子系統（例如「建立一個包含聊天、檔案儲存、帳務與分析功能的平台」），請立即標記出來。不要花費問題來釐清一個需要先分解的專案的細節。
- 如果專案對於單一規格來說過大，請協助使用者將其分解為子專案：有哪些獨立部分、它們之間如何關聯、應該以何種順序建構？然後透過正常流程設計第一個子專案。每個子專案都擁有自己的規格 → 計畫 → 實作循環。
- 對於範圍適當的專案，一次一個問題逐步釐清想法
- 盡可能偏好選擇題，但開放式問題也可以
- 每則訊息只問一個問題 — 如果一個主題需要更多探索，將其分解成多個問題
- 專注於理解：目的、限制條件、成功標準
探索方法：
- 提出 2-3 種不同的方法，並附帶取捨分析
- 以對話方式呈現選項，附上你的建議與理由
- 先介紹你建議的選項，並說明原因
呈現設計：
- 一旦你相信已理解要建構的內容，就呈現設計
- 根據複雜度調整各節篇幅：簡潔情況只需幾句話，細微之處可達 200-300 字
- 每節之後詢問：「目前看起來正確嗎？」
- 涵蓋範圍：架構、元件、資料流程、錯誤處理、測試
- 如果有任何不合理之處，準備好回頭釐清
為隔離性與清晰度而設計：
- 將系統分解為較小的單元，每個單元有單一明確的目的，透過定義良好的介面進行溝通，並且可以獨立理解與測試
- 針對每個單元，你應該能夠回答：它做什麼、如何使用它、它依賴什麼？
- 有人能在不閱讀其內部實作的情況下理解一個單元的功能嗎？你能在不破壞使用者的情況下改變內部實作嗎？如果不能，邊界需要調整。
- 較小且邊界良好的單元對你來說也更容易處理 — 你能更好地推理可以同時容納在脈絡中的程式碼，而且當檔案專注單一時，你的編輯會更可靠。當一個檔案變得龐大時，這通常表示它做的事情太多了。
在現有程式碼庫中工作：
- 在提出變更之前先探索當前結構。遵循現有模式。
- 如果現有程式碼存在影響工作的問題（例如檔案過大、邊界不明確、責任糾纏不清），請將有針對性的改進納入設計 — 就像一個好的開發者會改進他們所處理的程式碼一樣。
- 不要提議不相關的重構。專注於服務當前目標的內容。
設計完成後
文件化：
- 將驗證過的設計（規格）寫入
docs/superpowers/specs/YYYY-MM-DD-<topic>-design.md- （使用者對規格儲存位置的偏好會覆蓋此預設值）
- 將設計文件提交至 git
規格自我審查： 撰寫規格文件後，以全新眼光檢視它：
- 預留文字掃描： 有任何「待決定」、「待辦事項」、「不完整的章節」或模糊的需求嗎？修正它們。
- 內部一致性： 是否有任何章節相互矛盾？架構是否符合功能描述？
- 範圍檢查： 此內容是否足夠專注以用於單一實作計畫，還是需要進一步分解？
- 模糊性檢查： 是否有任何需求可以被解讀為兩種不同的方式？如果是，請選擇一種並明確說明。
立即修正任何問題。無需重新審查 — 只需修正並繼續。
使用者審查關卡： 在規格審查循環通過後，請使用者在繼續之前審查寫好的規格：
「規格已撰寫完成並提交至
<path>。請審查它，並讓我知道您是否希望在開始撰寫實作計畫之前進行任何變更。」
等待使用者的回應。如果他們要求變更，請進行修正並重新執行規格審查循環。只有在使用者核准後才能繼續。
實作：
- 呼叫寫作計畫技能以建立詳細的實作計畫
- 請勿呼叫任何其他技能。寫作計畫是下一步。
關鍵原則
- 一次一個問題 — 不要用多個問題讓使用者不知所措
- 偏好選擇題 — 在可能的情況下，比開放式問題更容易回答
- 嚴守 YAGNI — 從所有設計中移除不必要的功能
- 探索替代方案 — 在定案之前，始終提出 2-3 種方法
- 漸進式驗證 — 呈現設計，在繼續之前取得核准
- 保持彈性 — 當有不合理之處時，回頭釐清
從上游技能中移除的內容
原始 brainstorming 技能（obra/superpowers）包含一個「視覺夥伴」功能：一個用於在腦力激盪期間在瀏覽器標籤頁中顯示模擬畫面的 Node.js 瀏覽器伺服器（scripts/server.cjs、scripts/start-server.sh、scripts/stop-server.sh）。SkillSpector 因 stop-server.sh 中的工具參數濫用而封鎖了該技能。
此移植完全移除了視覺夥伴。核心方法論 — 協作設計對話、硬性關卡、規格自我審查、使用者審查關卡、過渡到寫作計畫 — 是純粹的流程指引，不包含任何腳本、shell 或外部伺服器。它在結構上是安全的。
如果你需要在設計對話期間顯示模擬畫面或圖表，請使用 agent 的原生工具（瀏覽器 MCP 工具、圖片生成或聊天中的內嵌 Mermaid/ASCII 圖表），而不是捆綁的伺服器。