用途：在 /plan-run 下按 plan 逐步推進實作。主模型不下場，只負責讀狀態機、寫派工 prompt、抽查回報與裁決。角色分工：主模型處理裁決、HITL 與稀缺配額 MCP 呼叫；一般實作、研究交 Sonnet agent；複雜實作、深度審查、困難除錯交 Opus agent，派工明帶 model 參數，避免繼承主模型額度。
迴圈步驟：以 plan_runner.py start <plan> <step> --task-id=<id> 開始；該腳本在 /plan-run skill 的 repo checkout 底下，npx skills 快照不含 scripts/。派工 prompt 必含目標、動機、範圍、既有慣例、驗收條件、回報格式六格，大素材給檔案路徑。同 working tree 的 step 循序派，真正獨立且不改檔才並行。
抽查與完成：不信任自報，需 ls 確認檔案、grep 關鍵內容、比對 git log、親跑測試；通過才 complete，否則用 fail 指令退回。回收前 KB gate 順序固定：先將教訓寫入 KB（session 檔 _pending/，成熟者落 wiki/learned/），再用 complete --summary 寫入 state。summary 四項必寫（做了什麼、偏離 plan、副作用或限制、延後待辦），上限 500 字元，逐字證據放 --evidence。
派工型態微調：搜尋定位用 Explore、haiku；實作用 general-purpose、sonnet；重構批次改檔可降 haiku 並加 isolation: "worktree"；研究查證用 sonnet，來源優先序為官方文件、原始碼、issue/changelog、部落格；審查需 fresh context，開頭設定懷疑立場，結尾給 ACCEPT/REJECT。派工 prompt 要明寫親自執行、禁止再委派，並事先想好驗證方式。
限制與紀律：plan 每 step 標預期 agent 數、模型層級與 token；單 step 超預算兩倍即停下重估；review 按風險與不可逆性裁剪。已知坑包括 agent 再委派造成孤兒任務、視覺裁決不可用縮圖、jsdom 測不到 UI 回歸、subagent 回報需抽查、compaction 後素材可能遺失。稀缺配額 MCP 不下放 agent，由主對話單次呼叫後落檔再派工。未提供的細節暫未說明。