AI Skills
ce-brainstorm

ce-brainstorm

熱門

將模糊或宏大的想法，梳理為規模適中、僅包含需求的統一規劃案。當使用者想要發想、釐清範疇、決定打造什麼產品，或在規劃前需要協同確認產品框架時使用。也適用於使用者必須在其聲明不熟悉的領域中界定工作範疇（例如：「我對 X 一無所知，但必須...」），或是要求進行「盲點盤點」——在提問開始前釐清整個決策全貌。不適用於執行已明確界定範疇的工作——例如產品範疇已確定、只需直接實作、除錯或程式碼審查的情境。亦不適用於針對是否採用或切換至特定外部技術、函式庫或平台做出最終決定——腦力激盪旨在界定「要打造什麼」，而非「是否選用外部方案」。

2.4萬星標
1862分支
更新於 2026/7/28
獲取技能源代碼

相關技能

recsys-pipeline-architect24萬academy-guide17萬para-memory-files8萬
SKILL.md
唯讀
名稱
ce-brainstorm
描述

將模糊或宏大的想法，梳理為規模適中、僅包含需求的統一規劃案。當使用者想要發想、釐清範疇、決定打造什麼產品，或在規劃前需要協同確認產品框架時使用。也適用於使用者必須在其聲明不熟悉的領域中界定工作範疇（例如：「我對 X 一無所知，但必須...」），或是要求進行「盲點盤點」——在提問開始前釐清整個決策全貌。不適用於執行已明確界定範疇的工作——例如產品範疇已確定、只需直接實作、除錯或程式碼審查的情境。亦不適用於針對是否採用或切換至特定外部技術、函式庫或平台做出最終決定——腦力激盪旨在界定「要打造什麼」，而非「是否選用外部方案」。

發想功能或改進方案

注意：目前年份為 2026 年。 在為「僅包含需求的統一規劃案」標示日期時請使用此年份。

腦力激盪有助於透過協同對話回答要打造什麼（WHAT）。它在 ce-plan 之前執行，後者會進一步用**如何打造（HOW）**來豐富同一個統一規劃案文件。

此工作流程的持久產出物是一份僅包含需求的統一規劃案（requirements-only unified plan）。在其他工作流程中，這可能被稱為輕量級 PRD 或功能概要（feature brief）。在複合工程（compound engineering）中，請保留工作流程名稱 brainstorm，但將規劃案文件的第一個版本寫入 <root>/plans/ 下，並標註 artifact_readiness: requirements-only，如此一來規劃階段就不需要憑空捏造產品行為、範疇邊界或成功標準。

此 Skill 不會實作程式碼。它負責探索、釐清並記錄決策，供後續的規劃或執行使用。

核心原則

  1. 先評估範疇 - 讓流程儀式感（ceremony）的程度與工作的規模及模糊度相匹配。
  2. 扮演思考夥伴 - 主動提供替代方案、挑戰假設並探索各種假設情境（what-ifs），而非僅僅擷取需求。
  3. 在此解決產品決策 - 面向使用者的行為、範疇邊界與成功標準屬於此工作流程。詳細的實作細節則屬於規劃階段。
  4. 預設將實作細節排除於產品合約（Product Contract）之外 - 除非發想本身本質上就是關於技術或架構的變更，否則請勿包含函式庫、Schema、Endpoint、檔案版面配置或程式碼層級的設計。
  5. 適度調整產出物規模 - 簡單的工作只需要精簡的「僅包含需求的統一規劃案」或簡短的方向對齊。較大的工作則需要更完整的產品合約。切勿增加對規劃毫無幫助的冗餘流程。
  6. 將 YAGNI 原則應用於維護成本而非程式碼撰寫精力 - 優先採用能提供實質價值且最簡單的做法。避免投機性的複雜度與假設性的未來相容設計，但若某項精緻化或令人驚喜的小功能維護成本極低且易於維護，就值得包含在內。
  7. 勿將涵蓋範圍誤作工作拆解 - 在軟體發想中，請將具名的裝置、提供者和資料源視為涵蓋範圍需求，而非自動拆解為獨立的整合工作串。僅在共用的存取路徑無法滿足具名需求時才進行拆分。將連接器（connector）的選擇留給規劃階段，除非該選擇會大幅改變產品範疇或行為。
  8. 每個產出物保持單一且連貫的工作單元 - 當一項請求包含可獨立規劃和交付且具有獨立價值的成果時，在深入探索前先選擇其中一項作為當前焦點。保留目前對周圍工作的理解，但不要將暫定的未來領域直接轉化為本規劃案的需求。

