Introducing /one-shot-orchestra — Our Most Powerful Skill Yet

🚀 The Launch

Today we're shipping /one-shot-orchestra — the biggest architectural jump we've made on the max-effort build skill. It's live inside Godmode now.

Every prior version (/one-shot, /one-shot-beta, /one-shot-scripts) was a single Claude instance running a long protocol in one working memory. Orchestra is different: it's a conductor pattern. One Claude orchestrates, many Claudes build.

🔎 Why We Built It

Claude's working memory is large but finite. When the main instance has loaded the skill, read the project, made a plan, spawned sub-agents, and started building — memory fills up. On truly big builds, quality drops before the work is done.

The obvious fix is parallelism. But the in-session Agent tool still runs inside the conductor's memory. Sub-agents help, but they don't buy you more memory — they share the same ceiling.

Orchestra breaks the ceiling by launching genuinely separate Claude Code processes in their own terminal windows. Each one boots with a fresh ~1M-token context. None of them inherit the conductor's loaded state.

⚙️ How It Works Under the Hood

Orchestra's execution loop is a file-based protocol. No sockets, no message bus — just directories and JSON files that both sides can read.

Every worker gets a shared run directory: a sandbox containing briefs/, work/, media/, a live chat.md, and a rolling telemetry.jsonl. You can watch the whole orchestra cooperate in real time by tailing those files.

🧠 Fresh Memory Is the Point

Every token a Claude instance reads costs working memory. By the time a skill has loaded, the project has been scanned, and the plan has been drafted, a meaningful chunk is already spent on knowing what to do instead of doing it.

A fresh-spawn worker starts empty. It gets a one-page brief describing only what it needs. The rest of its memory is free for the actual work — reading files, running tests, building output.

🎭 Two Modes, One Conductor

Not every task wants a fresh spawn. Some work benefits from a collaborator who's already read the plan. Orchestra supports both modes and has a written rule for when to pick which.

The decision table lives at the top of orchestra-protocol.md. Every phase script points to it — so when the conductor hits "need a reviewer here," it knows exactly which mode fits.

🔁 The Worker Contract

Every worker, regardless of mode, honours the same contract. When it's done, it writes one JSON file. That's it.

{
  "status": "success",
  "worker": "BuilderA",
  "artifact_paths": ["work/variant-A.txt"],
  "notes": "Drafted a single-sentence pitch, no markdown.",
  "token_usage": { "total": 48213 }
}

{
  "status"status · polled by orchestra-wait-and-kill.sh in a loop. The instant this field appears, the conductor terminates the worker terminal.: "success",
  "worker"worker · the brief↔result match key. Conductor uses it to find which brief just completed and route output to the right downstream phase.: "Builder-A",
  "artifact_paths"artifact_paths · file paths the conductor reads next. Verifier and Polisher phases pick up exactly these files; nothing else is opened.: ["work/variant-A.txt"],
  "notes"notes · free-form summary spliced into chat.md so the human watching the live feed sees what the worker did without reading every artefact.: "Drafted a single-sentence pitch.",
  "token_usage"token_usage · written to telemetry.jsonl for the audit trail. Used by /godmode-evolution to grade efficiency dim across runs.: { "total": 48213 }
}

The conductor waits on that file, reads it, kills the worker's terminal, and moves on. No ambiguity about "is it done yet?" — the file either exists or it doesn't.

🧪 Smoke-Tested On Arrival

Orchestra ships with a test/TEST-BENCH.md containing three real smoke tests. We ran them before flipping the skill to live.

🧬 Audited By Evolution

Every new skill we ship gets graded by /godmode-evolution — the meta-skill whose entire job is making other skills better. Orchestra's scorecard:

The two lowest scores are the honest ones. Smoke tests were written and executed on the golden path but not every timeout/backoff edge case. Delegation hygiene is solid at the protocol level but we'd still like deeper integration across a couple of phase scripts. Both are logged for the next loop.

📦 What You Get When You Use It

• Bigger builds without memory drops — fresh-spawn workers let Orchestra attack work that would have stalled a single-process skill.
• Live visibility — chat.md updates as workers sign off. You can watch the build happen in any markdown viewer.
• Two-mode flexibility — fresh-spawn when isolation matters, in-session agent when speed does.
• Deterministic hand-off — every worker writes result.json. No guessing, no polling for "is it done."
• Auditable — telemetry for every spawn, every kill, every result, in one jsonl you can replay.