---
name: batch
description: 通过将变更分解为独立单元并在隔离的工作树中生成并行工作代理，编排跨代码库的大规模可并行变更。
---

# Batch：并行工作编排

你正在编排此代码库中的大规模可并行变更。

## 用户指令

$ARGUMENTS

## 阶段 1：研究和计划（计划模式）

现在调用 `EnterPlanMode` 工具进入计划模式，然后：

1. **理解范围。** 启动一个或多个子代理（在前台——你需要它们的结果）以深入研究此指令涉及的内容。找到所有需要更改的文件、模式和调用点。理解现有约定，使迁移保持一致。

2. **分解为独立单元。** 将工作分解为 5–30 个自包含的单元。每个单元必须：
   - 能够在隔离的 git worktree 中独立实现（与兄弟单元无共享状态）
   - 能够独立合并而不依赖另一个单元的 PR 先落地
   - 大小大致均匀（拆分大单元，合并琐碎的单元）

   根据实际工作规模调整数量：少量文件 → 接近 5；数百个文件 → 接近 30。优先按目录或模块切片，而非任意文件列表。

3. **确定端到端测试方案。** 弄清楚工作人员如何验证其更改确实端到端有效——不仅仅是单元测试通过。寻找：
   - 一个 `claude-in-chrome` 技能或浏览器自动化工具（用于 UI 更改：点击受影响的流程，截图结果）
   - 一个 `tmux` 或 CLI 验证器技能（用于 CLI 更改：交互式启动应用，执行更改后的行为）
   - 一个 dev-server + curl 模式（用于 API 更改：启动服务器，命中受影响的端点）
   - 一个工作人员可以运行的现有端到端/集成测试套件

   如果你找不到具体的端到端路径，使用 `AskUserQuestion` 工具询问用户如何端到端验证此更改。根据你的发现提供 2–3 个具体选项（例如，"通过 chrome 扩展截图"、"运行 `bun run dev` 并 curl 端点"、"无端到端——单元测试足够"）。不要跳过这一步——工作人员自己无法询问用户。

   将方案写为一组简短、具体的步骤，工作人员可以自主执行。包括任何设置（启动开发服务器，先构建）和用于验证的确切命令/交互。

4. **编写计划。** 在你的计划文件中，包括：
   - 你在研究期间发现的内容摘要
   - 一个编号的工作单元列表——每个单元：简短标题、它覆盖的文件/目录列表，以及变更的单行描述
   - 端到端测试方案（或"跳过端到端因为…"如果用户选择了该项）
   - 你将给每个代理的确切工作人员指令（共享模板）

5. 调用 `ExitPlanMode` 呈现计划以供批准。

## 阶段 2：生成工作人员（计划批准后）

一旦计划被批准，使用 `Agent` 工具为每个工作单元生成一个后台代理。**所有代理必须使用 `isolation: "worktree"` 和 `run_in_background: true`。** 在单个消息块中启动它们所有，使它们并行运行。

对于每个代理，提示必须完全自包含。包括：
- 总体目标（用户的指令）
- 此单元的具体任务（标题、文件列表、变更描述——从你的计划逐字复制）
- 你发现的任何工作人员需要遵循的代码库约定
- 你计划中的端到端测试方案（或"跳过端到端因为…"）
- 以下工作人员指令，逐字复制：

```
完成实现更改后：
1. **代码审查** — 使用 `skill: "code-review"` 调用 `Skill` 工具来查找正确性缺陷（它报告发现；不编辑代码）。在继续之前修复它发现的任何发现。
2. **运行单元测试** — 运行项目的测试套件（检查 package.json 脚本、Makefile 目标或常见命令如 `npm test`、`bun test`、`pytest`、`go test`）。如果测试失败，修复它们。
3. **端到端测试** — 遵循协调员提示中的端到端测试方案（见下文）。如果方案说为此单元跳过端到端，跳过它。
4. **提交并推送** — 使用清晰的提交信息提交所有更改，推送分支，并使用 `gh pr create` 创建 PR。使用描述性标题。如果 `gh` 不可用或推送失败，在你的最终消息中注明。
5. **报告** — 以一行结束：`PR: <url>` 以便协调员可以跟踪。如果未创建 PR，以 `PR: none — <reason>` 结束。
```

使用 `subagent_type: "general-purpose"`，除非有更具体的代理类型适合。

## 阶段 3：跟踪进度

启动所有工作人员后，渲染一个初始状态表：

| # | 单元 | 状态 | PR |
|---|------|--------|----|
| 1 | `<title>` | 运行中 | — |
| 2 | `<title>` | 运行中 | — |

当后台代理完成通知到达时，解析每个代理结果中的 `PR: <url>` 行并以更新的状态（`已完成` / `失败`）和 PR 链接重新渲染表格。为任何未产生 PR 的代理保留简短的失败说明。

当所有代理都已报告时，渲染最终表格和一行摘要（例如，"22/24 个单元已作为 PR 落地"）。
