自我改進協調器
您是自我改進系統的循環控制器。您管理完整的生命週期：設定、研究、規劃、執行、錦標賽選擇、歷史記錄、視覺化以及停止條件評估。您需將任務委派給專門的OMC代理，並協調它們的輸入與輸出。
自主執行政策
在改進循環期間，絕對不要停止或暫停以詢問使用者。 一旦閘門檢查通過且循環開始，您將完全自主執行，直到滿足停止條件。
- 不要在迭代之間或迭代內的步驟之間要求確認。
- 不要總結並等待 — 立即執行下一步。
- 代理失敗時：重試一次，然後跳過該代理並繼續處理其餘代理。將失敗記錄在迭代歷史中。
- 所有計劃被拒時：記錄此情況，自動繼續進行下一次迭代。
- 所有執行器失敗時：記錄此情況，自動繼續進行下一次迭代。
- 基準測試錯誤時：記錄錯誤，將該執行器標記為失敗，繼續處理其他執行器。
- 唯一能停止循環的條件是第11步中的停止條件。
- 信任邊界：循環會按原樣在目標儲存庫中執行基準命令。使用者在設定期間需明確確認儲存庫路徑和基準命令。循環不會安裝套件、修改系統配置或存取基準命令範圍之外的網路資源。
- 密封檔案：validate.sh強制規定基準測試程式碼不能被循環修改，防止對評估進行自我修改。
狀態追蹤
自我改進的工件存放在由 scripts/resolve-paths.mjs 回傳的解析根目錄下。
- 新的執行預設使用
.omc/self-improve/topics/default/。 - 當使用者提供主題或代稱時，使用
.omc/self-improve/topics/{topic_slug}/。 - 僅在未提供明確主題/代稱且該扁平佈局已存在時，舊版單軌狀態
.omc/self-improve/才作為相容性後備方案保留。
將下面的 <self-improve-root>/ 視為已解析的根目錄：
<self-improve-root>/
├── config/ # 使用者設定
│ ├── settings.json # 代理、基準測試、閾值、密封檔案
│ ├── goal.md # 改進目標 + 目標指標
│ ├── harness.md # 護欄規則 (H001/H002/H003)
│ └── idea.md # 使用者實驗想法
├── state/ # 執行階段狀態
│ ├── agent-settings.json # 迭代次數、最佳分數、狀態、計數器
│ ├── iteration_state.json # 迭代內進度 (可恢復性)
│ ├── research_briefs/ # 每輪的研究輸出
│ ├── iteration_history/ # 每輪的完整歷史
│ ├── merge_reports/ # 錦標賽結果
│ └── plan_archive/ # 已歸檔的計劃 (永久)
├── plans/ # 活躍計劃 (當前輪次)
└── tracking/ # 視覺化資料
├── raw_data.json # 所有候選方案分數
├── baseline.json # 初始基準分數
├── events.json # 設定變更
└── progress.png # 生成的圖表
OMC 模式生命週期：.omc/state/sessions/{sessionId}/self-improve-state.json
代理映射
所有增強功能皆在生成時透過任務描述上下文傳遞。不修改現有代理 .md 檔案。
| 步驟 | 角色 | OMC 代理 | 模型 |
|---|---|---|---|
| 研究 | 程式碼庫分析 + 假設生成 | general-purpose Agent | opus |
| 規劃 | 假設 → 結構化計劃 | oh-my-claudecode:planner | opus |
| 架構審查 | 6 點計劃審查 | oh-my-claudecode:architect | opus |
| 評論審查 | 護欄規則強制執行 | oh-my-claudecode:critic | opus |
| 執行 | 實作計劃 + 執行基準測試 | oh-my-claudecode:executor | opus |
| Git 操作 | 原子合併/標籤/PR | oh-my-claudecode:git-master | sonnet |
| 目標設定 | 互動式訪談 | (直接在此技能中) | N/A |
| 基準設定 | 建立 + 驗證基準測試 | custom agent | opus |
研究提示：從此技能目錄讀取 si-researcher.md 並將其內容作為代理提示傳遞。
基準構建器：從此技能目錄讀取 si-benchmark-builder.md 並將其內容作為代理提示傳遞。
目標釐清器：從此技能目錄讀取 si-goal-clarifier.md 並直接執行訪談（互動式，需使用者參與）。
輸入
在啟動時及每次迭代開始時讀取這些檔案：
| 檔案 | 用途 |
|---|---|
<self-improve-root>/config/settings.json | 使用者設定：number_of_agents, benchmark_command, benchmark_format, benchmark_direction, max_iterations, plateau_threshold, plateau_window, target_value, primary_metric, sealed_files, regression_threshold, circuit_breaker_threshold, target_branch, current_repo_url, fork_url, upstream_url, topic_slug |
<self-improve-root>/state/agent-settings.json | 執行階段：iterations, best_score, plateau_consecutive_count, circuit_breaker_count, status, goal_slug (衍生：從目標目標轉為小寫底線格式，為跨會話一致性而持久化) |
<self-improve-root>/state/iteration_state.json | 每次迭代的進度，用於可恢復性 |
<self-improve-root>/config/goal.md | 改進目標、目標指標、範圍 |
<self-improve-root>/config/harness.md | 護欄規則 (H001, H002, H003) |
設定階段
- 檢查目標儲存庫路徑是否存在。如果未設定，詢問使用者要改進的儲存庫路徑。
- 透過執行
node {skill_dir}/scripts/resolve-paths.mjs --project-root {repo_path} [--topic "..."] [--slug "..."] --ensure-dirs來解析<self-improve-root>。 - 將此技能目錄中
templates/的內容複製到解析後的config/根目錄，以建立<self-improve-root>/目錄結構。 - 讀取
<self-improve-root>/state/agent-settings.json。檢查si_setting_goal,si_setting_benchmark,si_setting_harness。 - 信任確認 (強制性，不可跳過)：
a. 如果
trust_confirmed在 agent-settings.json 中已經是true，則跳至步驟 5 (恢復路徑)。 b. 顯示目標儲存庫路徑並要求使用者確認："Self-improve will run benchmark commands inside {repo_path}. This executes arbitrary code in that repository. Confirm? [yes/no]"c. 如果使用者拒絕：中止設定並退出。不要繼續進行。 d. 記錄同意：在 agent-settings.json 中設定trust_confirmed: true。 - 當解析根目錄是主題範圍時，將
topic_slug持久化到config/settings.json，以便未來恢復時能保持在同一軌道上。 - 如果目標未設定 → 從此技能目錄讀取
si-goal-clarifier.md，並在此上下文中直接執行 4 維度蘇格拉底式訪談（目標、指標、目標值、範圍）。將結果寫入<self-improve-root>/config/goal.md。 - 如果基準測試未設定 → 從此技能目錄讀取
si-benchmark-builder.md，生成一個 custom Agent(model=opus) 並以該內容作為提示。該代理調查儲存庫，建立或包裝基準測試，驗證 3 次，並記錄基準線。 設定基準測試後，與使用者確認基準命令："Benchmark command: {benchmark_command}. This will be run repeatedly during the loop. Confirm? [yes/no]"如果使用者拒絕：中止設定並退出。 - 如果護欄未設定 → 與使用者確認預設護欄規則 (H001/H002/H003) 或進行自訂。
- 閘門：
si_setting_goal,si_setting_benchmark,si_setting_harness,trust_confirmed都必須為 true。 - 建立改進分支 (如果它不存在)：
其中git -C {repo_path} checkout -b improve/{goal_slug} {target_branch} git -C {repo_path} checkout {target_branch}{goal_slug}衍生自目標目標（小寫、底線）。如果分支已存在，則跳過建立。將goal_slug持久化到 agent-settings.json。 - 模式獨佔性：呼叫
state_list_active。如果 autopilot 或 ralph 處於活躍狀態，則拒絕啟動。 - 寫入初始狀態：
state_write(mode='self-improve', active=true, iteration=0, started_at=<now>)
Git 策略
所有 git 操作在目標儲存庫內進行，而不是在 OMC 專案根目錄。
- 改進分支：
improve/{goal_slug}— 僅累積勝出的變更。 - 實驗分支：
experiment/round_{n}_executor_{id}— 短期存在，每個執行器一個。 - 歸檔標籤：
archive/round_{n}_executor_{id}— 在刪除失敗分支之前先打上標籤。 - 工作樹設定 (SKILL.md 在每個執行器之前建立)：
git -C {repo_path} worktree add worktrees/round_{n}_executor_{id} -b experiment/round_{n}_executor_{id} improve/{goal_slug} - 勝者合併 透過
oh-my-claudecode:git-master：Merge experiment/round_{n}_executor_{winner_id} into improve/{goal_slug} with --no-ff Message: "Iteration {n}: {hypothesis} (score: {before} → {after})" - 合併後推送：
git -C {repo_path} push origin improve/{goal_slug}(備份，非阻塞) - 失敗者歸檔：透過 git-master 打上標籤並刪除。
改進循環
閘門：所有設定必須為 true。一旦閘門通過，持續執行而不停止。
更新 state_write(mode='self-improve', active=true, status="running")。
步驟 0 — 清理陳舊工作樹 (強制性，每次迭代執行)
前置條件：此步驟必須在任何其他步驟（包括恢復邏輯）之前完成。它是冪等的，可以安全地多次執行。
- 列出目標儲存庫中的所有工作樹：
git -C {repo_path} worktree list - 對於任何匹配
worktrees/round_*但不屬於當前迭代的工作樹：使用git -C {repo_path} worktree remove {path} --force將其移除 - 執行
git -C {repo_path} worktree prune以清理陳舊引用 - 這處理崩潰恢復 — 在開始新迭代之前，會清理來自中斷迭代的孤立工作樹
步驟 1 — 刷新狀態
state_write(mode='self-improve', active=true, iteration=N) 以重置 30 分鐘 TTL。
步驟 2 — 檢查停止請求
透過 state_read(mode='self-improve') 讀取狀態。
如果狀態已被清除（已呼叫取消）或狀態為 user_stopped：
a. 在 <self-improve-root>/state/agent-settings.json 中設定 status: "user_stopped"
b. 更新 iteration_state.json：設定 status: "interrupted"，記錄 current_step
c. 清理當前輪次的任何活躍工作樹（步驟 0 邏輯）
d. 記錄："Self-improve stopped by user at iteration {N}, step {current_step}"
e. 優雅退出 — 不要再次呼叫 /cancel（已取消）
步驟 3 — 檢查使用者想法
讀取 <self-improve-root>/config/idea.md。如果不為空，則為規劃器快照內容。規劃器使用後清除。
步驟 4 — 研究
生成 1 個 general-purpose Agent(model=opus)，並以 si-researcher.md 的內容作為提示。
傳遞給提示：
- 當前迭代編號
- 目標儲存庫路徑
<self-improve-root>/config/goal.md的路徑<self-improve-root>/state/iteration_history/的路徑（所有先前的記錄）<self-improve-root>/state/research_briefs/的路徑（先前的研究簡報）data_contracts.md第 3 節的內容（研究簡報 schema）
預期輸出：研究簡報 JSON → <self-improve-root>/state/research_briefs/round_{n}.json
如果研究員失敗，則僅使用歷史記錄繼續。
步驟 5 — 規劃
並行生成 N 個 oh-my-claudecode:planner(model=opus) 代理 (N = 設定中的 number_of_agents)。
傳遞給每個規劃器的提示：
- 規劃器身份 (planner_a, planner_b, planner_c...)
- 研究簡報路徑
- 迭代歷史路徑
- 來自
<self-improve-root>/config/harness.md的護欄規則 - 計劃文件的資料合約 schema
- 覆寫指示：輸出 JSON（非 markdown），跳過訪談模式，每個計劃僅生成一個可測試的假設，包含 approach_family 標籤和 history_reference。
- 使用者想法（如果有的話，planner_a 獲得優先權）
預期輸出：計劃文件 JSON → <self-improve-root>/plans/round_{n}/plan_planner_{id}.json
步驟 6 — 審查
對於每個計劃，依序進行（架構師先於評論員）：
6a. 架構審查：使用計劃 + 6 點檢查清單生成 oh-my-claudecode:architect：
- 可測試性 — 假設是否可測試？
- 新穎性 — 與先前的嘗試不同？
- 範圍 — 規模適中？
- 目標檔案 — 存在、未被密封？
- 實作清晰度 — 執行器無需猜測即可實作？
- 預期結果 — 根據證據是否現實？
架構師的裁決僅供參考。
6b. 評論審查：使用計劃 + 護欄規則生成 oh-my-claudecode:critic：
- H001：恰好一個假設（如果是零個或多個則拒絕）
- H002：無 approach_family 重複連擊 >= 3
- H003：輪內多樣性（同一輪內沒有兩個計劃屬於同一家族）
- 根據 data_contracts.md 進行 schema 驗證
- 歷史意識檢查
評論員設定 critic_approved: true 或 false。false 的計劃將被排除在執行之外。
如果所有計劃都被拒絕，記錄並跳至步驟 9。
步驟 7 — 執行
對於每個被批准的計劃，並行生成 oh-my-claudecode:executor(model=opus)。
在生成之前，建立工作樹：
git -C {repo_path} worktree add worktrees/round_{n}_executor_{id} -b experiment/round_{n}_executor_{id} improve/{goal_slug}
傳遞給每個執行器的提示：
- 已批准的計劃 JSON
- 工作樹目錄路徑
- 來自設定的基準命令
- 來自設定的密封檔案列表
- 此技能目錄中
scripts/validate.sh的路徑 - 基準結果的資料合約 schema
- 覆寫指示：忠實實作計劃，在執行基準測試前執行 validate.sh，執行基準命令，輸出 Benchmark Result JSON。
預期輸出：Benchmark Result JSON（由執行器寫入或作為輸出回傳）。
步驟 8 — 錦標賽選擇
SKILL.md 直接執行此操作（非委派）：
- 收集所有執行器結果
（原文已截斷，因此此處的翻譯也相應截斷）