An agent skill · one command, nine run shapes

/orchestrate

You hand one agent a big plan and watch it degrade — the context fills up, quality drops, you babysit. orchestrate turns that plan into a controlled run: one command, many fresh agents, every result checked before it counts.

# that's the whole start /orchestrate plan.md

runs onClaude CodeCodexCursorAntigravityopencodeGrok BuildHermesKimi CodePi

The idea

Everything in orchestrate follows one idea: coordination and work are different jobs, and they should never share a context window.

A controller plans the run, assigns the work, and checks the results — it never writes code itself. Each task goes to a subagent: a fresh worker that starts empty, does one scoped job, and is thrown away.

The two never talk through chat. The controller writes a brief file; the worker reads it, works, and writes a report file back. The files outlive the worker — so a run survives crashes, compaction, and restarts, because its state lives on disk instead of in anyone's head.

Worker 1 is already gone. Its brief, its report, and its ledger line remain — that is the whole trick.

How a run works

Every strategy shares the same six-step spine.

invokeYou point it at a plan file, or just describe the task. Every flag is optional.
triageTriage measures the task — size, independence, whether success is checkable — then picks a run shape and says why.
flight planBefore anything launches, the flight plan prints the design — topology tree, model + effort per agent, gates, budget range — and waits for your approval. Say change 3 to tweak a dimension, or approve. confirm=off skips the gate, never the print.
dispatchThe controller writes a brief and sends a fresh subagent to do exactly that task, on an explicitly chosen model.
gateGates review each result — first against the brief, then for quality. Failures loop back until clean.
ledgerEach finished task becomes one line in the ledger, progress.md. A resumed run trusts the ledger, not memory.

One preset, ten knobs

A strategy is a preset, not a product. orchestrate has ten dimensions — knobs like how work splits, who reviews it, which engine runs it at which reasoning effort, and whether the flight plan gates on your approval (confirm, on by default). Each of the nine strategies is just a named preset over those knobs. Learn one command and you've learned all nine.

Any knob you set yourself overrides its preset value. That's the whole override model:

/orchestrate plan.md strategy=staged engine=codex # one preset, one override

stagedthe preset…

topologystaged
planningplan-first
reviewdual
engineclaude
isolationoff
triggeronce

staged + your override…after your one flag

topologystaged
planningplan-first
reviewdual
engineclaude codex
isolationoff
triggeronce

That one line means: Codex implements every task, Claude still reviews every result. Strategies compose the same way — strategy=loop topology=parallel makes each loop cycle fan out.

The knobs you'll actually type — most runs touch two or three:

knobwhat it controlsdefault
strategythe run shape — one of the nine belowauto → triage picks
reviewwhich gates run on each resultdual — spec, then quality
enginewho executes — claude, codex, grok, cursor, agy, opencode, hermes, kimi, pi, or mixedclaude
modelswhich model tier does which jobtier map (appendix)
effortreasoning level per role — the first cost knob, model tier is the secondpinned per dispatch where the surface allows
isolationwhether workers get their own git worktreeworktree when >1 writer
triggerrun once, on a goal, on an interval, on a scheduleonce
workershow many run at once3–5
budgethard caps — cycles, agents, tokens, open PRsper strategy
confirmwhether the flight plan gates on your approvalonoff still prints the plan
the full command grammar
/orchestrate [plan-file | task description] strategy=auto|staged|parallel|hierarchical|team|workflow|loop|advisor|adversarial|xcli review=dual|spec|quality|panel:N|consensus:N|off engine=claude|codex|grok|cursor|agy|opencode|hermes|kimi|pi|mixed models=orchestrator:opus,worker:sonnet,advisor:strongest,… effort=low|medium|high|xhigh|max | worker:low,reviewer:high,… isolation=worktree|branch|off workers=N trigger=once|goal:"tests green"|interval:5m|schedule:"0 6 * * *" budget=cycles|agents|tokens confirm=on|off alias=saved-preset

Full reference: docs/usage.md — every dimension, every value, selection precedence.

Choose a strategy

Find yours by the shape of your task — or pass nothing and let triage pick.

controller / strong model worker script external CLI

stageddefault

Use it when you have a plan of mostly-independent tasks and want quality on every one. It works by sending a fresh implementer per task and reviewing each result twice before it counts. Every task's acceptance check is authored before the first dispatch — ideally by an agent other than the one who'll implement it.

parallel

Use it when tasks are independent, share no files, and wall-clock time matters. It works by running 3–5 workers at once in isolated git worktrees, then merging in dependency order. The merge counts returns against dispatches and refuses to synthesize a partial set — one dead worker never slips into a report that looks complete.

hierarchical

