batch-orchestration

Use the /batch command with a description of the change pattern, such as converting class components to function components. The orchestrator scans the repo, decomposes the work into 5-30 independent units, and runs one agent per unit in parallel after your approval.

Batch works best for mechanical, repetitive changes: API migrations, dependency upgrades, codemod-style refactors, adding tracing or logging instrumentation, filling test coverage gaps, and applying lint rule fixes across many files.

Avoid batching interdependent changes, shared-state modifications, architecture changes, and database schema migrations. These require sequential execution or holistic reasoning rather than independent parallel units.

Each agent runs in its own isolated git worktree with its own context window, so units never share state or overwrite each other's changes. Each agent tests its own change and opens a separate PR.

Failed units are flagged in the final collection summary with error details rather than silently skipped. You can retry failed units individually after the batch completes.