---
name: gauntlet-lite
description: Rewrite the user's rough request into a short, copy-ready Gauntlet Loop prompt for Claude Code at one-sitting scale — a goal stated as a destination, one real bar the agent can lose against (a number when one exists, otherwise a named reference artifact), the agent picks a handful of pieces and works them mostly one at a time, each piece gets a builder sub-agent and a separate fresh-context critic that inspects the real artifact (blind side-by-side against the reference, or re-running the instrument), names the single biggest gap, and sends it back; keep-or-revert each round; a scoreboard file; stop at target, plateau, or a hard cap. Same method as /gauntlet-prompt, a fraction of the compute. Use whenever the user says "gauntlet lite", "lite gauntlet", "light gauntlet", "mini gauntlet", "quick gauntlet", "small gauntlet", "hill climb", "hill-climb this", "iterate on X until Y", "optimize X until Y", "make X hit Y", or pastes an improvement request on an existing thing — faster, smaller, cheaper, higher score, fewer errors, less flaky, tighter copy, this page should look as good as that one — that should finish in one sitting rather than overnight. Bare "gauntlet" with no qualifier is /gauntlet-prompt; so is any greenfield build or anything that needs a fleet of parallel agents running overnight. A request that names an existing thing and one bar to beat is lite even when the user says neither word. Do not execute the underlying task; produce the prompt.
---

# Gauntlet Lite

Matt Shumer's Gauntlet Loop at one-sitting scale. The method is unchanged — give the
agent something real to lose against, and never let the builder grade itself — with
everything around it shrunk: a few pieces instead of fifty, rounds capped instead of
unlimited, a scoreboard file instead of a live page, no ultracode.

**You write the prompt. You do not do the work.** The output is a copy-ready prompt
the user pastes into a fresh Claude Code session and expects back in well under two hours.

## Lite vs. full

**Kept — this is the method, it doesn't shrink:**

- The goal is a destination, never an implementation.
- One real bar the agent can inspect and lose against. A number when one exists
  (p95, Lighthouse, CI time, word count) — numbers make keep/revert mechanical. A
  named reference artifact when the quality is visual, written, or felt (Linear's
  pricing page, a specific essay's paragraphs, a competitor's PDP). Never "better",
  "cleaner", "production-ready".
- The agent decides the pieces, not the user. "Make the page better" is too big;
  "make the hero compare favorably with Linear's hero" is a problem it can attack
  repeatedly.
- Builder and critic are separate sub-agents. The critic has fresh context, inspects
  the real artifact — the rendered page, the running code, the finished draft, the
  instrument's own output — never the builder's summary, compares it against the bar
  (blind when the medium allows), and names the single biggest remaining gap.
- Build, judge, lose, fix, repeat.

**Shrunk:**

- Pieces: the agent picks at most 3–4 and works them one at a time, or 2–3 in
  parallel only when they're obviously independent. Not a fleet.
- Rounds: a hard cap per piece and a plateau rule. In the full gauntlet a round
  budget is a bug; here it is the point — bounded time, bounded compute.
- Progress: one markdown scoreboard (round, piece, what changed, verdict, kept or
  reverted) instead of a live HTML page. Screenshots in a folder if the work is visual.
- Smoothing: one fresh-context coherence pass at the end, only if more than one piece
  was touched. Skip it for a single piece.
- Effort: no ultracode, default effort.

**Dropped:** the parallel fleet, unlimited rounds.

**Send the user to `/gauntlet-prompt` instead** when it's a greenfield build, the pieces
number in the dozens, or they want it running overnight. Don't promote a lite into a
full gauntlet mid-run — if it needs the fleet, it was never lite.

## The six ingredients

1. **A bounded goal, stated as a destination.** An existing thing and what it should
   become ("the pricing page should hold up next to Linear's", "p95 under 200ms").
   Never "add a cache", never "redesign the hero".
2. **One real bar.** A number with a target, or a named reference artifact the critic
   can put side by side with ours. The bar doesn't have to be reachable — Linear's
   page is fine as a bar even if we never beat it; the cap ends the run, not the bar.
   Numeric bars also stop at the target.
3. **How the critic inspects.** For a number: the instrument — profiler, benchmark
   script, test suite, eval set, Lighthouse — named explicitly, one command, same
   dataset or scenario every round; if none exists, the prompt's first step is to
   build a small repeatable one and record a baseline. For a reference: exactly what
   gets compared — the rendered page at named viewports next to the reference
   screenshots, the draft next to the reference paragraphs — labels stripped, critic
   says which is better and why ours lost.
4. **Agent-chosen pieces, few of them.** "Break this into the smallest pieces that can
   be improved and judged on their own — you decide, keep it to three or four, work
   them one at a time." For a pure numeric hill-climb, one piece is the normal case.
5. **One builder, one fresh-context critic per piece — both sub-agents.** The lead
   session only orchestrates and keeps the scoreboard; it never edits or judges, so
   the user's main context stays lean. The critic has no memory of what changed and
   reads nothing the builder wrote about its work.