Use it when the work is too broad for one context and each domain needs real thinking. It works by giving every domain its own sub-orchestrator, which returns conclusions instead of transcripts. Wide and shallow beats deep — and who can stop a hung worker is settled before anything spawns.

team

Use it when workers must talk to each other — debates, competing hypotheses, cross-layer features. It works by spawning named teammates who share a task list and message each other directly. Teammates aren't worktree-isolated, so file ownership is partitioned in the spawn prompt; the team owes one final review before it disbands. Experimental.

workflow

Use it when you have 20+ similar items and a script should hold the plan instead of you. It works by fanning agents out from a deterministic script that verifies every finding and resumes with cached results. Resume only holds while the script stays deterministic — a clock or a random draw silently defeats the journal.

loop

Use it when work grinds toward a checkable goal — tests green, a metric hit. It works by running gated cycles against a stop condition, with hard caps and a kill switch. Cycles of activity that never move an acceptance gate force a real result or repair; a replan that produces no visible delta doesn't count as one.

advisor

Use it when budget is tight and most of the task is mechanical. It works by letting a cheap model do every turn while the strongest model answers only the few questions that need real judgment. Or invert it — the architect session never leaves the room and routes each dispatch to a routine, escalation, or review lane.

adversarial

Use it when a wrong plan costs far more than arguing about it — architecture, migrations, security. It works by having a different-lineage model attack the plan until consensus, before any code exists.

xcli

cdxcldgrk
Use it when a task fits another coding CLI, or you want a second opinion from a different model family. It works by routing tasks to codex or grok as workers or reviewers — one task per launch, and their diffs get reviewed too. An empty diff is never complete: exit 0 with nothing changed is a refusal, quoted verbatim, not a finished task.

Gated by default

Nothing lands because an agent says it's done. Every result passes two gates, in a fixed order, and reviewers verify by reading the code — never the worker's own report. Every gate that judges produced work names at least one fact no agent produced: a command that ran with its output, a file on disk at a stated sha, an external readback. A topology of agents reading each other's reports can be perfectly consistent and entirely unverified.

implementA fresh worker builds exactly what its brief asks.
spec gate"Did they build what was asked?" Nothing missing, nothing extra.
quality gate"Is it well-built?" Runs only after spec passes — never before.
final gateBefore the run reports done, a fresh context judges the whole accumulated change set against your originally stated goal — per-task gates structurally cannot see drift across tasks. Verdict: ship, fix-first, or rethink.
ledgerThe task becomes one ledger line; the run can always resume from here.
Any failure sends one fix agent back through the same gate until it's clean — no skipping, no downgrading a finding to pass. Two or three failed rounds on the same gate escalates the model tier, never a fourth identical round. Judges are cross-family where the host allows, and pinned and logged per round — a silently upgraded judge makes round 1 and round 3 incomparable. High-stakes plans can add more lenses: review=panel:3.

Four invariants sit under every status, gate, and ledger line:

observation ≠ transition proposal ≠ authority tool success ≠ accepted progress accepted progress = validation + durable writeback + committed readback

The third is the one most runs get wrong: an exit code of 0 only proves the process exited — not that the work landed.

Where the tokens go

The target is zero wasted tokens, not minimal tokens. Workers get every pointer they need to do the job — then stay quiet while working and report densely when done. Noisy command output is redirected to files, so dumps never enter anyone's context.

Every dispatch carries a short contract matched to its role — a dispatch with no block is a defect, not a default:

WORKER≈334 tok

Who: implementers, integrators, loop executors.
Orient first — reading to understand is work, not waste. Then silence: no narration, no restating the brief. Blockers come back structured, and safety messages are never silenced. Written files follow the same discipline: length matched to what the task needs, no filler sections or boilerplate.

REVIEWER≈176 tok

Who: spec, quality, and panel reviewers.
Never self-filters. Every finding goes to a findings file with severity and confidence; inline is just the verdict and counts. Deciding what matters is the controller's job. Delivering that verdict is the completion condition — a finished-but-silent reviewer never finished.

MINIMAL≈19 tok

Who: advisors, verifiers, one-line judges.
One line: return only the answer in the asked shape. A 300-token contract on a 4-line return would cost more than it saves.

