任務拆分器 — 最便宜的正確執行
目標：以 在符合品質前提下，總成本最低 的方式完成主要任務。 兩個槓桿：(1) 將每個工作片段路由到最便宜的勝任層級，(2) 透過將相同層級的工作批次化到單一執行緒，來分攤每個子代理的冷啟動上下文成本。
在評分前，請先閱讀 references/routing-rubric.md；在撰寫任何批次提示前，請先閱讀 references/batch-brief-template.md。
嚴格規則
- T0 工作絕不產生代理。 確定性步驟（install、mkdir、mv、設定值、執行產生器）在主執行緒中內聯執行。一個冷啟動子代理的成本比命令還高。
- 對於便宜層級，絕不使用
subagent_type: "fork"。 Fork 永遠在父模型上執行，且忽略model。請使用general-purpose（或唯讀搜尋使用Explore），並明確指定model和effort。 - 此技能明確授權設定
effort，在其進行的每個 Agent 呼叫上，使用層級表。始終同時傳遞model和effort。 - 由腳本驗證，而非模型。 測試、lint、型別檢查和建置由主執行緒執行。不要花費模型呼叫來審查腳本能檢查的程式碼。
- 僅升級失敗的子任務，一層，一次。 一次升級後，停止並詢問使用者。
- 永遠不要將編輯同一檔案的兩個子任務批次到同一波次中的不同批次中。
層級表（預設值 — 使用路由日誌進行校準）
| 層級 | 分數 | 執行方式 | 典型工作 |
|---|---|---|---|
| T0 | 0 | 主執行緒，內聯 shell | 安裝依賴項、搭建目錄、重新命名、設定環境/設定值 |
| T1 | 1–3 | model: haiku, effort: low | 遵循現有模式的樣板、複製編輯、簡單的 CRUD 接線、文件、測試用具 |
| T2 | 4–6 | model: sonnet, effort: medium | 一般功能程式碼、元件、端點、遵循現有模式的測試 |
| T3 | 7–8 | model: sonnet, effort: high | 多檔案邏輯、狀態管理、整合、棘手錯誤、身份驗證/付款/安全性 |
| T4 | 9–10 | model: opus, effort: high | 架構、跨領域設計、資料模型、困難除錯、性能/並發 |
預覽的相對成本權重：haiku = 1, sonnet = 3, opus = 5； 努力倍數 low = 1, medium = 1.5, high = 2.5。T0 = ~0。
工作流程
階段 0 — 擷取與持久化
- 用 ≤10 行重新說明主要任務：目標、限制、驗收標準、技術棧、範圍外。
- 推導出一個 slug。在
<project>/.claude/task-splitter/中尋找現有帳本（ls .claude/task-splitter/ 2>/dev/null）。如果有一個匹配此任務且包含未完成子任務 → 從它恢復（跳到其工作尚未完成的第一個階段）。 - 否則，從
templates/split-ledger.md建立<project>/.claude/task-splitter/<YYYY-MM-DD>-<slug>.md，並填寫「Context」部分。在每個階段後更新它。在計劃模式下，如果不允許在計劃檔案之外寫入檔案，則將帳本內容放入計劃檔案中的## Ledger標題下，並在批准後的第一個 T0 步驟中寫入實際檔案。
階段 1 — 輕量探勘
僅讀取拆分所需的內容：清單（package.json, pyproject 等）、進入點、功能觸及的檔案、可重複使用的現有工具。如果需要廣泛搜尋，請使用一個 Explore 代理，搭配 model: haiku、effort: low，並只要求路徑和一行結論。將可重複使用的工具和確切檔案路徑記錄在帳本中 — 它們將成為上下文包，防止便宜代理重新探勘。
階段 2 — 拆分
將工作分解為原子性子任務。每個子任務具有：
id (S1, S2…)、goal（一句話）、files（確切路徑，新檔案或現有檔案）、
depends_on (id)、done_check（一個命令，如 pnpm test foo 或一個精確標準）、
type（短標籤：install, scaffold, component, endpoint, test, migration, refactor, config, docs, debug, design…）。
原子性 = 一個代理可以在不做屬於另一個子任務的決策的情況下完成它。
將設計決策提取到它們自己的早期子任務中（通常是 T4），以便後續子任務是機械式的且便宜。
階段 3 — 評分與路由
使用 references/routing-rubric.md 中的 5 維度評分標準（模糊性、推理深度、影響範圍、所需上下文、新穎性；各 0–2 分）為每個子任務評分，套用覆寫規則，然後將分數映射到層級。
然後檢查 ~/.claude/task-splitter/routing-log.md（如果存在）：如果一個 type 在最近 3 次執行中，有 ≥2 次在特定層級被升級，則從高一層開始；如果它在你選擇的層級低一層時，連續 3 次以上首次通過，則考慮降一層。
階段 4 — 批次
- 建置依賴波次：波次 1 = 沒有未滿足依賴項的子任務；波次 N = 其所有依賴項都在前面波次中的子任務。
- 在每個波次內，按
(model, effort)分組，然後按程式碼區域（相同功能資料夾/模組）分組，以便一個代理一次性載入相關檔案。 - 每個批次的限制：≤6 個子任務或一個連貫區域；同一波次中，沒有檔案被兩個批次編輯（將衝突的子任務移到同一個批次或下一個波次）。
- 合併小批次：如果存在，一個孤立的 T1 子任務會加入同一波次中的另一個 T1 批次；一個幾乎是機械式的孤立 T1 子任務可以改為內聯執行。
- T0 子任務被分組到其波次開始處的一個內聯步驟中。
階段 5 — 成本預覽（批准門檻）
將以下內容寫入計劃檔案（或向使用者顯示，在計劃模式外）：
| 波次 | 批次 | 模型 / 努力 | 子任務 | 估計成本 |
|------|-------|----------------|----------|-----------|
| 1 | 內聯 | 主 / shell | S1, S2 | ~0 |
| 1 | B1 | haiku / low | S3, S4 | 2 |
| 1 | B2 | sonnet / medium| S5 | 4.5 |
| 2 | B3 | opus / high | S6 | 12.5 |
總計 ≈ 19 單位 (全部-opus/high 基線 ≈ 75 單位 → 節省約 75%)
估計成本 = 子任務數量 × 模型權重 × 努力倍數。包含全部-opus/high 基線以便節省金額一目了然。在計劃模式下，以 ExitPlanMode 結束；在批准前不要執行。
階段 6 — 執行
對於每個波次，按順序：
- 執行該波次的 T0 內聯步驟。
- 在一則訊息中啟動該波次的所有批次（平行 Agent 呼叫）：
Agent(subagent_type: "general-purpose", model: <層級模型>, effort: <層級努力>, description: "<波次>/<批次>: <簡短說明>", prompt: <簡短提示>)。 每個簡短提示都應從references/batch-brief-template.md建立。共享的前言必須在所有批次中位元組一致（利於提示快取）— 將變數內容放在其後。 - 等待波次中的每個批次回報後，再開始下一個波次。切勿撰寫或猜測待處理代理的結果。
- 使用每個批次的狀態和回報的檔案來更新帳本。
階段 7 — 驗證與升級
- 在每個波次後，主執行緒執行子任務的
done_check命令以及專案的廉價全域檢查（型別檢查 / lint / 受影響的測試）。 - 一個失敗的子任務被提升一層後，單獨（或與相同新層級的其他失敗子任務一起）重新執行，並附上失敗輸出和前一個代理的報告。
- 每個子任務最多一次升級。如果仍然失敗，停止並向使用者提供簡短的診斷。T4 失敗直接交給使用者。
階段 8 — 記錄與學習
- 將帳本標記為完成：每個子任務的最終層級、通過/升級、變更的檔案。
- 將每個子任務的一行追加到
~/.claude/task-splitter/routing-log.md（如果缺少資料夾/檔案則建立；絕不可在該技能的 git 儲存庫內）：YYYY-MM-DD | <專案> | <類型> | <起始層級> | <最終層級> | first-pass|escalated|failed - 用 ≤10 行向使用者報告：已完成的工作、相對於基線的最終成本單位、任何升級、任何未解決的事項。
輸出慣例
- 保持主執行緒精簡：代理回報簡短報告，而非檔案內容。
- 對於拆分和成本預覽，向使用者提供表格，而非散文。
- 如果整個任務總分 ≤3，或子任務 ≤2 個，請說明情況並直接執行 — 拆分它的成本會超過節省的成本。