<Use_When>
- 使用者想要從一個想法到可運作程式碼的端到端自動執行
- 使用者說出「autopilot」、「auto pilot」、「autonomous」、「build me」、「create me」、「make me」、「full auto」、「handle it all」或「I want a/an...」
- 任務需要多個階段：規劃、編碼、測試和驗證
- 使用者希望放手執行，並願意讓系統運行至完成 </Use_When>
<Do_Not_Use_When>
- 使用者想要探索選項或腦力激盪 —— 請改用
plan技能 - 使用者說「just explain」、「draft only」或「what would you suggest」 —— 以對話方式回應
- 使用者想要單一的、聚焦的程式碼變更 —— 請改用
ralph或委派給執行代理 - 使用者想要審查或評論現有計劃 —— 請使用
plan --review - 任務是一個快速修復或小錯誤 —— 直接委派給執行代理 </Do_Not_Use_When>
<Why_This_Exists> 大多數非瑣碎的軟體任務需要協調的階段：理解需求、設計解決方案、平行實作、測試和驗證品質。Autopilot 自動編排所有這些階段，讓使用者只需描述他們想要的東西，就能獲得可運作的程式碼，而無需管理每個步驟。 </Why_This_Exists>
<Execution_Policy>
- 每個階段必須在下一階段開始前完成
- 在可能的情況下，階段內使用平行執行（階段 2 和階段 4）
- QA 循環最多重複 5 次；如果相同錯誤持續出現 3 次，則停止並報告根本問題
- 驗證需要所有審查者的批准；被拒絕的項目會修復後重新驗證
- 隨時可使用
/oh-my-claudecode:cancel取消；進度會保留以供恢復 </Execution_Policy>
<Workflow_Profiles>
命名階段設定檔 (v1)
僅可透過 /autopilot --workflow <name> <task> 選擇已設定的設定檔。設定檔是 autopilot 擁有的階段排程，而非指令、模式、外掛、檔案名稱或獨立的狀態身份標識。在沒有 --workflow 的情況下，autopilot 保留其傳統生命週期和行為。
命名工作流程設定檔在 v1 中需要配備 flock 工具的 Linux 環境，因為其對話記錄證據邊界使用了 Linux 的無跟隨檔案描述子遍歷，而其可回復的可變鎖定則使用了核心的建議性鎖定。不支援的環境會在狀態變異前拒絕明確的 --workflow 啟用；請改用傳統的 autopilot。
設定檔在專案或使用者的 JSONC 檔案中配置為 autopilot.workflows.<slug>。每個 v1 設定檔都必須完全包含 version: 1 和 stages；不接受其他設定檔鍵值。唯一允許的階段序列為：
{
"autopilot": {
"workflows": {
"plan-build-qa": {
"version": 1,
"stages": ["ralplan", "execution", "qa"]
}
}
}
}
[ralplan, execution]
[ralplan, execution, ralph]
[ralplan, execution, qa]
[ralplan, execution, ralph, qa]
ralplan 建立 execution 所使用的計劃；execution 建立 ralph 和 qa 所需的已實作工作區。因此，省略或重新排序的必要條件、重複的階段，以及非內建的階段都是無效的。設定檔名稱使用 ^[a-z][a-z0-9-]{0,62}$ 格式，僅作為經過驗證的中繼資料，且不能與內建階段、autopilot/模式名稱或已棄用的別名衝突。
使用者和專案配置來源在組合前會各自驗證。不同名稱可以共存；同名專案設定檔會完全取代使用者設定檔，而不是進行深度合併。環境配置不能定義或取代設定檔。
成功選擇後，autopilot 會以不可變的標準化描述元及僅限所選階段的管線追蹤，原子性地建立其現有的工作階段範圍狀態。該描述元包含工作流程名稱、設定檔版本、標準化階段以及一個確定性的 SHA-256 設定檔雜湊；它排除了任務文字和可變的進度。恢復和停止操作會驗證該雜湊，並在不重新載入配置或發出階段提示的情況下拒絕不匹配的情況。取消、恢復、清理、狀態檢查、HUD 和停止繼續操作仍由 autopilot 擁有。
已安裝的外掛和獨立安裝的停止鉤子，僅在該階段持續存在的啟用對話記錄邊界之後，出現該活躍階段的授權助手完成記錄時才會前進。它們將證據綁定到擁有者工作階段以及有界的、非符號連結的對話記錄；拒絕使用者/工具/本地指令輸出以及過時或錯誤階段的證據；並使用先比較後寫入的追蹤更新，以便重複或並發的停止事件恰好前進一次。公開狀態、HUD 和停止輸出僅顯示安全的工作流程中繼資料和進度，絕不顯示任務、描述元內部細節、對話記錄引用、偏移量或記錄雜湊。
V1 延期事項
V1 不支援 stageModels、模型路由、提供者或角色選擇；內聯/無衍生執行；動態指令、模式或狀態檔案；任意階段、提示、外掛、分支、迴圈、DAG 或回呼；或由環境定義的設定檔定義。另外，自訂技能內聯陣列 frontmatter 解析器不匹配問題也已延期。
</Workflow_Profiles>
-
階段 1 - 規劃：根據規格建立實作計劃
- 如果 ralplan 共識計劃存在：跳過 —— 已在 3 階段管線中完成
- 架構師（Opus）：建立計劃（直接模式，無訪談）
- 評論者（Opus）：驗證計劃
- 輸出：
.omc/plans/autopilot-impl.md
-
階段 2 - 執行：使用執行代理搭配 Ralph 持久化來實作計劃
- 執行器（Haiku）：簡單任務
- 執行器（Sonnet）：標準任務
- 執行器（Opus）：複雜任務
- 獨立任務平行執行
-
階段 3 - QA：循環直到所有測試通過
- 建構、檢查、測試、修復失敗
- 最多重複 5 次循環
- 如果相同錯誤重複出現 3 次則提前停止（表示根本性問題）
-
階段 4 - 驗證：平行進行多角度審查
- 架構師：功能完整性
- 安全審查員：弱點檢查
- 程式碼審查員：品質審查
- 所有人都必須批准；拒絕時修復並重新驗證
-
階段 5 - 清理：成功完成時刪除所有狀態檔案
- 移除
.omc/state/autopilot-state.json、ralph-state.json（以及如果存在舊版副本，則移除過時的ultraqa-state.json/ultrawork-state.json） - 執行
/oh-my-claudecode:cancel以乾淨退出
- 移除
<Tool_Usage>
- 使用
Task(subagent_type="oh-my-claudecode:architect", ...)進行階段 4 的架構驗證 - 使用
Task(subagent_type="oh-my-claudecode:security-reviewer", ...)進行階段 4 的安全審查 - 使用
Task(subagent_type="oh-my-claudecode:code-reviewer", ...)進行階段 4 的品質審查 - 代理形成自己的分析並返回；然後 LEAD 自行衍生任何交叉驗證代理。除非檢查了 Claude Code 深度設定，否則不要依賴子代理進一步衍生子代理：Claude Code 2.1.217–2.1.218 版本將
CLAUDE_CODE_MAX_SUBAGENT_SPAWN_DEPTH預設為 1，而 2.1.219+ 版本則預設為 3。除非是有意的嵌套委派且受到執行時期支援，否則請在 LEAD 層級進行交叉驗證。 - 絕不要阻塞外部工具；如果委派失敗，則繼續使用可用的代理 </Tool_Usage>
<Escalation_And_Stop_Conditions>
- 當相同的 QA 錯誤連續出現 3 次循環時停止並報告（根本性問題，需要人工介入）
- 當驗證在 3 輪重新驗證後持續失敗時停止並報告
- 當使用者說「stop」、「cancel」或「abort」時停止
- 如果需求過於模糊，擴展後產生的規格不明確，建議重新導向到
/deep-interview進行蘇格拉底式釐清，或暫停並在使用者繼續前要求釐清 </Escalation_And_Stop_Conditions>
<Final_Checklist>
- 所有 5 個階段已完成（擴展、規劃、執行、QA、驗證）
- 所有驗證者在階段 4 中批准
- 測試通過（透過最新的測試執行輸出驗證）
- 建構成功（透過最新的建構輸出驗證）
- 狀態檔案已清理
- 已通知使用者完成，並附上所建構內容的摘要 </Final_Checklist>
平行工作階段注意事項
- 多儲存庫工作區錨點： 在父目錄放置一個
.omc-workspace標記，以便跨子儲存庫的多個工作階段共享同一個.omc/。解析順序：OMC_STATE_DIR > .omc-workspace > git > cwd。請參閱docs/REFERENCE.md。 - 工作階段 ID 來源：
OMC_SESSION_ID環境變數在 CLI 上下文中優先；鉤子負載data.session_id在鉤子上下文中優先。 - 計劃 ID（如適用）： Autopilot 狀態是工作階段範圍的。同一工作區中的兩個 autopilot 需要不同的工作階段 ID。
- 平行執行判定： 支援（工作階段範圍狀態）
在 .claude/omc.jsonc（專案）或 ~/.config/claude-omc/config.jsonc（使用者）中的可選設定：
{
"autopilot": {
"maxIterations": 10,
"maxQaCycles": 5,
"maxValidationRounds": 3,
"pauseAfterExpansion": false,
"pauseAfterPlanning": false,
"skipQa": false,
"skipValidation": false,
"execution": "solo"
}
}
要透過 tmux CLI 團隊執行時期執行 autopilot 實作，並偏好 Cursor 執行器工作者：
{
"autopilot": {
"execution": "team",
"team": { "agentTypes": ["cursor"] }
}
}
使用該配置後，執行階段必須透過以下方式啟動執行器風格的工作：
omc team 1:cursor "<implementation task>"
或 Claude Code 斜線相容性介面：
/omc-teams 1:cursor "<implementation task>"
限制：
- Cursor 工作者支援實作和審查者風格的團隊角色。
critic、code-reviewer、security-reviewer和test-engineer工作者必須發出團隊領導者所使用的結構化判定檔案；最終批准仍是領導工作階段的責任。 - Cursor 需要安裝並驗證
cursor-agentCLI。如果cursor-agent不可用，請報告該設定需求，而不是默默地回退到僅限 Claude 的執行。
恢復
如果 autopilot 被取消或失敗，請再次執行 /oh-my-claudecode:autopilot 以從停止處恢復。
輸入最佳實務
- 具體說明領域 —— 用 "bookstore" 而非 "store"
- 提及關鍵功能 —— "with CRUD"、"with authentication"
- 指定限制條件 —— "using TypeScript"、"with PostgreSQL"
- 讓它運行 —— 除非真的需要，否則避免中斷
疑難排除
卡在某個階段？ 檢查 TODO 列表中的阻塞任務，檢視 .omc/autopilot-state.json，或取消並恢復。
QA 循環耗盡？ 同一錯誤出現 3 次表示根本性問題。檢視錯誤模式；可能需要人工介入。
驗證持續失敗？ 檢視具體問題。需求可能過於模糊 —— 取消並提供更多細節。
深度訪談整合
當 autopilot 以模糊輸入被呼叫時，階段 0 可以重新導向到 /deep-interview 進行蘇格拉底式釐清：
使用者：「autopilot build me something cool」
Autopilot：「您的請求過於開放。您想先進行一次深度訪談嗎？」
[是的，先訪談（推薦）] [不，直接擴展]
如果深度訪談規格已存在於 .omc/specs/deep-interview-*.md，autopilot 會直接將其用作階段 0 的輸出（該規格已經過數學驗證其清晰度）。
3 階段管線：deep-interview → ralplan → autopilot
建議的完整管線串聯了三個品質關卡：
/deep-interview "模糊想法"
→ 蘇格拉底式問答 → 規格（模糊度 ≤ 20%）
→ /ralplan
→ 共識計劃（規劃者/架構師/評論者）
→ /autopilot（從階段 2 執行開始）
→ 完全驗證的程式碼