--- name: gauntlet-prompt description: Rewrite the user's rough request into a short, copy-ready Gauntlet Loop prompt for Claude Code — an ambitious goal, one concrete quality bar the agent can inspect and compare against, sub-agents fanned out over independently-judgable pieces, a harsh fresh-context critic that grades the real running output blind, a smoothing pass, a live progress page, and /loop until it wins. Use whenever the user says "gauntlet", "gauntlet loop", "gauntlet prompt", "gauntletize this", "make this a gauntlet", or pastes a rough build/write/design/research/analysis request and wants it turned into a maximally ambitious prompt that keeps looping against a reference until the bar is beaten. Works for ANY domain — apps, websites, games, writing, design, marketing, research, data, backend, ops — not only games. If the user says lite/light/mini/quick/small gauntlet, or wants an existing thing improved in one sitting rather than an overnight fleet, use /gauntlet-lite instead. Do not execute the underlying task; produce the prompt. --- # Gauntlet Prompt Turn a rough ask into a short prompt that makes a Claude Code agent keep beating its own work against a bar it cannot argue with. **You write the prompt. You do not do the work.** The output of this skill is a copy-ready prompt the user pastes into a fresh Claude Code session. The method comes from Matt Shumer's essay "How to Run a Gauntlet Loop" (https://somethingbig.ai/gauntlet-loop). Fetch it when you want the reasoning behind a choice. ## Why this works Ordinary prompts let an agent produce one decent result and stop, because the agent grades itself and "reasonable" always wins. A Gauntlet Loop removes both escape hatches: it gives the agent an external bar it can inspect, and it puts the judging in a different agent with no memory of why the work was built that way. Everything below exists to serve those two things — keep that in mind rather than following the template mechanically. ## The seven ingredients Every Gauntlet prompt you write carries these. If one is missing, the loop leaks. 1. **An ambitious goal, stated as a destination — not an architecture.** Say what it should be, never how to build it. Modern models decide decomposition better than a spec written in advance. 2. **One concrete bar the agent can actually inspect.** A named real thing, a measurement, or a reference artifact. Not "amazing", not "production-ready". 3. **Self-decided decomposition.** "Break it into the smallest pieces that can be improved and judged on their own — you decide what the pieces are, not me." 4. **Fan-out.** A sub-agent per piece, working in parallel. 5. **A separate critic with fresh context that inspects the real artifact.** Never the builder's summary. Blind A/B against the bar where the medium allows it. When ours loses, it names the single biggest gap and sends the builder back. 6. **No fixed number of rounds.** `/loop` until the critic is genuinely wowed or the user stops the run. Plus a smoothing pass between major waves so the separately-improved pieces feel like one thing. 7. **A live progress page** the user can open from their phone, and `ultracode`. ## How to work ### 1. Read what the user actually gave you Pull out: the goal, any named reference or comparable, any hard constraints (stack, format, length, platform, deadline, brand), and how ambitious they're being. Keep every constraint they stated — those are load-bearing, and dropping "in Three.js" or "must run on Vercel" wastes a run. If the request is a vague one-liner ("make me a CRM"), raise the ambition yourself. The whole point of a gauntlet is a target higher than the agent would pick alone. ### 2. Settle the bar — this is the part worth slowing down for **If the user named a bar** (Age of Empires, Linear, Stripe's docs, a competitor's site, a specific essay), use it. Don't second-guess it. **If they didn't**, propose 2–3 concrete candidates *and* ask them directly whether they have something in mind. Keep it to a few lines — they shouldn't have to read an essay to answer: > No bar named yet, so here's what I'd compare against — but do you already have > something in mind? > - **Linear** — for interaction feel, keyboard-first speed, and empty states > - **Stripe Dashboard** — for information density done calmly > - **A p95 < 200ms cold-load budget** — if speed is the thing that matters most > > Say the word and I'll write it against whichever, or a mix. What makes a good bar: - **It can be inspected.** A screenshot, a running product, a rendered page, a published article, a test suite, a number. If the critic can't put it side by side with our output, it isn't a bar. - **It's specific and real.** "The best SaaS onboarding" is not a bar. "Superhuman's onboarding" is. - **It's out of reach.** A bar you can hit isn't doing its job. Matt's game never beat Call of Duty; Call of Duty stopped it from settling at "pretty good for AI." ### 3. Say what the critic looks at This is the ingredient most often botched outside of games, so be explicit about the medium. The critic must grade the real thing: - App or site → the running app in a browser, screenshots at real viewport sizes - Game → the actual playable build - Writing → the finished draft, read end to end - Design → the rendered comp or exported asset - Research or analysis → the finished report plus the sources it cites - Backend or infra → the passing test suite, real latency numbers, failure injection - Marketing → the live page, the actual creative, the real funnel numbers Blind A/B ("show it both without saying which is ours") works whenever both artifacts can be viewed side by side. When they genuinely can't be — a latency budget, a test suite — swap it for the measurement and keep everything else. ### 4. Write the prompt Short. Matt's original was a handful of sentences and it produced 55,000 lines. Every sentence you add that specifies *how* replaces the model's judgment with yours. Use this as a skeleton, not a form to fill in — rewrite the wording so it sounds like it was written for this specific goal: ``` I want you to build/write/design [GOAL] at the level of [THE BAR]. It should be utterly [the quality words that fit this domain], with every single thing done at that standard — from [dimension] to [dimension] to [dimension] to anything else you can think of. Break [the thing] into the smallest pieces that can be improved and judged on their own — you decide what the pieces are, not me. Fan out sub-agents and have each one tackle a piece individually. /loop on each piece, and have a separate sub-agent with fresh context inspect [the real artifact — never the builder's summary] and judge it against [THE BAR]. That critic should be a genuinely harsh critic, and if it doesn't meet that standard, it should keep going. Don't stop until every critic is wowed compared with [THE BAR]. It should compare them side by side blind, say which one is better, and when ours loses, name the single biggest gap and send the builder back in. No fixed number of rounds. Between major waves, spawn one fresh agent to [experience the whole thing end to end] and smooth everything into one coherent thing. Keep a simple live progress page updated as you work so I can watch it evolve. [Any hard constraints the user gave: stack, platform, format, length.] /loop until it's [bar-level]. Fan out sub-agents and ultracode. ``` ### 5. Hand it over Output the prompt in one fenced code block so the user can copy it in a single motion. Above it, one or two lines: which bar you chose and why. Below it, at most a line about what to expect or watch. No summary of the method, no bullet-point recap of what the prompt contains — they can read it. Then, if it's a long-running build, mention they should turn on ultracode with `/effort` and just leave it alone. Interrupting a gauntlet every twenty minutes is what the progress page exists to prevent. ## Things that quietly kill a gauntlet - **A soft bar.** "Make it beautiful" gives the critic nothing to lose against, so it never loses, so the loop ends on round one. - **The builder grading itself.** It has seen every decision and can justify all of them. Fresh context is the entire mechanism. - **The critic reading a summary.** If it grades the builder's write-up instead of the artifact, you've built an elaborate way to compliment yourself. - **A round budget.** "Do 3 passes" caps quality at whatever 3 passes reaches. - **Prescribing the decomposition.** Listing the workstreams yourself throws away the thing the model is best at. - **Length.** A long prompt reads as a spec, and the agent starts implementing your plan instead of pursuing the goal. ## Scope Write the prompt only. If the user wants the work done too, they'll paste the prompt — that's a fresh session with a clean context window, which is the point. Don't start building inside the same conversation where you designed the loop.