用途：将多个 GitHub issue 批量执行到单一构建分支。它把原本单体式的 build-train 技能拆成 ICM 流程，每个阶段由独立子代理负责，避免长会话上下文膨胀影响冲突解决判断。
主要能力：采用 6 阶段流程。00-setup 内联执行，确定默认分支、创建构建分支与标签、读取全部 issue；01-plan-order 由子代理读取 issue 正文，推导依赖图并输出构建波次；02-build-fanout 由子代理按波次扇出构建，同一波内并发、跨依赖边串行，每个构建由一个 Task worker 产出 PR，并校验和修正 base 分支与标签；03-merge-chain 将各 PR 合并进构建分支并解决冲突；04-final-pr 向默认分支开一个最终 PR（不带 build-train 标签，进入正常评审流程）；05-report 内联写报告并输出结果标记。
使用方式：参数包括必填的 repo（org/repo，第一个位置参数）、必填的 --issues（逗号分隔的 issue 编号，如 10,14,15,16），以及可选的 --branch（默认 build/YYYY-MM-DD，若已存在则追加 -2 后缀）。从 $ARGUMENTS 解析。各阶段交接文件位于 .procedure-output/build-train/{stage}/handoff.md，02 阶段还会为每个构建写子交接文件。子代理只接收所需交接文件，不接收完整编排器上下文。
适用场景：需要把多个相互关联的 issue 批量构建、合并并统一提交评审时。
限制：同一仓库一次只能运行一个 build-train，00 阶段会检查已有 build/* 分支；02 阶段单个构建失败不会导致整体失败，会跳过并记录，只有零个构建成功才失败；禁止对构建分支强制推送；每个 worker 仅处理其分配的 issue；00 和 05 阶段必须内联运行，结果标记必须来自编排器。资料未提供安装命令、收费或平台信息。