The life of a dispatch — where tokens get spent, saved, and where quality is guarded:

  1. briefcontrollerinput quality ↑
    Pointers, not payloads: the objective, the scope, read: pointers to the right files, a verification command, and a stop condition — instead of pasted file contents.
    example brief ▸
    # .orchestrate/task-3-brief.md Objective extract the rate-limit middleware; done = suite green, public API unchanged Scope in: src/middleware · out: auth flow · must NOT change: response shape Pointers read: src/middleware/rate.ts — current implementation @ 4f2c91a read: src/config/limits.ts — constants to honor Verification pnpm test middleware Report .orchestrate/task-3-report.md · inline <15 lines Stop BLOCKED if the storage backend is ambiguous — don't guess
  2. brief-checkgatesaves a worker turn
    A script fails dead pointers and missing sections before dispatch — a clarifying round-trip afterward costs a full worker turn.
  3. workworker−narration −dumps
    The worker orients, works silently, and redirects noisy output to .orchestrate/raw/ at execution time — the dump never enters context.
  4. reportworkercompounds every turn
    Dense and structured — the report becomes controller input that is re-read on every later turn, so every saved token compounds. Code and exact errors stay verbatim.
  5. gate & ledgerreviewer · controllerrecall guard
    Findings land in a file that caps can't truncate; the task lands as one ledger line. Resume reads the ledger and git log — never the transcript.
Honest numbers: expect 10–25% session-level savings, not the 65–75% output-only headlines. A/B on your provider's billing page before believing anyone — including this page.

Start here

Install once, point it at a plan. Bare invocation triages and explains its pick.

# install npx skills add gabros20/orchestrate-skill -g # run $orchestrate docs/feature-plan.md $orchestrate "keep fixing until the suite passes" strategy=loop trigger=goal:"pytest green"

The same install runs on any Agent Skills host — Claude Code is the reference; on the others the skill detects its host at kickoff, binds what's native, and degrades honestly where a primitive is missing.

supported agents — who runs what
hostnative subagentsmodel pinworth knowing
Claude Codedeep, parallel, backgroundthe reference — every primitive native
Codex CLI6 threads, depth 1invoke with $orchestrate; installs under $CODEX_HOME/skills
Cursor CLIparallel + backgroundheadless ask-user is broken — human gates need ACP
Antigravityasync, depth 10, messagingsubagents inherit the parent's model
opencodesynchronous onlyparallel via opencode serve or external processes
Grok Build8 parallel, auto-worktreereads .claude/ wholesale; skills load at session start
Hermes3 concurrent, flatinvoke /orchestrate explicitly — no auto-trigger
Kimi Code CLIAgent/AgentSwarm, coder/explore/plannative /goal loop; live-verified v0.28.0, smoke run pending
Pinone — headless-CLI fan-out onlyper processthinnest host: no sandbox or approvals — worktree + diff review; docs-verified

team needs Claude Code or Antigravity and workflow needs Claude Code; every other strategy runs everywhere — worst case as headless-CLI fan-out. Full bindings and quirks: shared-hosts.md.

An alias is a preset you name yourself in config.yaml. Five ship built in — good defaults to steal:

aliasexpands tofor
red-teamadversarial + panel:3high-stakes builds — debate the plan, triple-lens the output
codex-grindstaged + engine=codex + effort=highcheap bulk implementation, Claude reviews every task
swarmparallel + workers=4 + review=specfast independent fan-out, minimal ceremony
afkloop + trigger=goal + cycles:20, open_prs:1walk-away grinding with hard rails
architectadvisor + worker:sonnetbig-model thinking, small-model doing

Copy-paste starting points for more scenarios: docs/recipes.md.

model tiers — who runs on what

Model and reasoning effort are explicit on every dispatch — an omitted model silently inherits the most expensive one, and effort is the first cost knob, tier the second. A pin you requested is not a pin you got: the run records the model that actually ran beside the one you asked for. And turn count beats token price — a too-cheap model takes 2–3× the turns and loses the savings.

tierjobdefaultnever
advisorrare judgment consults, out of the hot pathstrongestexecutes
orchestratorplans, decomposes, assigns, measuresstrongimplements
reasonerarchitecture, hard debuggingopus-classmechanical batches
workerscoped executionsonnet-classdesign decisions
reviewerspec / quality / verificationmid-tier floorwrites
peerdifferent-lineage second opinioncodex / grokseeing the other peer's answer first
what appears on disk
$CODEX_HOME/skills/orchestrate/ (client path varies) ├─ SKILL.md the router — grammar, catalog, universal rules ├─ config.yaml your saved aliases ├─ scripts/ workspace · task-brief · review-package · brief-check · toolbox └─ references/ strategies, shared contracts, dispatch templates <your repo>/.orchestrate/ per-run workspace — self-ignoring, invisible to git ├─ run.md dimensions, budget, flight-plan outcome (the audit trail) ├─ task-N-brief.md / -report.md per-task handoffs ├─ decisions.md cross-cutting decisions — briefs cite IDs, never restate ├─ raw/ redirected command output — dumps never enter context ├─ toolbox.md probed orientation recipes — read, don't re-probe └─ progress.md THE LEDGER — resume trusts this + git log, not memory

Layout details: docs/usage.md.