batch

name	batch
description	Research and plan a large-scale mechanical change, then execute it in parallel across independent work units
when_to_use	Use when the user wants to make a sweeping, mechanical change across many files (migrations, refactors, bulk renames, mass updates) that can be decomposed into independent parallel units of work.
argument-hint	<instruction describing the change to make>
context	inline
disable-model-invocation	true

Execute a large-scale change by researching, planning, then parallelising the work.

$ARGUMENTS

Phase 1: Research and plan (enter plan mode)

Before making any changes:

1. Understand the scope. Search the codebase to identify all affected files, packages, or modules. Use glob, grep_file, and bash to build a complete picture.

2. Decompose into independent units. Break the work into 5–30 units where each unit can be completed without depending on another unit's output. Prefer per-package or per-directory decomposition.

3. Define the validation recipe. Determine how to verify each unit after the change:

   • Existing test suite: go test ./... or equivalent
   • Build check: go build ./...
   • Lint: golangci-lint run or equivalent

4. Write the plan. Include:

   • Summary: one paragraph describing the change
   • Work units: numbered list, each with a clear, self-contained description
   • Validation recipe: exact commands to run after each unit
   • Worker instructions: step-by-step instructions a sub-agent should follow for any unit

5. Present the plan and ask for approval before proceeding to Phase 2.

Phase 2: Execute units in parallel (after approval)

For each work unit, launch a background agent with these instructions:

Goal: [paste work unit description]

Validation recipe: [paste validation commands]

Worker instructions:
1. Make the required change for this unit only. Do not touch other units.
2. Run the validation recipe. Fix any failures before proceeding.
3. Invoke /simplify on the changed files.
4. Create a git commit with a clear message: "batch: [unit description]"
5. Report back: "DONE: [unit title]" or "FAILED: [unit title] — [reason]"

Track the status of each unit in a table:

#	Unit	Status	Notes
1	...	running
2	...	done

Phase 3: Summarise

Once all units complete, report:

• How many units succeeded / failed
• Any units that need manual attention
• Overall validation: run the full test suite across all changes