goal-batch

name	goal-batch
description	Batch independent work into isolated /goal lanes — one worktree, branch, and tmux session each — get your approval, then verify and merge every lane yourself. Use when work decomposes into pieces that can run at the same time: "run these in parallel", "goal-batch", "launch lanes for these", "work these N tasks simultaneously", "batch these as goals". Nothing launches until you've seen the lane split and said go, and this is NOT fire-and-forget: the orchestrating session re-runs the full suite after every merge and never accepts a lane's own claim that it finished. NOT for bounded edits that each end in their own PR — use mass-change for that. For continuous refill-on-drain parallel work toward an outcome, use ten-lane-highway instead. Requires git, tmux, the amplifier CLI on PATH, and the goalify and monitor skills.
version	2.0.0
user-invocable	true
argument-hint	<the work to batch, or where it is enumerated>
allowed-tools	["bash","read_file","write_file","edit_file","grep","glob","delegate","load_skill","todo"]
model_role	general
visibility	{"summary":"One-shot batch of parallel /goal lanes that launches once and drains together; for continuous refill-on-drain work use ten-lane-highway."}

Goal Batch

Split large work into lanes that cannot collide, run each as an autonomous /goal session in its own worktree, and land the results through a merge pass you verify yourself.

You are the ORCHESTRATOR. You plan, launch, watch, verify, merge, report. You do not do the lanes' work — if you catch yourself editing a lane's code mid-flight, stop and fix the goal file or relaunch instead.

Every rule here was bought with a real failure in production use — roughly 45 lanes across three operators. Where a rule looks fussy, it is load-bearing.

Shape references (plan screen, approval vocabulary, DONE.json, report) live in examples/plan-and-report.md. This file is the rules.

Invoking. /goal-batch <batch> in the interactive TUI, or "Use the goal-batch skill and …" in natural language — both load this skill reliably (measured). What does NOT work is a bare /goal-batch … in a headless amplifier run "<prompt>": the model reads the token as prose and does the work itself, producing plausible branches with no gate, no manifest, and no lanes. In a headless one-shot, direct the assistant in natural language — e.g. amplifier run "Use the goal-batch skill and run this batch: …" — or call load_skill(skill_name="goal-batch", arguments=…) outright. Naming the skill is what loads it; the bare slash token is not.

If $ARGUMENTS is empty, you have no batch. This skill forks — the sub-session cannot see the parent conversation, so an arguments-less load_skill call arrives with nothing to plan against. That happened in a real run and the whole invocation died silently. Do not produce an empty plan and do not guess: reconstruct the batch from whatever context you were given, and if there genuinely is none, say so in one line and ask for the work. One question, not an interview.

Running the companion scripts. load_skill returns skill_directory. Resolve every script from it — <skill_directory>/scripts/<name>.sh — and use that absolute path. Never a bare relative path: the working directory is the target repo, not the skill, and in a bundle the skill lives under a hash-suffixed cache path that changes between installs. Never copy a script into the target repo — a real run did exactly that, leaving .amplifier/bin/ behind as untracked pollution in someone else's repository.

Input — $ARGUMENTS: the work to batch, or a pointer to where it is enumerated. If lane independence is unclear, that is Phase 1's job, not a question for the user yet.