/gauntlet

description: >-
  Runs a Gauntlet Loop: turns an ambitious goal into a builder/critic prompt
  judged against a concrete quality bar, confirms with the user, then leads
  the run until the output beats the bar or the user stops it — or exports
  a paste-ready /goal prompt for a fresh session. Use for long-horizon goals
  with an inspectable reference. Long-running; spawns many subagents, edits
  project files, and commits and pushes finished pieces to a feature branch.
disable-model-invocation: true
argument-hint: "<goal> [possible references or quality bars]"

Gauntlet

Turn an ambitious goal into a builder/critic improvement loop judged against a concrete quality bar, and run that loop until the output wins or the user stops it.

The user's arguments are the goal, plus any references or quality bars they mentioned. If no goal was given, ask for one.

Gauntlet prompts are modeled on Matt Shumer's prompt for the Claude-of-Duty game:

> I want you to build a first-person shooter at the level of the most recent > Call of Duty games. It should be utterly perfect, visually beautiful, with > every single thing done at AAA quality—from textures to physics to anything > you could think of. > > Fan out sub-agents and have sub-agents tackle each one individually so that > the game is utterly perfect. You should /loop on each item and have a > separate sub-agent check it visually to ensure it looks triple A. That > separate sub-agent should be a really harsh critic, and if it doesn't look > triple A, it should keep going. > > Don't stop until each sub-agent is utterly wowed with the quality when > compared with the actual Call of Duty game. It should literally compare them > side by side blind and say which one looks better. Do this in ThreeJS. /loop > until it's utterly perfect. Fan out sub-agents and ultracode.

Copy its register — short, concrete, goal-first, harsh about quality — not its literal tokens. `/loop` and `ultracode` there are one user's shorthand typed into a live session; as commands they mean something else entirely. Never carry slash commands or effort keywords into the prompt you write.

1. Choose the bar

Choose the strongest concrete bar that an agent can actually inspect and compare its work against. If the user has not supplied one, propose a useful comp or measurement that plays the same role for this task that real Call of Duty screenshots played for the Claude-of-Duty game.

Then resolve it into something a fresh agent with no prior context can open: file paths, a URL, a command that renders it, or screenshots saved to disk. A bar that cannot be resolved that way cannot be judged against — say so and fall back to the strongest one that can. Explain the chosen bar in one sentence.

2. Write the gauntlet prompt

Read `$CLAUDE_PLUGIN_ROOT/skills/init/references/constraint-doc-loading.md` and load the docs it lists. The bar defines what "good" means from outside; these define what this project requires from inside. The prompt carries both — the docs as repo paths.

Write a short prompt in that register (minimal is better here — the lead agent decides the specifics).

Give the lead agent the goal and the bar, but let it choose the approach. State the goal as a destination and do not enumerate its aspects, even when the user did: a list of aspects in the goal sentence becomes the decomposition, and that is the lead agent's call. Tell it to divide the goal into pieces that can be improved and judged independently, no more than the work needs — a piece is independent only if its builder can work without waiting on or overwriting another builder's files; anything less is merged or sequenced before the pieces are set. One builder takes each piece through every round: it gets the critic's verdict file verbatim and chooses the fixes, which the lead never writes for it. Every round, a separate critic with fresh context judges the piece.

Use the host's available agent capacity; sequence dispatches rather than drop pieces or reviews. Builders spawn no reviewers of their own; the critic is the review. Carry these dispatch rules into the prompt, and when the run's host is Codex, tell it to disable conversation inheritance for each critic (`fork_turns: "none"` when that option exists).

Each piece's critic prompt is written once, before its first round, kept on the progress page, and sent every round with only the artifact paths changed. It carries the resolved bar materials themselves — the paths, URL, or command — plus the artifact under judgment, and nothing from the builder: not its report, its reasoning, or its round history. A critic that cannot open the bar grades from memory, which is the builder-grades-itself failure this loop exists to prevent. The lead agent is the other route to that failure, because it reads every builder report and writes every critic prompt: so the remit is never narrowed after a verdict, what a builder found reaches a critic only as a file it can open and measure — never as a conclusion or an exclusion — and a verdict the lead disputes goes to the user as a disagreement, not back to the critic as a new rule.

Critics judge the artifact as a user would meet it — run, rendered, executed — never the builder's summary, and never source review alone when the work is visual or behavioral. Anything presented as computed — metrics, simulation output, live data — must trace to real computation: staged output that merely looks right is a gap, not a pass.

Each critic compares ours against the bar, never an older and a newer version of our own work, which measures the round, not the bar. Where blind A/B is practical, the critic gets both unlabeled, in random order, and learns which is ours only after recording its pick; tests and numerical thresholds need no blinding. It writes its verdict to its own file under `.claude/gauntlet/`, named by piece and round: what it opened and ran, every gap it found, biggest first, then one of two final lines: exactly