From pro-workflow
Decomposes large-scale changes into independent units and spawns parallel agents in isolated worktrees. Use for migrations, refactors, codemods, and changes touching 10+ files.
How this skill is triggered — by the user, by Claude, or both
Slash command
/pro-workflow:batch-orchestrationThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
The `/batch` command pattern for large-scale parallel changes.
The /batch command pattern for large-scale parallel changes.
/batch <instruction>
│
├── 1. Research: scan repo, understand scope
├── 2. Decompose: split into 5-30 independent units
├── 3. Present plan: show units, ask for approval
├── 4. Execute: one background agent per unit in isolated worktree
└── 5. Collect: each agent runs tests and opens a PR
/batch Convert all React class components to function components
/batch Add error boundaries to every page component
/batch Migrate from moment.js to dayjs across the codebase
/batch Add OpenTelemetry tracing to all API handlers
The instruction should describe the change pattern, not individual files. The batch system finds the files.
The orchestrator scans the repo to find every instance that matches the instruction:
grep -r "class.*extends.*Component" --include="*.tsx" -l
It builds a complete list of targets and groups them by independence.
Each unit must be:
Good units:
Unit 1: Convert src/components/Header.tsx (class → function)
Unit 2: Convert src/components/Footer.tsx (class → function)
Unit 3: Convert src/components/Sidebar.tsx (class → function)
Bad units:
Unit 1: Convert all components in src/components/ (too broad)
Unit 2: Fix issues from Unit 1 (dependent)
Target 5-30 units. Fewer than 5 doesn't justify the overhead. More than 30 and coordination costs grow.
The orchestrator presents:
BATCH: Convert class components to function components
Found: 18 class components across src/
Units (18):
1. src/components/Header.tsx — class Header → function
2. src/components/Footer.tsx — class Footer → function
...
18. src/pages/Settings.tsx — class Settings → function
Per unit: convert class to function, update hooks, run component tests
Estimated: ~2 min per unit, ~5 min total (parallel)
Proceed? (y/n)
Wait for approval. Never spawn agents without explicit confirmation.
After approval, for each unit:
Agents run in parallel. Each has its own context window and worktree — no conflicts.
[Agent 1] ── worktree-1 ── Header.tsx ── tests pass ── PR #41
[Agent 2] ── worktree-2 ── Footer.tsx ── tests pass ── PR #42
[Agent 3] ── worktree-3 ── Sidebar.tsx ── tests fail ── flagged
After all agents complete:
| Use Case | Why Batch Works |
|---|---|
| API migrations | Same pattern across many endpoints |
| Dependency upgrades | Find/replace + fix across codebase |
| Codemod-style refactors | Mechanical transformation, file by file |
| Adding instrumentation | Same tracing/logging pattern everywhere |
| Test coverage gaps | Add tests to untested modules independently |
| Lint rule adoption | Apply new rule fixes across all files |
| Don't Batch | Why |
|---|---|
| Interdependent changes | Units can't run in parallel if they depend on each other |
| Shared state modifications | Multiple agents writing to the same config or state file |
| Architecture changes | Need holistic reasoning, not file-by-file |
| Schema migrations | Database changes must be sequential |
| Changes requiring human judgment per file | Defeats the purpose of automation |
| Pattern | Scale | Isolation |
|---|---|---|
| Direct edit | 1-3 files | None needed |
| Subagent | 1 focused task | Forked context |
| Worktree | 1 feature branch | Full repo copy |
| Agent teams | 3-5 parallel tasks | Shared task list |
| Batch | 5-30 identical pattern | Full worktree per unit |
Batch is the heaviest tool. Use it when the change is mechanical, repetitive, and the units are truly independent.
npx claudepluginhub rohitg00/pro-workflow --plugin pro-workflowDecomposes large tasks (migrations, multi-issue fixes, big features) into parallel work packages with quality gates. Useful for reducing PR cycle time and avoiding merge conflicts.
Plans and executes large refactors by splitting scope into dependency-aware work packets, running parallel analysis, and coordinating sub-agents for safe, high-throughput code changes.
Orchestrates a multi-step refactoring pipeline: analyzes code quality, plans improvements, optionally writes tests, implements changes, and reviews results. Routes simple refactors to a lighter workflow.