<Use_When>
- 使用者在實作前想要進行規劃 — 「規劃這個」、「規劃一下」、「我們來規劃」
- 使用者想要針對模糊的想法進行結構化需求收集
- 使用者想要審查現有計畫 — 「審查這個計畫」、「
--review」 - 使用者想要針對計畫取得多方共識 — 「
--consensus」、「ralplan」 - 任務廣泛或模糊，需要在撰寫任何程式碼之前先界定範圍 </Use_When>
<Do_Not_Use_When>
- 使用者想要自主的端到端執行 — 請改用
autopilot - 使用者想要在任務明確的情況下立即開始編碼 — 請改用
ralph或委派給執行者 - 使用者提出可以直接回答的簡單問題 — 直接回答即可
- 任務是單一且範圍明確的修復 — 請改用執行技能，不要透過此規劃模組執行 </Do_Not_Use_When>
<Why_This_Exists> 在不了解需求的情況下直接跳入編碼，會導致重工、範圍蔓延以及遺漏邊界情況。Plan 提供結構化的需求收集、專家分析以及受品質把關的計畫，讓執行能建立在穩固的基礎上。共識模式則為高風險專案增加了多方驗證。 </Why_This_Exists>
<Execution_Policy>
- 根據請求的具體程度自動偵測面談模式或直接模式
- 面談期間一次只問一個問題 — 絕不一次提出多個問題
- 在向使用者提問之前，先透過
exploreagent 收集程式碼庫的事實 - 計畫必須達到品質標準：80% 以上的聲明需引用檔案/行號，90% 以上的標準需可測試
- 共識模式預設為全自動執行；加入
--interactive可在草稿審查與最終核准步驟中啟用使用者提示 - 共識模式預設使用 RALPLAN-DR 簡短模式；當請求明確表示高風險（驗證/安全、資料遷移、破壞性/不可逆變更、生產事故、合規/PII、公開 API 中斷）時，切換為深思模式，或使用
--deliberate參數 - 規劃/執行邊界： 規劃模式僅能檢查上下文並產出計畫/規格/提案。它們必須將產出標記為
pending approval，除非使用者已在當前回合或透過結構化核准 UI 明確選擇執行。在獲得明確的執行核准前，規劃模式不得執行變動性的 shell 命令、編輯原始檔、提交、推送、開啟 PR、呼叫執行技能或委派實作任務。 - 目標工作流程邊界： 當計畫比較 Claude Code
/goal、Ralph、Team 或僅產出物的 Ultragoal 時，需明確識別一個主要循環權威，並使用確定性的衝突策略refuse、adopt_existing和artifact_only，而非非確定性的警告處理。/goal的事實必須僅引用 Claude Code/Anthropic 來源（Claude Code/goal文件：https://code.claude.com/docs/en/goal；Anthropic Claude Code 更新日誌：https://raw.githubusercontent.com/anthropics/claude-code/main/CHANGELOG.md），且計畫不得聲稱/goal評估器能獨立執行命令或讀取檔案；在任何完成聲明之前，需要呈現已浮現的證據。 - 目標工作流程文件目標： 針對使用者面對的比較，請確保範例與
docs/shared/mode-selection-guide.md#goal-oriented-workflow-selection和docs/REFERENCE.md#goal-workflow-ux-goal-ralph-team-ultragoal保持一致。 </Execution_Policy>
模式選擇
| 模式 | 觸發條件 | 行為 |
|---|---|---|
| 面談模式 | 預設用於廣泛請求 | 互動式需求收集 |
| 直接模式 | --direct，或詳細請求 | 跳過面談，直接產生計畫 |
| 共識模式 | --consensus，"ralplan" | Planner -> Architect -> Critic 循環，透過 RALPLAN-DR 結構化討論達成共識（預設為簡短模式，高風險情況使用 --deliberate）；加入 --interactive 可在草稿與核准步驟中啟用使用者提示 |
| 審查模式 | --review，"review this plan" | Critic 對現有計畫進行評估 |
面談模式（廣泛/模糊請求）
- 分類請求：廣泛請求（模糊的動詞、未指定特定檔案、觸及 3 個以上領域）觸發面談模式
- 提出一個重點問題：使用
AskUserQuestion詢問偏好、範圍與限制 - 先收集程式碼庫事實：在詢問「你的程式碼使用什麼模式？」之前，先啟動一個
exploreagent 來找出答案，然後再提出有根據的後續問題 - 根據答案建構：每個問題都建立在先前的答案之上
- 諮詢分析師 (Opus) 以找出隱藏需求、邊界情況與風險
- 當使用者表示準備就緒時建立計畫：例如「建立計畫」、「我準備好了」、「把它變成一個工作計畫」
直接模式（詳細請求）
- 快速分析：可選的簡要分析師諮詢
- 建立計畫：立即產生全面的工作計畫
- 審查（選擇性）：如有要求，進行 Critic 審查
共識模式（--consensus / "ralplan"）
RALPLAN-DR 模式：簡短模式（預設，有邊界的結構）與深思模式（用於 --deliberate 或明確的高風險請求）。兩種模式都保持相同的 Planner -> Architect -> Critic 順序以及相同的 AskUserQuestion 閘門。
提供者覆蓋（在提供者 CLI 已安裝時支援）：
--architect codex— 將 Claude Architect 階段替換為omc ask codex --agent-prompt architect "..."以進行偏實作的架構審查--critic codex— 將 Claude Critic 階段替換為omc ask codex --agent-prompt critic "..."以在執行前進行外部審查- 如果請求的提供者不可用，簡短說明並繼續使用該階段的預設 Claude Architect/Critic 步驟
狀態生命週期：持久模式的停止鉤子使用 ralplan-state.json 來強制在共識循環期間繼續執行。此技能必須管理此狀態：
- 進入時：在步驟 1 之前呼叫
state_write(mode="ralplan", active=true, session_id=<current_session_id>) - 移交執行時（核准 -> ralph/team）：呼叫
state_write(mode="ralplan", active=false, session_id=<current_session_id>)。請勿在此使用state_clear—state_clear會寫入一個 30 秒的取消訊號，這會停用所有模式的停止鉤子強制執行，使新啟動的執行模式失去保護。 - 真正終止退出時（拒絕、非互動式計畫輸出、錯誤/中止）：呼叫
state_clear(mode="ralplan", session_id=<current_session_id>)— 後面不會接著執行模式，因此取消訊號視窗是無害的。 - 請勿在 Critic 核准或最大疊代次數提示等中間步驟中清除，因為使用者仍可能選擇「請求變更」。
如果未清理，停止鉤子會持續封鎖所有後續的停止，並顯示 [RALPLAN - CONSENSUS PLANNING] 強化訊息，即使共識工作流程已完成。始終傳遞 session_id 以避免清除其他並行會話的狀態。
-
Planner 建立初始計畫，以及在 Architect 審查前的精簡 RALPLAN-DR 摘要。摘要必須包含：
- 原則 (3-5 條)
- 決策驅動因素 (前 3 項)
- 可行選項 (>=2 個)，附帶每個選項的限制性優缺點
- 如果只剩下一個可行選項，則需提供被拒絕替代方案的明確無效化理由
- 在深思模式中：一個預先檢討（3 個失敗情景）和一個涵蓋單元 / 整合 / 端到端 / 可觀測性的擴充測試計畫
-
使用者回饋 (僅限 --interactive)：如果使用
--interactive執行，必須使用AskUserQuestion呈現草稿計畫以及 RALPLAN-DR 原則 / 決策驅動因素 / 選項摘要以進行早期方向校準，並提供以下選項：- 進行審查 — 發送給 Architect 和 Critic 進行評估
- 請求變更 — 融入使用者回饋後返回步驟 1
- 跳過審查 — 直接進入最終核准（步驟 7）
如果不是使用
--interactive執行，則自動進行審查（步驟 3）。
-
Architect 使用
Task(subagent_type="oh-my-claudecode:architect", ...)審查架構穩健性。Architect 審查必須包含：針對偏好的選項提出最強的鋼鐵人反論（反面論點）、至少一個有意義的取捨張力，以及（如果可能）一個綜合路徑。在深思模式中，Architect 應明確標記違反原則的情況。等待此步驟完成後再繼續步驟 4。 請勿並行執行步驟 3 和 4。Architect 必須評估 Planner 在步驟 1 中產生的相同固定計畫快照，且不得對其進行變更；Architect 的輸出不得傳遞給 Critic。 -
Critic 使用
Task(subagent_type="oh-my-claudecode:critic", ...)根據品質標準進行評估。Critic 必須驗證原則與選項的一致性、替代方案的公平探索、風險緩解的清晰度、可測試的驗收標準以及具體的驗證步驟。Critic 必須明確拒絕膚淺的替代方案、驅動因素矛盾、模糊的風險或薄弱的驗證。在深思模式中，Critic 必須拒絕遺漏/薄弱的預先檢討或遺漏/薄弱的擴充測試計畫。僅在步驟 3 完成後執行。Critic 必須獨立評估相同的固定計畫快照，作為一個獨立、分別等待的 Task 呼叫；Critic 不得消費或接收 Architect 的審查。對一個固定計畫快照進行獨立的順序審查。 Architect 和 Critic 各自審查 Planner 在步驟 1 中產生的相同固定計畫快照，且任一審查都不會對其進行變更。Architect 的輸出不得傳遞給 Critic。Architect 和 Critic 必須作為獨立、分別等待的 Task 呼叫順序執行 — 絕不並行 — 且 Critic Task 不得在 Architect Task 完成且其結果被等待之前發出。Critic 不得消費或接收 Architect 的審查。Architect 和 Critic 的結果必須僅由 Planner 在修訂或改進綜合期間合併，且僅在兩個審查都完成之後。
-
重新審查循環（最多 5 次疊代）：如果 Critic 拒絕，執行此封閉循環： a. 收集所有來自 Architect + Critic 的拒絕回饋（僅限 Planner 綜合：Architect 和 Critic 的結果必須僅由 Planner 合併，且僅在兩個審查都完成之後）。 b. 將回饋傳遞給 Planner 以產出修訂後的計畫 c. 返回步驟 3 — Architect 審查修訂後的計畫 d. 返回步驟 4 — Critic 評估修訂後的計畫 e. 重複直到 Critic 核准或達到最多 5 次疊代 f. 如果達到最大疊代次數仍未核准，則透過
AskUserQuestion向使用者呈現最佳版本，並備註專家共識未能達成 -
套用改進：當審查者核准但附帶改進建議時，在繼續之前將所有接受的改進合併到計畫檔案中。最終共識輸出必須包含一個 ADR 章節，內容包括：決策、驅動因素、考慮過的替代方案、選擇原因、後果、後續事項。具體來說： a. 收集所有來自 Architect 和 Critic 回應的改進建議 b. 對建議進行去重和分類 c. 使用接受的改進更新位於
.omc/plans/的計畫檔案（加入遺漏的細節、優化步驟、強化驗收標準、更新 ADR 等） d. 在計畫末尾的簡短變更日誌章節中記錄已套用的改進 -
在 Critic 核准（且改進已套用）時：除非已獲取明確的執行核准，否則將計畫狀態標記為
pending approval。(僅限 --interactive) 如果使用--interactive執行，使用AskUserQuestion呈現計畫，並提供以下選項：- 透過團隊核准執行（推薦）— 明確選擇透過協調的並行團隊 agent（
/team）繼續執行。Team 是自 v4.1.7 以來的標準協調介面。 - 透過 ralph 核准執行 — 明確選擇透過帶驗證的 Ralph 持續性繼續執行
- 先壓縮再返回以取得執行核准 — 明確選擇先壓縮上下文視窗（當規劃後上下文較大時建議使用），然後在已儲存的待核准計畫處停止，並在啟動執行前再次詢問
- 請求變更 — 融入使用者回饋後返回步驟 1
- 拒絕 — 完全拋棄該計畫
如果不是使用
--interactive執行，輸出標記為pending approval的最終計畫，呼叫state_clear(mode="ralplan", session_id=<current_session_id>)，然後停止。請勿自動執行。
- 透過團隊核准執行（推薦）— 明確選擇透過協調的並行團隊 agent（
-
(僅限 --interactive) 使用者透過結構化的
AskUserQuestionUI 進行選擇（絕不以純文字要求核准）。如果使用者選擇拒絕，呼叫state_clear(mode="ralplan", session_id=<current_session_id>)並停止。 -
在使用者核准後： a. 如果選擇「透過團隊核准執行」，則使用
Task(subagent_type="oh-my-claudecode:team", ...)啟動協調的團隊執行。團隊 Agent 會將工作分解為並行任務、分配實作、在需要時發起審查，並合併最終結果。 b. 如果選擇「透過 ralph 核准執行」，則將計畫移交給 Ralph 進行逐步的、經驗證的執行。 c. 如果選擇「先壓縮再返回以取得執行核准」，則壓縮上下文，將計畫保存為pending approval，呼叫state_clear(mode="ralplan", session_id=<current_session_id>)，然後停止並提示後續執行步驟。 d. 將狀態標記為approved。 -
在向使用者呈現的最終計畫輸出中，始終包含一個決定記錄，記錄所做的關鍵選擇以及替代方案被拒絕的原因。對於共識模式，ADR 應特別詳細，記錄選項、權衡和替代方案。
審查模式（--review / "review this plan"）
- 要求使用者提供現有計畫（如果需要）
- 使用 Critic 評估其品質標準：完整性、可測試性、風險緩解、時間估計
- 呈現結構化審查，內容包括：優點、疑慮/風險、改進建議、整體評級（通過/有條件通過/失敗）
- 如果評級為「失敗」，提供可付諸行動的具體改進建議
品質標準
審查和產出計畫時，根據以下標準進行評估：
- 完整性：涵蓋所有領域？是否有明顯的漏洞？
- 可測試性：接受標準是否具體、可衡量且可驗證？
- 風險緩解：風險是否被明確識別並有具體的備案計畫？
- 時間估計：時間是否基於過往經驗且有明確的假設？
- 替代方案：是否公平地考慮了多種方法？
- 邊界情況：是否處理了邊緣情況和錯誤路徑？
- 依賴關係：外部依賴關係是否被識別並說明？
計畫產出格式
計畫應包含：
- 目標：清晰的問題陳述和成功標準
- 範圍：包含與排除事項
- 方法/途徑：所選解決方案的描述（含替代方案）
- 步驟：按時間順序排列的行動項目，附有時間估計
- 風險：已識別的風險與緩解策略
- 接受標準：可測試的通過/失敗條件
- 依賴關係：先決條件和所需資源