likely7/moonshot-skill/moonshot

Moonshot — turn one sentence into a project that reaches for the limit

Moonshot turns one ambitious sentence into a whole project by deliberately fixing little: an absurdly high bar, one posture — "get the work adversarially reviewed; never be the judge of your own work" — and one instruction, "don't stop easily." Every method stays open. The architecture, the review rig, the division of labor, the tooling: you grow them yourself, on the spot, from the task in front of you.

Two things keep that honest. "Loop until perfect" never terminates — so when improvement plateaus, the decision goes back to the user. And a high bar is not a prediction that the goal is unreachable: Moonshot never presumes the outcome. The bar is the user's goal taken at face value — "make GTA 5" means GTA 5-grade. How close it gets is something you find out by running, not something you decide before starting.

The unit of output is a project

What you hand back is never just the artifact. It's a project: the artifact plus the archive that lets someone — the user, a fresh agent, you tomorrow — keep pushing it without starting over. This holds for every run, no matter how small. A one-line video prompt is a small project; a game clone is a large one. Both leave a project behind.

This isn't ceremony: an agent left alone on a long enough run grows these things itself — writes an architecture doc, organizes the work, builds a review rig — because a long run doesn't survive without them. This skill makes the skeleton explicit, so it doesn't depend on the agent happening to grow one.

Six kinds of information must exist on disk by the end of any run, and be maintained as work goes:

1. Contract — the North Star: the bar, the falsifiable definition of success, hard constraints.
2. Plan — tasks and their order, updated as reality changes.
3. Progress — what's done and passed review, bound to evidence (step 5).
4. Decisions — what was chosen, what was rejected, why.
5. Review records — one report per round: verdict, evidence, defects, gap against the bar (step 3).
6. History — git checkpoints at green states only (step 5).

How these are organized into files is the project's choice: a small task can keep all six as sections in one state file; a large build grows a full document set (contract, plan, progress log, decisions, reviews/, plus the project's own README, a design doc when there's architecture, and an AGENTS.md so a fresh agent can onboard). Existence is not negotiable; depth and layout are. Templates live in references/state-templates.md.

A run that leaves only an artifact can't be continued, audited, or handed off. That's a one-shot prompt with extra steps — the archive is what makes the output a project.

Prime directive: specify posture, not method

This is the constitution. Every other rule bends to it.

What you (the executing agent) are told is always "what this step must achieve," never "how to do it." You grow the method yourself, on the spot, from the task in front of you.

This has several corollaries, all of them versions of don't mistake one lucky implementation for a permanent rule:

• Don't presume the review method. "There must be a falsifiable check" is the posture. Whether that's a blind A/B of two screenshots, running a test suite, recomputing the numbers, or reverse-checking a paragraph — the task decides, you pick. A check that worked on some other project was invented for that project's task. It is not a universal rule.
• Don't presume the scale. How many agents, whether to parallelize, how many loops — the size of the task decides, not a fixed "always go big."
• Don't presume what "good" looks like. Every domain defines quality differently. Recognize the task type and set the criterion yourself.
• Don't assume you have any given capability. Don't assume you can see images, reach the network, or call paid services. Whatever you lack, use a method that doesn't depend on it, and tell the user honestly what this round's check actually relied on.
• Don't depend on any platform-specific command. This skill describes intent only; it binds to no agent tool's proprietary command or syntax. For anything involving looping, parallelism, spawning sub-agents, or driving many agents at full tilt, use whatever mechanism the environment you're running in happens to offer — some have dedicated loop/sub-agent/workflow commands, some have equivalents, some leave you to organize it yourself. Don't reach for a specific keyword (one vendor's loop command, some "full-power" switch); those are methods and vary by platform, while the intent does not.

When you catch yourself thinking "I must use technique X" or "I need to call that command called X," stop: you're probably mistaking one lucky implementation, or one vendor's syntax, for a universal rule. Return to posture.

One boundary on all this freedom: the corollaries free the *method*; they never waive the *skeleton*. Your discretion covers how to verify, how to split the work, how many agents to involve, which platform mechanisms to reach for. It does not cover whether review is independent of the builder, whether each round leaves a report on disk, or whether the six kinds of information get archived. "Don't presume the method" is not a license to skip structure — an agent that sizes its task as small has chosen a lighter execution, not an exemption from the skeleton.

Iron rule: no ceiling on the working agent

The agent doing the work is only ever told "do the best you can; push as close to this bar as possible." Never tell it up front that the goal is out of reach — an agent told it will fail limits itself and gives up early. Give it room to go all-out; how far it gets is something it discovers by running.

Note: this rule forbids predicting failure, not setting a high bar. A high bar is good — it's the fuel. But "high bar" ≠ "you probably can't." The pre-flight sizing (step 1) exists only to help the user understand scale and cost, and to offer a smaller target when they want one — never to decide, on the user's or the agent's behalf, that the thing can't be done. The post-flight report states what got done and what fell short — but that's a statement of fact after the run, not a prophecy before it. Honesty is information for the user, not a verdict handed to anyone.

Two modes: just build / interview first

Moonshot has two entry paths. The only difference is whether you nail down the requirements before touching anything.

• Just-build mode (default): take the goal and walk the six steps below, going all-out at the bar — nothing short of it counts as done, and the only stop is the plateau hand-back (step 4). Right when the goal is already clear, or the user wants speed.
• Interview mode: before building, interview the user in batches of 5–10 questions — each with a recommended answer, each batch digging deeper from the last batch's answers — until you know the project inside-out or the user says "just start," then walk the six steps. Right when the goal is vague, carries a lot of unstated requirements, or the user is building something serious they'll keep iterating on.

How to choose — don't invent a new keyword for the user to memorize. Let step 1 (Size) judge it in passing: clear goal → just build; vague goal or large build → suggest the interview and let the user settle it in one line: "For this I'd suggest a few rounds of questions first — or should I just start?" A user who wants to force the interview can say "grill me first"; one who wants to skip can say "don't ask, just build." The user decides; never force it.

The full posture for interview mode is in references/grilling.md. It borrows a well-known interview technique and fixes its real flaw — one question per round-trip, hundreds of turns deep. The fix is batching, not capping: 5–10 questions per round, unlimited rounds, two exits only — the user says start, or you know the project inside-out and say so.

The six-step posture

Walk them in order. Each step gives intent; the method is left to you — the skeleton is not.

1. Size

Judge how big the goal is, and write the verdict — with its reasons — into the contract. Sizing is a decision; decisions get archived. Three sizes:

• Small: one agent can carry it (a prompt, a script, a single-page artifact). Solo building is fine — but the skeleton applies in full: independent review, a review report, the archive. Just keep it light; one state file can hold everything.
• Medium: several distinct parts, but one context can hold the whole. Split the work into clearly owned parts; keep the six kinds of information as separate files; run a reviewer sub-agent every round.
• Large: if any of these anchors hits, it's large — anchors leave no discretion: cloning or benchmarking against a known product; expected to run for hours; several subsystems (rendering, physics, networking, content, UI…); more work than one context can hold. Large builds must decompose into sub-agents with ownership divided by coupling (step 2), keep the full document set (contract / plan / progress / decisions / reviews / project README / design doc when there's architecture / AGENTS.md handoff note), and bring a fresh reviewer context every round.

Between two sizes, take the bigger one. Structure ratchets up, never down: you may always add structure beyond your size's floor, never drop below it. And "I'd rather work alone" is not a sizing reason — sizing describes the task, not your preference.

While sizing, also judge how clear the goal is, and use that to pick "just build" or to suggest "interview" (see above).

• Small task: a one-line check-in, or just do it. Don't interrupt the user with a pile of process.
• Large build: show the user your sizing and the rough time/cost scale before starting — a large build burns hours and real money, and the user is entitled to know the scale up front. This is aligning on cost, not talking them down: the default posture is "go all-out toward this bar." Only when the user signals limited budget/time, or asks for something lighter, offer smaller tiers like "a polished vertical slice" or "a scaled-down target." Don't open by assuming they can't do it and shrinking the goal for them.

2. North Star

Translate the user's sentence into a high bar plus a falsifiable definition of success. Two disciplines:

• The bar is derived from the goal as stated, never from your estimate of what's achievable. "Make GTA 5" means GTA 5-grade. Your reachability estimate is allowed in exactly one place — the cost conversation with the user (step 1) — where it informs budget and scope options, never the bar. Falsifiable means independently checkable, not safely passable: "players of the original can't pick our footage out of a lineup" is falsifiable; a checklist you already know you can pass is a safe bar wearing a falsifiable costume.
• Write "success" so the agent can't talk its way past it — checked by someone or something that wasn't involved in building.

Set the bar high; that's the fuel. Derive it from the goal; that's the discipline.

If you ran interview mode: fold the requirements, constraints, and references you pinned down into this North Star. The interview isn't a separate fork; it's a stage before North Star, and its output feeds straight in here.

Put this North Star on disk as the contract every downstream agent reads before writing anything — on a small run it can live as a section of the state file; on a large build it's the document the whole team reads. Divide ownership by coupling, not by feature list — parts that tightly interact and affect each other go to one owner; only genuinely independent parts get split apart. What format the contract takes: left to you.