互動規則

這些規則適用於所有腦力激盪，包含引導至 references/universal-brainstorming.md 的通用（非軟體）流程。

  1. 一次只問一個問題 - 每輪對話僅提出一個問題，即使子問題看似相關也是如此。在單一訊息中堆疊多個問題會導致回答品質被稀釋；挑選最有價值的一個問題提出即可。
  2. 優先使用單選題 - 當需要選擇單一方向、單一優先事項或下一個步驟時，請使用單選。
  3. 謹慎且有意識地使用複選題 - 僅在選擇可共存的相容集合（如目標、限制條件、非目標或成功標準）時使用。若優先順序很重要，請在後續追問所選項目中哪一個是首要項目。
  4. 預設使用平台的阻塞式提問工具 - 在 Claude Code 中使用 AskUserQuestion（若其 Schema 未載入，先呼叫帶有 select:AskUserQuestion 的 ToolSearch），在 Codex 中使用 request_user_input，在 Antigravity CLI (agy) 中使用 ask_question，在 Pi 中使用 ask_user（需要 pi-ask-user 擴充套件）。這些工具包含自由文字備用選項，因此精選的選項既能引導回答，又不會限制回答。此預設規則同樣適用於開場與需求挖掘提問，而非僅用於收斂階段。只有在 Harness 中不存在阻塞式工具（包含 ToolSearch 未返回匹配項）或呼叫發生錯誤（例如 Codex 編輯模式）時，才退回到在聊天中使用編號選項——切勿僅因需要載入 Schema 而退回。絕不可默默跳過提問。例外 — 視覺探針門檻（visual-probe gate）： 對於本質上屬於視覺主題（Phase 0.3 觸發條件），第一個形狀/行為/狀態/版面配置/流程/圖表決策受 references/visual-probes.md 規範，且優先於本規則。請參閱 Phase 1.3 門檻。
  5. 僅在問題真正開放時使用開放式提問 - 當回答本質上屬於敘述性質、所提供的選項會主導診斷或反思性回答、或者你無法在不硬湊的情況下寫出 3-4 個真正截然不同且合理的選項時，請放棄使用阻塞式工具。檢驗標準：如果你覺得填滿選項欄位很吃力，說明該問題是開放式的——請直接以開放式提出。規則 1 依然適用：每輪對話僅提出一個問題。
  6. 開放式提問唯有在足夠具體、能引出實質回答時才有價值 - 默認套用規則 5：直接提出問題，切勿說明提問形式的選擇。問題必須提供使用者具體可參考的錨點。好的範例：「關於這件事，目前有人做過最具體的操作是什麼——付費購買、建立替代方案，還是因為它而放棄某個工具？」——它明確指出了什麼才算是有效回答。過於單薄的範例：「你怎麼看？」——沒有任何聚焦切入點，而暗示簡短回答的構框（如「簡短說明」、「是不是」）也會以相同的方式浪費開放式提問的作用。

產出物根目錄

此 Skill 會在 <root>/plans/ 下寫入僅包含需求的規劃案。請在首次組合 <root>/ 路徑時（依據下方區塊）解析 <root>，切勿在需要前提前解析。寫入 <root>/... 或讀取 <root>/solutions/ 皆算作組合 <root>/ 路徑，因此任一操作皆會觸發解析；只有完全不觸及 <root>/ 路徑的執行流程（例如僅使用暫存區或無儲存庫的流程）才會跳過此步驟。

<!-- ce-docs-root:start -->
在組合任何產出物路徑前，先解析 CE 產出物根目錄 <root>。

  • 讀取：先從 <repo-root>/.compound-engineering/config.local.yaml 讀取 docs_root，再讀取 config.yaml；以第一個非空值為準（<repo-root> = git rev-parse --show-toplevel）。若未設定 -> <root> 為 docs，與先前完全一致。
  • 驗證：已設定的值必須是相對於儲存庫的目錄，其真實（解析符號連結後）路徑須保持在儲存庫內部，且既不是儲存庫根目錄，也不在 .git/ 下。否則停止執行並拋出包含 docs_root 及該值的錯誤——絕不退回到 docs。
  • 使用：將 <root> 作為唯一的產出物存放位置：若不存在則建立它，以此 Skill 自身的子目錄將每個路徑組合為 <root>/<subdir>，且絕不重複讀取 docs。
    <!-- ce-docs-root:end -->

