腦力激盪 (brainstorm)
將模糊的問題轉換為一組結構化的候選 ADR 和計畫項目。此技能為 產生和提出/唯讀 — 絕不會直接寫入 ADR 或計畫檔案。在獲得批准後，它會將每個候選項目交給 new-adr 和 new-plan 技能。
步驟 0 — 前置條件與背景
- 確認儲存庫已引導完成（或註明輸出可以為全新的 bootstrap 技能執行提供種子）。
- 閱讀
CONVENTIONS.md以了解 ADR 的格式和生命週期，並瀏覽INDEX.md和現有 ADR，以便候選項目不會與現有內容重複或矛盾，且相依關係指向實際的 ADR。
步驟 0.5 — 評估（先執行）
在開始分解之前，先執行共用的評估協議：
-
優先重複使用已提供的答案。 將請求或本次對話中已提供的適用選擇（包括深度）視為已回答。總結它們，無需再次詢問；預設值絕不會取代明確的選擇。如果所有重大選擇都已提供，則繼續。僅詢問缺失或衝突的重大選擇。僅有儲存庫偏好設定不等於當前的答案或執行授權。
-
針對未解決的選擇使用深度選擇器。 如果未提供深度且仍有選擇，請詢問此次評估應進行的深度： 快速（express） — 每個選擇都採用其建議的預設值；僅詢問那些無法推導出預設值的問題（自由文字的必要問題）； 引導式（guided） — 僅詢問下方標記為高影響力的問題，以及自由文字的必要問題； 完整（full） — 詢問下方的每個問題。 如果儲存庫的
CONVENTIONS.md中記錄了Assessment depth:，則在詢問時將其預選為建議選項；記錄的深度絕不會被靜默套用。 否則，當請求在缺乏或無背景資訊的情況下送達時，建議使用 完整，當請求已完全明確時，建議使用 快速。 在任何問題上，操作者可以回答「從這裡開始使用預設值」或「深入探討」；立即遵循切換。 -
下方問題 一次問一個，每個問題都提供一個 建議選項 和一行理由；等待每個答案。
-
使用 結構化選擇（單選或多選）。如果主機提供了結構化的單選/多選問題工具，請使用它並標記建議選項；否則以純文字列出選項 A/B/C 並指出建議選項。僅在無法列舉出集合（例如目標陳述）的情況下使用 自由文字。
-
操作者決定。 在沒有答案的情況下，絕不要越過問題繼續前進，並且在沒有背景資訊的情況下被叫用時，絕不要猜測範圍。
問題（跳過請求中已回答的）：
- 目標 / 問題 — 自由文字（不可避免的開放式答案；在所有深度下都會詢問），如果尚未給出。
- 輸出 — 僅候選 ADR，或 ADR + 計畫項目。建議：ADR + 計畫項目。
- 分解深度 — 快速（頂級候選項目）或徹底（完整分解）。建議：先快速，按需擴展。
此處沒有問題被標記為高影響力 — 對於此技能來說，引導式執行的行為類似於快速執行。
此技能在您批准輪廓之前 不會寫入任何內容。
步驟 1 — 理解問題
如果尚未給出，則詢問目標 / 功能 / 問題。探討範圍邊界、約束條件以及對該儲存庫重要的監管 / 品質問題。在目標明確之前，不要開始分解。
步驟 2 — 分解
產生一個候選清單。對於每個候選 ADR：
- 提議的編號（下一個可用的、連續的）、工作標題、格式（如果儲存庫有區分是能力型還是技術型）。
- 一行範圍 — 它所捕獲的單一決策。
- 對其他候選項目或現有 ADR 的相依關係。
每個 ADR 一個決策。 如果一個候選項目捆綁了多個決策，則拆分它並說明原因。如果一個候選項目實際上是需要修訂的現有 ADR，則說明這一點，而不是提議一個新編號。
步驟 3 — 排序工作
提出一個計畫排序（哪些 plan/todo/ 項目，按什麼順序），並遵守相依關係邊緣。註明可以並行處理的工作（這對 agent-wave 技能來說是很有用的輸入）。
步驟 4 — 審查與移交
將完整集合作為可審查的輪廓（候選項目 + 相依關係 + 排序）呈現。接受編輯。還不要寫入任何內容。 一旦使用者批准，透過為每個候選項目呼叫 new-adr 技能，以及為每個排隊項目呼叫 new-plan 技能來建立它們 — 或者將批准的輪廓移交給這些技能。
護欄：如果問題過於模糊，無法在不憑空發明需求的情況下進行分解，則應說明情況並要求提供更多資訊，而不是產生臆測性的 ADR。
命名已同意的選項和剩餘的決策；單純討論不會寫入任何成品。
關閉報告
每次執行結束時，包括被阻止、失敗和停止的執行，都應以一個標題為 Status at a glance 的章節結束，該章節包含以下三個標籤：
- This run: 僅包含實際嘗試過的動作及其結果；引用每個驗證門控的確切輸出和退出碼，包括超時或中斷。
- Overall: 已實作、部分驗證、已驗證、被阻止、失敗或未知。通過子步驟並不代表整體通過；不完整或缺失的證據永遠不會變成成功。
- Yet to do: 每個剩餘的動作、未解決的發現、驗證、清理或所需的輸入。僅在整個任務可驗證完成時才寫入「無」；絕不能因為預算結束而省略工作。
常規進度消息不需要區塊。保持最終結果簡潔，並區分在 PR 上準備的工作與已確認交付的工作。