AI Skills
ce-ideate

ce-ideate

熱門

生成並評估立足於實際脈絡的構想與點子。當使用者要求提供想法、改進方案、出乎意料的選項或 AI 生成的方向，以供選擇並進一步開發時使用；若要精煉使用者自己的想法，請改用 ce-brainstorm。

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

相關技能

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

生成並評估立足於實際脈絡的構想與點子。當使用者要求提供想法、改進方案、出乎意料的選項或 AI 生成的方向，以供選擇並進一步開發時使用；若要精煉使用者自己的想法，請改用 ce-brainstorm。

生成改進構想

注意：今年是 2026 年。 在為發想文件標註日期以及檢查最近的發想產出物時，請使用此年份。

ce-ideate 執行於 ce-brainstorm 之前。

  • ce-ideate 解答：「有哪些最值得探索的強大點子？」
  • ce-brainstorm 解答：「選定的單一點子具體代表什麼意思？」，並在 <root>/plans/ 下撰寫一份僅含需求的統一計畫（unified plan）。
  • ce-plan 解答：「應該如何構建它？」

此工作流程會產生一份排名的發想產出物（ranked ideation artifact）——若存在則寫入 <root>/ideation/，否則寫入 CE 暫存路徑（參見階段 4）。它不會產生需求、計畫或程式碼。

初始化設定（Setup）

在本次調用的開頭、派發任何 subagent 之前執行一次本段指令，並遵循其印出的指示——除非其中有指令與本 Skill 自訂的「向使用者提問」規則相衝突（無論該規則適用於非互動模式或所有模式），此時一律以本 Skill 的規則為準，且不發出阻塞式提問。在同一次調用中切勿重複執行；後續調用本 Skill 或其他 Skill 時會自行執行其初始化。若無可用 Node 執行階段（Node runtime），則 Skill 照常繼續執行。

SKILL_DIR="<absolute path of the directory containing the SKILL.md you just read>";
NODE="$(for c in node nodejs; do command -v "$c" >/dev/null 2>&1 && "$c" -e '' >/dev/null 2>&1 && { echo "$c"; break; }; done)";
if [ -n "$NODE" ]; then
"$NODE" "$SKILL_DIR/scripts/context.mjs" || echo "context script failed; continue with the skill's normal behavior";
else
echo "no Node runtime; continue with the skill's normal behavior";
fi

互動管道（Interaction Method）

請使用各平台的阻塞式提問工具：Claude Code 中使用 AskUserQuestion（若其 schema 未載入，請先以 select:AskUserQuestion 調用 ToolSearch）、Codex 中使用 request_user_input、Antigravity CLI (agy) 中使用 ask_question、Pi 中使用 ask_user（需要 pi-ask-user 擴充功能）。僅在執行環境中不存在阻塞式工具或調用報錯時（例如 Codex 編輯模式），才在對話中退回使用編號選項——切勿僅因需要載入 schema 就直接退回對話選項。絕不可靜默跳過提問。

一次只問一個問題。當有自然可選的選項時，優先採用精簡的單選項目。

焦點提示（Focus Hint）

焦點提示（focus hint） 是本 Skill 被調用時附帶的任何可選上下文——存在於目前的提示詞（prompt）或對話中，無論是使用者直接提供或由調用的 Skill 所傳遞。本 Skill 的其餘部分將其簡稱為 {focus_hint}（若未提供則為空值）。

請將傳入的任何參數視為可選上下文。它可以是：

  • 某個概念，例如 DX improvements
  • 某個路徑，例如 skills/
  • 可供參考的研究產出物——存於任何路徑（專案儲存庫內外皆可）的收集證據檔案（社群研究報告、問卷匯出資料、數據分析備份）；於階段 1 的使用者提供研究子章節中處理
  • 某個限制條件，例如 low-complexity quick wins
  • 某個數量提示，例如 top 3、100 ideas 或 raise the bar

若未提供任何參數，則進行開放式的發想。

產出物根目錄（Artifact Root）

