任务分割器 — 最便宜的正确执行
目标：以满足质量的最低总成本完成主任务。 两个杠杆：(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 | 多文件逻辑、状态管理、集成、棘手的 bug、认证/支付/安全 |
| 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并填写上下文部分。在每个阶段后更新它。在计划模式下，如果不允许在计划文件之外写入文件，则将台账内容放入计划文件中的## 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 次被升级，则将其起始等级提高一级；如果某个 type 在你选择的等级低一级的情况下连续 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个子任务，直接说出来并直接执行——拆分它的成本将超过节省的成本。