用途：把一个大批次工作拆成互不冲突的 lane（通道），每条 lane 在自己的 git worktree 中作为自主 /goal 会话运行，最后通过一次人工验证的 merge 汇合。goal-batch 扮演编排者（ORCHESTRATOR）：规划、启动、监视、验证、合并、报告，不替代 lane 干活。触发语包括“run these in parallel”“goal-batch”“launch lanes for these”等。
主要能力与流程： 1）调用：交互式 TUI 里 /goal-batch <batch>，或自然语言“Use the goal-batch skill and …”。headless 场景下裸 /goal-batch 会被当成普通文本，应改用 amplifier run "Use the goal-batch skill and run this batch: …"，或直接 load_skill(skill_name="goal-batch", arguments=…)。若 $ARGUMENTS 为空，需从已有上下文重建批次，否则直接说明并询问。 2）Phase 1 规划：做冲突分析，把争用同一文件的 lane 合并或指派唯一拥有者，其余记为 residual；预分配所有编号；标出无人拥有的 seam；固定 BASE_SHA 与测试基线。lane 数不设上限，但容器/VM/后台服务等超出进程寿命的资源需要全批次累计上限，由编排者维护资源账本。 3）Phase 2 评审：先展示“When this finishes you WILL have:”与“You will NOT have:”两行，再给出单屏计划（lane 表、争用文件、搁置项、无主文件、每 lane 边界、监视方式）。每个 lane 必须能追溯到用户实际要求。批准可对话式给出；预授权（如 pre-approved）有效，计划仍须展示。 4）Phase 3 编写 goal 文件：用 goalify 按 lane 生成，先提交到基础提交再切 worktree。goal 需包含析取式退出条件、PASS/FAIL-named/BLOCKED-named/PENDING-HUMAN 终态、所需 work-tracker 可达终态动词（如 work_erratum）、工作目录+分支+基础 SHA、文件所有权与 residual 协议、早提交常推送、不得合并到 main、宿主能力限制、非 git 资源及其拆除、时间上限（超时是终端 BUDGET 状态）。最终动作是在 worktree 根写 DONE.json（字段含 lane、session_id、verdict 等），并先加入 .gitignore。 5）Phase 4 预检：每条 lane 输出必须可提交；远程建议但非必需；创建 worktree 时跳过已存在的；抽样冒烟测试启动器。 6）Phase 5 启动：每条 lane 一个 tmux 会话，用 <skill_directory>/scripts/launch_lane.sh <batch> <lane> <worktree> .amplifier/goals/<lane>.md <repo>/.amplifier/goals/manifest.tsv [wall_s] [max_turns] 启动；manifest 由脚本维护，会话名形如 gb__<batch>__<lane>。必须单阶段启动，禁止向裸 TUI 发送按键。 7）Phase 6 监视：用 <skill_directory>/scripts/batch_status.sh <manifest.tsv> <BASE_SHA> 探测；每条结论必须来自刚运行的探测。 8）Phase 7 合并与报告：由编排者执行合并，验证并报告 residual、PENDING-HUMAN 与资源拆除。
限制：以上是技能本身的工作规则与用法；具体安装命令、价格、平台支持、实际效果等资料未提供。