Seven stages. One pause. Zero drift.
A first-draft plan is one perspective that sounds confident. Moonshot forces the plan through five opposing perspectives, six improvement rounds, and a hard gate before it earns the name "one-shot". We ran this pattern by hand on real builds until it kept producing smaller, cheaper, more honest plans. Then we made it one command.
Idea
Your raw idea, saved verbatim. This exact text becomes the drift anchor.
Triage
Too small for the pipeline? It says so and offers a direct plan instead.
Council
5 advisors + peer review + chairman lock the goal and draft plan v0.
Checkpoint
You confirm the goal in one glance. Wrong goal never reaches EBI.
EBI ×6
Six deep rounds climb the depth ladder and harden the plan.
Goal-Lock
Six-criterion gate. PASS ships. DRIFT loops back. BLOCK stops.
Contract
Goal, criteria, preflight, plan, and the paste-ready one-shot prompt.
Subagents cannot spawn subagents.
The council alone spawns 11 subagents: 5 advisors, 5 peer reviewers, 1 chairman. If this pipeline lived inside an agent definition, the council step would fail the moment it tried to convene. So Moonshot is packaged as main-thread skills that orchestrate everything and can spawn whatever they need.
The run directory is the pipeline's memory.
Every stage writes its output to a file on disk, and later stages read files, not chat history. The EBI rounds edit the plan file in place instead of piling six drafts into the conversation. That is the opposite of monolithic multi-agent runs that overflow context, and it means a run that dies can resume from its last completed file.
A plan is not done when it sounds good. It is done when a fresh session can execute it without asking a question.
Five advisors. One verdict. The goal gets locked here.
Ask one AI a question and you get one answer with no way to tell if it is great or mid. The council, adapted from Andrej Karpathy's LLM Council, runs the question through five independent thinking styles, has them review each other anonymously, then a chairman synthesizes the verdict. In this pipeline, the framed question is always the same shape: what is the real goal behind this idea, and what plan achieves it in one shot?
The Contrarian
Assumes the idea has a fatal flaw and hunts for it. The friend who saves you from a bad deal by asking the questions you are avoiding.
First Principles
Ignores the surface question and asks what you are actually trying to solve. Sometimes its best output is "you are asking the wrong question."
The Expansionist
Hunts the upside everyone else is missing. What if this works better than expected? What adjacent opportunity is hiding?
The Outsider
Zero context on you or your field. Catches the curse of knowledge: things obvious to you but confusing to everyone else.
The Executor
Only cares whether it can actually be done and what the fastest path is. "OK, but what do you do Monday morning?"
Why these five: they fight on purpose
Downside against upside. One hunts the fatal flaw, the other hunts the hidden win. Neither is allowed to hedge.
Rethink everything against just ship it. The tension between the right question and the fastest path.
Fresh eyes in the middle. When the experts assume, the Outsider says "I do not know what that word means."
How a session runs
- Frame the question with context. The skill scans your workspace first: CLAUDE.md, project docs, files the idea references. Advisors get grounded facts, not just your sentence, so the advice is specific instead of generic.
- Convene the council. All 5 advisors spawn in parallel as subagents. Each is told: lean fully into your angle, do not hedge, do not be balanced. 150 to 300 words each.
- Anonymized peer review. The 5 answers become Response A through E in random order. Five fresh reviewers each answer: which is strongest, which has the biggest blind spot, and what did all five miss?
- Chairman synthesis. One agent sees everything and writes the verdict: where the council agrees, where it clashes, blind spots caught, the recommendation, and the one thing to do first.
Reviewers defer to the thinking style they like. "The Executor is always practical" beats evaluating the actual argument.
Ideas win on merit. The peer-review round is what makes this a council and not just asking five times.
What this stage hands to the pipeline: a locked goal in canonical format, GOAL: [outcome] measured by [criteria] within [constraints], plus the full verdict and plan v0. The chairman is allowed to side with a lone dissenter if the dissenter's reasoning is strongest.
Each round asks a different question.
EBI stands for Even Better If. It is recursive: each round reveals improvements the previous round could not see, because the work has evolved. Six rounds is not "check it six times". It is six different lenses, climbing a depth ladder from surface fixes to full reframes. Round five or six is where the breakthrough usually lives.
| Round | Depth | The question it asks | Technique |
|---|---|---|---|
| 1 | Surface | What would a sharp-eyed colleague flag in review? | Checklist audit against standards |
| 2 | Structure | Is this organized to maximize its purpose? | Reorder, regroup, cut redundancy |
| 3 | Craft | What separates good from great here? | Side-by-side with the North Star reference |
| 4 | Resonance | How does this land for the person using it? | Walk through as the end user, moment by moment |
| 5 | Innovation | What would make this award-winning? | Cross-pollinate from other domains |
| 6 | Synthesis | What pattern connects the best improvements so far? | Review all rounds for the unifying principle |
The rules inside every round
15+ ideas, keep 7 to 12
Each round generates more ideas than it keeps. The cutting is where quality lives. Bold ideas that got cut surface as wild cards.
At least 2 per round
Inversion, audience rotation, constraint flips, the 10x test, remove-to-improve. These push past the obvious first answers.
Quality gate every round
Improvement attempts can make things worse. Each round verifies fundamentals still hold before it counts. If a round regresses, it reverts.
Improves a finished artifact: does it still work, is it still readable, is it actually better?
Improves a plan, not an artifact. Bold pivots are encouraged because ideas are cheap to change. The quality gate becomes: is this the right thing to build?
Around round five, the plan usually reframes itself.
In every deep EBI session there is a point where an insight stops being "add this" and becomes "wait, the whole approach shifts." Moonshot's own design went through this exact process, and its round six produced the reframe this whole page is built on: the output is not a prompt, it is a contract. The pipeline actively hunts for that moment on every run.
What this stage hands to the pipeline: the final plan, hardened over six rounds, edited in place in the run directory with a round-by-round log of what changed and why.
The gate that keeps the plan honest to the idea.
Six improvement rounds create a real risk: the plan gets smarter and slowly stops being your plan. Goal-lock is the enforcement step. It holds the final plan against two fixed anchors: your original idea, word for word, and the goal the council locked. Every check must quote evidence from the plan. No vibes.
| # | Criterion | The question | Verdict |
|---|---|---|---|
| 1 | Goal fidelity | Does the plan deliver the locked goal, not a cooler adjacent goal? | P/F |
| 2 | Scope drift | Was anything added that the original idea did not ask for and the goal does not need? | P/F |
| 3 | One-shot executability | Could a fresh session run this with zero clarifying questions? Every path, key, and dependency named? | P/F |
| 4 | Environment preflight | Does the contract list the concrete facts to verify before executing: files exist, server running, keys in .env? | P/F |
| 5 | Phase gating | Does every phase end with a concrete verification step before the next begins? | P/F |
| 6 | Assumptions + done | Are assumptions explicit with fallbacks? Is "done" unambiguous and tied to the goal? | P/F |
Criterion 4 exists because missing environment facts are the number one killer of one-shot prompts. A perfect plan that assumes a server is running, when it is not, fails on step one.
Three possible verdicts
Ship it
All six criteria pass with quoted evidence. The pipeline compiles the contract and offers to execute.
Fix and re-gate
Specific violations listed with quotes. One targeted EBI remediation round fixes exactly those items, then goal-lock runs again. Maximum two loops, then it comes to you with the standing verdict.
Stop
Structural failure: the goal itself is wrong, contradictory, or unachievable as scoped. No silent patching. The pipeline stops and tells you why.
Six rounds of clever improvements quietly turn "fix the checkout bug" into "redesign the checkout." Nobody decided that. It just accreted.
Criterion 2 quotes the addition, names it drift, and the remediation round strips it or you approve it explicitly. Scope changes become decisions, not accidents.
Also usable alone: /goal-lock <plan-file> against <original-idea> gates any plan from any source, not just pipeline runs.
What you type, what you see, what you get.
You type /one-shot followed by your idea, short or long-form. Then the pipeline runs. You are interrupted exactly once.
- Intake + triage. Your idea is saved verbatim as the drift anchor. If it is trivially small, the pipeline says so and offers a direct plan instead of burning a full run. If the goal is ambiguous, it asks exactly one clarifying question.
- Council runs. Eleven subagents: advisors, reviewers, chairman. Output: the locked goal, the verdict, and plan v0.
- Checkpoint: your only pause. You see three things and nothing else: the goal in one line, the plan in five bullets, and where the council clashed. Confirm or correct. Saying "just do it" up front skips this pause.
- EBI runs six rounds autonomously. Surface, Structure, Craft, Resonance, Innovation, Synthesis. The plan file evolves in place; every round logs what changed.
- Goal-lock gates. PASS, or up to two DRIFT remediation loops, or BLOCK.
- The contract compiles. Saved to the run directory, and the pipeline offers to execute it right now, or you paste it into a fresh session whenever you want.
The run directory: every stage on disk
Because every stage is a file, a run that dies resumes from its last completed file instead of starting over. And any run can be audited later: you can read exactly why the plan says what it says.
The contract: anatomy of the deliverable
One sentence
Outcome, measured by what, within what constraints. The same locked goal from the council, unchanged.
How you know it worked
Unambiguous, checkable, tied to the goal. Not "improved", but concrete and countable.
Verify before executing
Files that must exist, services that must be running, keys that must be in .env. Checked first, so failures happen in minute one, not hour two.
Phased and verify-gated
Every phase ends with a concrete verification before the next begins. No phase rides on hope.
Paste-ready
Fully self-contained. Paste into a fresh Claude Code session and it executes the whole build without asking a question.
The edges, explicit
Every assumption with its fallback, and a hard list of what this contract deliberately does not touch.
The pipeline caught two things a solo plan would have shipped.
On its first production run, intake discovered the "bug" in the request was already fixed in code, so the council re-aimed at the real problem behind it. Then the goal-lock gate failed the polished plan because one step named the wrong location for a config flag: exactly the kind of small wrong fact that kills a one-shot prompt an hour into execution. One targeted remediation round later, it passed. That is the system working: stale assumptions die at intake, wrong facts die at the gate.
Heavy machinery. Use it where being wrong is expensive.
A full run is token-heavy by design. That is the price of five opposing perspectives and six improvement rounds. The pipeline protects you from wasting it two ways: triage refuses ideas that are too small, and the single checkpoint stops a wrong goal before the expensive part begins.
Run it on
- New modules, systems, or client-facing builds
- Decisions where a bad call costs days or dollars
- Anything you would pressure-test from multiple angles anyway
Triage rejects
- Typo-level fixes and one-file changes
- Questions with one right answer
- Work an existing runbook already covers
It fails loudly
- DRIFT twice unresolved: comes to you with the verdict
- BLOCK: stops with reasons, never patches silently
- Crash mid-run: resumes from the last completed file
Four skill folders. One copy command.
Moonshot ships as four Claude Code skills: the one-shot orchestrator, the goal-lock gate, and the two engines it chains, llm-council and ebi-process. MIT licensed. No build step, no dependencies, no telemetry. Markdown files you can read in full before you install them.
- Clone the repo and copy the four folders from
skills/into~/.claude/skills/(global) or a project's.claude/skills/. - Restart Claude Code (or open a new session) so the skills register.
- Run it:
/one-shot <your idea>. Add "just do it" to skip the checkpoint and go fully autonomous.
Stop shipping first drafts of your plans.
Five advisors, six improvement rounds, and a drift gate between your idea and the prompt that builds it.
Get Moonshot on GitHub