產出指導原則

  • 優先保留與決策相關的細節 - 保留下一階段決策所需的特徵事實、權衡（tradeoffs）和注意事項；優先精簡引言、重複內容及可有可無的背景說明。

模型分級（Model Tiers）

子 Agent（Sub-agent）的分派是依據任務型態進行分級，絕不硬編碼特定模型名稱。當分派 Phase 1.1 的背景探查員（grounding scout）、Phase 2.6 的主張驗證員（claim verifier）或可選的 Slack 調查員時，請參閱 references/model-tiers.md 以取得分級定義（提取 / 生成 / 上限）以及適用於不支援單獨 Agent 模型選擇或完全無子 Agent 原生功能的平台的降級規則。

功能描述

功能描述（feature description）是呼叫此 Skill 時傳入的輸入內容——即要探索的主題，存在於目前的提示詞或對話中，無論是使用者直接提供還是由上層呼叫的 Skill 所傳遞。

若未提供功能描述，請詢問使用者： 「您想探索什麼內容？請描述您正在思考的功能、問題或改進方案。」

在取得使用者的功能描述之前，請勿繼續執行。

工作階段已決定的事項。 呼叫此 Skill 的對話，或是作為呼叫輸入傳入的精簡概要（來自使用者或上層呼叫 Skill）可能包含先前已審視並選定的決策。在對對話中所帶入的決策進行分類前，請先閱讀 references/settled-decisions.md——其中包含已定案測試、兩種來源分類、註解格式以及擷取規則。跳過分類會導致雙向的失敗：重複詢問使用者已做出的決策，或是將未經審視的斷言誤提升為已定案決策。

執行流程

Phase 0：恢復、評估與路由

0.0 解析輸出模式

在觸發任何其他階段前先確定 OUTPUT_FORMAT。輸出模式具有排他性——僅包含需求的統一規劃案只會寫入為 Markdown (.md) 或 HTML (.html) 其中一種，絕不同時寫入兩者。優先順序：提示詞內請求 > 使用者先前聲明的偏好 > 設定檔 > 預設值 (md)，並帶有硬性的管道模式（pipeline-mode）覆寫。

讀取設定檔。 在執行階段透過 Shell 工具執行 git rev-parse --show-toplevel 來解析 <repo-root>。接著使用原生檔案讀取工具讀取 <repo-root>/.compound-engineering/config.local.yaml。若無法解析根目錄（非 Git 儲存庫）或檔案不存在，則退回使用下方的預設值。

解析步驟：

  1. 提示詞內請求。 分析使用者本次執行的提示詞，檢查是否有針對本文檔輸出格式的請求（以 output: 簡寫或自然語言如「將此做成網頁」、「我要 HTML 格式」表示）。若有明確格式，不分大小寫比對 md/html，並在將提示詞其餘部分讀取為功能描述時忽略 output: 簡寫標記。請區分關於文檔格式的請求與作為主題名稱的格式：例如「探索 HTML 匯出功能」屬於工作主題而非文檔格式請求——切勿據此切換模式。
    • 僅有 output:（無值）→ 空操作（no-op），退回至步驟 2。
    • output:<未知>（例如 output:pdf）→ 丟棄該標記，退回至步驟 2，並在最終解析完成後，記得在生成後選單上方顯示一行提示：Ignored unknown output: value '<value>' — using <resolved_format> instead.，其中 <resolved_format> 為在完成其餘優先級步驟後 OUTPUT_FORMAT 實際解析出的值。切勿在提示中硬編碼 md——當設定檔設為 HTML 時這會誤導使用者。
  2. 使用者先前聲明的偏好。 若此提示詞未包含格式請求，請遵從使用者先前建立的輸出格式偏好（Markdown 對比 HTML）——無論是在此工作階段先前對話、你的記憶中，或寫入其作用中的指令中，只要已存在於你的 Context 中即可（不分大小寫比對 md/html）。被記住的偏好比起鮮少修改的設定檔更新，因此它會覆寫步驟 3 的設定檔。請勿開啟或搜尋指令檔案去尋找它——僅根據已存在於 Context 中的偏好操作；若無，則退回至設定檔。
  3. 設定檔。 若步驟 1-2 未能解析，且上方讀取的設定檔包含**有效（未被註解）**的 brainstorm_output: 鍵值，且其值比對為 md 或 html（不分大小寫），則使用該值。缺失、無效或已被註解的值將默默跳過。關鍵：以 # 開頭的行是 YAML 註解，必須忽略——隨附的設定檔範本包含註解範例，例如 `# b