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 `beats the bar` when it found
none, or the biggest gap again, which sends the file back for another round.
A critic that could not open the bar or run the artifact has not judged it:
its final line names what it could not open or run, never `beats the bar`. A
gap is a way the bar beats ours; checks the bar cannot show — interaction,
robustness, window sizes — belong in the remit from round one or in the test
suite, never added round by round. The progress page copies each verdict's
final line from its file and links to the file. A piece is done when its
critic's file reads `beats the bar`.

Pieces that individually beat the bar can still disagree with each other, so
when every piece is done, a fresh integration critic judges the assembled
whole against the same bar, and any gap it names goes back for another round,
judged again by a fresh integration critic. The run ends when the integration
critic returns `beats the bar` or when the user stops it — and in practice it
is usually the second. Never treat a plateau as completion: if a piece's last two rounds
close no gap its critic can still name, report the plateau to the user and
keep working on the rest while they decide whether it is worth more compute.
Honor the host's permission, blocking, budget, and pause rules; record any
such suspension as incomplete, with a resumable checkpoint, never a pass.

If the project has a test command, the suite stays green: a piece is not done
while its tests fail.

The run never touches the default branch: before the first edit, the lead
agent creates and switches to a descriptively named feature branch (a
worktree made at confirmation already is one). Each piece, then the assembled whole, is committed, with
its verdict files and the progress page, when its critic returns `beats the
bar` and the suite is green — focused commits at judged milestones, never
one giant commit at the end — and pushed to that branch unless the user said
not to, never force-pushed. A failed push never blocks the run: note it on the
progress page and keep going.

Have the lead agent maintain a simple live progress page that shows the work
evolving over time — a rendered HTML page when the work is visual, markdown
otherwise — at `.claude/gauntlet-progress.html` or `.md`. Keep the goal, the
resolved bar, this prompt, every piece's critic prompt, and every piece's
rounds and verdicts in it, and write it before dispatching each round, so it
doubles as the anchor a later session resumes from.

Do not prescribe the architecture, exact decomposition, or a fixed number of
rounds. Keep the prompt short, but short is a budget for phrasing, not licence
to drop guarantees: one builder per piece, fresh-context critics, the frozen
remit, the bar materials in every critic prompt, ours-against-the-bar
comparison, blind and in random order where practical, the verdict file with
its evidence, ranked gaps, and two-way final line, judging the running
artifact and never passing what could not be opened or run, the anti-staging
rule, the integration critic, the green suite, the plateau and suspension
rules, the dispatch rules, the progress page, and the branch, commit, and push
rules all survive to the final draft. Short also has a number: keep the
prompt under 2,500 characters, because the /goal handoff
must fit this exact prompt plus an opening instruction and a completion
condition into either host's /goal 4,000-character message cap, and those need the rest.

## 3. Confirm and run

Show the user the bar and the prompt. Under Claude Code, recommend ultracode
for serious runs (`/effort` → ultracode): set it before approving "Start the run",
because the run starts immediately after, or in the fresh session for "Copy as /goal prompt".

Run `git status --porcelain`. If it reports anything, say so before asking:
this run rewrites the same files for hours with no per-change approval, and
uncommitted work will not survive it. Offer `/optimus:worktree` or committing
first — on the handoff path, before pasting: the danger window is the future
session, not this one.

Then use `AskUserQuestion` — header "Gauntlet", question confirming the start
of a long-running multi-agent run that spawns many subagents, edits files
without per-change approval, commits and pushes to a feature branch, and
consumes credits in proportion to how long it runs — with options "Start the
run", "Adjust first", "Copy as /goal prompt", and "Cancel". Offer Copy in both hosts, explaining that it prepares a prompt
for a fresh session in this host, or in a destination/model the user named,
without starting the run here. Honor an already supplied choice. Apply
requested adjustments and ask again. On "Cancel", stop.
On "Copy as /goal prompt", read
`$CLAUDE_PLUGIN_ROOT/skills/gauntlet/references/goal-handoff.md` and follow
it: the run is handed to a fresh session instead of executed here.

On "Start the run", execute the prompt yourself as the lead agent; this choice
does not itself request a native goal. Create one only if the user explicitly
asked for it, using the host's available controls.

Close on the outcome — `/optimus:commit` for uncommitted work, then
`/optimus:pr`, both in this conversation; then `/optimus:code-review` in a
fresh one — and say plainly whether the run beat the bar, plateaued, or was
interrupted, and whether the suite is green.