本 Skill 在專案模式（repo mode）下會將發想產出物寫入 <root>/ideation/，並從 <root>/solutions/ 讀取經驗學習（learnings）。請僅在組合此類路徑時才解析 <root>（依據下方區塊）——無專案/非專案模式（no-repo / elsewhere）的工作流程會寫入暫存目錄且完全不需要它，因此在模式分類前切勿解析或建立根目錄。若有解析出路徑，請將解析後的路徑傳給任何 subagent，而不是傳遞設定檔。

<!-- 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，與過往完全一致。
  • 驗證設定值：必須為專案相對目錄，且其解析符號連結（symlink）後的真實路徑必須保持在專案內部，既不能是專案根目錄，也不能位在 .git/ 底下。否則請停止執行並回報指出 docs_root 與該值的錯誤——絕不要退回使用 docs。
  • 使用 <root> 作為唯一的產出物存放位置：若不存在則建立它，將每個路徑組合為 <root>/<subdir>（配合本 Skill 自訂的子目錄），且切勿同時讀取 docs。
    <!-- ce-docs-root:end -->

核心原則（Core Principles）

  1. 發想前先立足實際（Ground before ideating） - 先掃描實際的程式碼庫。切勿脫離儲存庫憑空產生抽象的產品建議。
  2. 大量生成 -> 全面批判 -> 僅解釋倖存者（Generate many -> critique all -> explain survivors only） - 品質把關機制在於「附帶理由的明確淘汰」，而非盲目樂觀的排序。不要讓多餘的流程掩蓋此模式。
  3. 將行動導向至 Brainstorming 階段（Route action into brainstorming） - Ideation（發想）旨在找出有潛力的方向；ce-brainstorm 則能將選定的方向定義得足夠精確以利規劃。切勿直接從發想產出跳過至規劃階段。

模型分層（Model Tiers）

Sub-agent 的派發分層依據任務特性而定，絕不硬編碼特定模型名稱：

  • 提取層（Extraction tier） — 證據搜集員（evidence scouts）與其他檢索/引用工作。當目前執行環境提供已知的模型覆寫設定時，採用平台最便宜但勝任的模型。「勝任」亦包含於規範中——當專案庫過大或技術棧冷門時，升級至生成層。
  • 生成層（Generation tier） — 證據導向的發想框架與基礎驗證。當目前執行環境提供已知的模型覆寫設定時，使用平台的初中階/中層模型。若模型名稱未知，請忽略覆寫並直接繼承設定，切勿憑空猜測。
  • 頂層（Ceiling tier） — 高階發想框架、跨領域綜合分析與最終仲裁。直接省略模型參數，繼承協調者（orchestrator）的模型。

降級規則（Degradation rule）。 當平台的 subagent 原生機制不支援個別 agent 的模型選擇時，全部使用繼承的模型進行派發，並保持讀取預算與檔案上限——此時成本控制來自於結構設計，而非模型分層。

有兩種覆寫會將整個 ideation 團隊提升至頂層：surprise-me 模式（主題探索極度仰賴判斷力，這也是該模式的核心價值）以及 go deep 深度覆寫（階段 0.5）。

執行流程（Execution Flow）

階段 0：恢復與確定範圍（Phase 0: Resume and Scope）

當主題、模式與格式已在提示詞中表達清楚時，只需一次完成本階段即可繼續前進——下方的檢核點是為了排除模糊性而設，而非為了形式走過場。

0.0 決定輸出模式（0.0 Resolve Output Mode）

確定本次執行可能保存的發想產出物之 OUTPUT_FORMAT。輸出模式具有排他性——發想文件要麼寫入為 HTML (.html)，要麼寫入為 Markdown (.md)，絕不同時寫入兩者。優先順序：提示詞內要求 > 使用者已聲明偏好 > 設定檔 > 預設值 (html)，並帶有管線模式（pipeline-mode）的強制覆寫。

與 ce-plan 及 ce-brainstorm（預設為 md）不同，ce-ideate 預設為 html — 發想產出物主要是給人類閱讀以評估候選方向，而豐富且自包含的 HTML 檔案（附帶前幾名候選方案的圖解）能讓點子更容易理解。

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