6. **Keep-or-revert with a stop condition.** Each round on a piece: one change; the
   critic judges; keep if ours improved against the bar and the invariants held,
   revert otherwise. Stop a piece at the target (numeric), when the critic says ours
   wins or is indistinguishable (reference), after N consecutive rounds without a gain
   over a stated threshold, or at a cap on rounds or time. Put the numbers in the prompt.

**Hard rule — invariants.** Every lite prompt names what must not regress while the
bar is chased: tests pass, output byte-identical, every spec still present, analytics
still fire, accessibility score doesn't drop, nothing deleted to win. The critic checks
them every round. A win that breaks an invariant is a revert, not a win.

**Hard rule — discipline.** One change per round. Baseline recorded before the first
change — the first measurement, or the first set of screenshots next to the reference.
The builder never reports its own number or its own verdict; the critic does.

## How to work

### 1. Read what the user gave you

Pull out: the thing, what about it should change, any named bar or number, the
instrument if one exists, the invariants, hard constraints (stack, files off-limits,
platform), and a cap. Keep every constraint they stated.

### 2. Settle the bar

If the user gave a number or named a reference, use it. If the thing has a natural
number, propose one in two lines — baseline-relative ("half the baseline") or a known
standard (Lighthouse ≥ 90, p95 < 200ms, CI < 5 min, bundle < 150 kB) — and ask. If the
quality is visual or written, propose one specific real comparable (not "the best
SaaS pages" — "Linear's pricing page") and ask. Either way, write the prompt against
your best guess so they can paste immediately:

> No bar named. I'd put it against **Linear's pricing page** at 390 and 1440 wide —
> or do you have one in mind? Prompt below assumes Linear.

When both are available — copy that's too long *and* reads worse than a reference —
pair them: the number makes keep/revert mechanical, the reference keeps the agent
from winning by gutting the thing.

### 3. Settle the inspection

Numeric bar: name the instrument and the exact command. If none exists in the repo,
make building it step one — small, repeatable, same inputs, ideally under a minute a
run. Measure the real thing — a production build, a seeded database — never a dev
server. Noisy instruments (Lighthouse, anything on a laptop) need a median of 3 and a
keep threshold above the noise.

Reference bar: say what the critic opens and at what sizes, where the reference
screenshots or paragraphs live (the prompt's first step captures them if they don't),
and that it sees current vs. previous vs. reference with labels stripped.

### 4. Write the prompt

Short — 10 to 18 lines. Rewrite the wording for this specific goal; the skeleton is a
shape, not a form. The bracketed pairs are numeric | reference variants — pick one.

```
Iterate on [THING] until [METRIC hits TARGET | it holds up next to REFERENCE]. The
bar is [INSTRUMENT on DATASET/SCENARIO | REFERENCE, viewed at VIEWPORTS / these
paragraphs] — [run it | capture it alongside ours] before touching anything and
record the baseline as round 0. You only orchestrate: all editing and judging
happens in sub-agents.

Break this into the smallest pieces that can be improved and judged on their own —
you decide what they are, keep it to [3–4], work them one at a time. [Or, for a
single-number climb: treat it as one piece.]

Each round on a piece: send a builder sub-agent to make one change, then spawn a
fresh critic sub-agent that knows nothing about what changed. It [runs INSTRUMENT
itself on the real artifact and reports the number | opens the real rendered
artifact and the reference side by side, labels stripped, and says which is better],
confirms [INVARIANTS] still hold, and names the single biggest remaining gap. Keep
the change if [the number improved | ours won or closed the gap] and every invariant
held; revert it otherwise. Work on the gap next.

Keep a scoreboard in [FILE]: round, piece, what changed, [number | verdict], kept or
reverted. Stop a piece [at TARGET | when the critic can't pick ours apart from the
reference], after [N] rounds with no gain over [THRESHOLD], or at [CAP]. [If more than
one piece: when all pieces are done, one fresh sub-agent reviews the whole thing end
to end and smooths the seams — no redesign.] [Hard constraints.] Finish with the
baseline, where it ended, and the one change that moved it most.
```

### 5. Hand it over

One fenced code block. One line above naming the bar and the inspection you chose
(plus the question, if you guessed). At most one line below. No recap — they can read it.

## Things that quietly kill a lite run

- **A soft bar.** "Make it cleaner" gives the critic nothing to lose against, so it
  never loses, so the loop ends on round one.
- **The critic reading a summary.** If it grades the builder's write-up instead of the
  page, the number, or the draft, you've built an expensive way to compliment yourself.
- **A different scenario each round.** Noise looks like progress. Same dataset, same
  inputs, same viewports, same machine state.
- **No baseline before the first change.** Then nothing afterward means anything.
- **The builder reporting its own number or verdict.** It ran the measurement it
  wanted to see.
- **A bar with no invariants.** The agent wins by deleting things.
- **Two changes in one round.** You can't tell which one helped, so you can't revert
  the one that hurt.
- **The user listing the pieces.** Deciding the decomposition is the thing the model is
  best at; a prescribed list turns the gauntlet into a checklist.
- **Promoting a lite into a full gauntlet mid-run.** If it needs fan-out, it was never
  lite — stop and use `/gauntlet-prompt`.

## Scope

Write the prompt only. If the user wants the work done too, they'll paste the prompt into a
fresh session with a clean context window — that is the point. Don't start running the
loop inside the same conversation where you designed it.