解析步驟：

  1. 提示詞內要求。 分析使用者本次執行的提示詞中關於本文件輸出格式的要求，無論是以 output: 簡寫或一般口語（例如「幫我做成 markdown」、「我要一個網頁」）表達。當有明確格式時，不分大小寫比對至 md/html，並在將提示詞其餘部分讀取為焦點提示（focus hint）時忽略 output: 簡寫標記。請區分「針對文件格式的要求」與「作為主題內容提及的格式」：例如「針對 HTML 匯出功能進行發想」屬於工作主題而非文件格式要求——切勿據此切換模式。
    • 僅有 output:（無數值） → 空操作（no-op），順延至步驟 2。
    • output:<unknown>（例如 output:pdf） → 捨棄該標記，順延至步驟 2，並在最終解析後於發想後選單上方顯示單行提示：Ignored unknown output: value '<value>' — using <resolved_format> instead.，其中 <resolved_format> 為經歷其餘順序解析後 OUTPUT_FORMAT 實際決定的數值。切勿在提示中硬編碼格式，以免設定檔或預設值與預期不符時誤導使用者。
  2. 使用者已聲明偏好。 若提示詞未包含格式要求，且使用者先前已建立輸出格式偏好（Markdown 對比 HTML）——包含於本次對話早期、記憶中或寫入生效中的指示中，且已存在於目前上下文中——請尊重該偏好（不分大小寫比對 md/html）。被記住的偏好比起鮮少修改的設定檔更具時效性，因此會覆寫步驟 3 的設定檔。切勿開啟或搜尋指示檔案來尋找——僅依據目前上下文已存在的偏好行動；若無，則順延至設定檔。
  3. 設定檔。 若步驟 1-2 未能決定，且上方讀取的設定檔包含**生效中（非註解）**的 ideate_output: 鍵，其值比對為 md 或 html（不分大小寫），則採用之。缺失、無效或已被註解的值將靜默順延。關鍵重點：以 # 開頭的行屬於 YAML 註解，必須忽略——預設的設定檔範本包含例如 # ideate_output: md 的註解範例，若將其誤判為生效設定，會在使用者未主動選擇的情況下，靜默覆寫每次執行的預設值。
  4. 預設值。 否則 OUTPUT_FORMAT=html。
  5. 管線覆寫。 當在任何管線或 disable-model-invocation 上下文中調用時，無視步驟 1-4 強制設定 OUTPUT_FORMAT=md——自動化下游解析器能穩定解析 Markdown，且在管線中生成 HTML 會造成不必要的阻礙。

標記解析慣例： 僅有字面字首標記（例如 output:、適用時的 mode:）會被解析並移除。其他的 <word>:<word> 標記——包含可能出現在焦點提示中的傳統提交字首（如 feat:、fix:、chore:）——皆會原封不動地傳遞。

延後載入格式渲染參考。 產出物會在階段 4（生成後）寫入，因此 references/ideation-sections.md 與格式渲染參考（markdown-rendering.md / html-rendering.md）屆時才需要——在階段 0.0 載入會將其一路帶過整個立足分析與發想派發，徒增負擔。請現在決定 OUTPUT_FORMAT，但在寫入時才載入章節規範與對應的渲染參考（參見 references/post-ideation-workflow.md §4.1）。

output: 偏好不會在交接（階段 5）時自動傳播至 ce-brainstorm——ce-brainstorm 會獨立重新解析其本身的 brainstorm_output 設定。非對稱輸出（ideation.html + 統一計畫 Markdown）是可以接受的；想要兩者皆為 HTML 的使用者可以在 .compound-engineering/config.local.yaml 中設定這兩個鍵。

0.1 檢查最近的發想工作（0.1 Check for Recent Ideation Work）

在 <root>/ideation/ 中尋找過去 30 天內建立的發想文件（*.md 或 *.html）。此為專案模式（repo-mode）下的便利功能：若不存在 git 儲存庫，或解析 <root> 失敗（例如無效的 docs_root），請跳過此掃描並繼續執行——切勿在階段 0.3 將模式分類為專案模式或非專案/無專案模式前中止執行，因為非專案或非軟體發想執行會寫入暫存區域，完全不會存取 <root>/ideation/。

當符合以下條件時，將先前的發想文件視為相關：

  • 主題符合要求的焦點
  • 路徑或子系統與要求的焦點重疊
  • 要求為開放式，且有明顯最近未結案的發想文件
  • 立足於 Issue 的狀態符合：請勿提供 r