Nil Ni / BlogHome
Nil Ni9 min read

The Gauntlet Loop: My Claude Code Prompt for Polishing Any Product

I adapted Matt Shumer’s Gauntlet Loop for QuizGen.ai. Here is the reusable Claude Code Opus 5 prompt—and the guardrails that keep it useful.

ai

I stole a good idea, made it more specific, and pointed it at QuizGen.ai.

Matt Shumer calls the pattern the Gauntlet Loop: one group of agents builds, a separate group judges, and the work keeps going back through the loop until the judges stop finding excuses to reject it.

That sounds obvious. It is not how most people use coding agents.

The usual prompt is: “Make this page better.” The agent changes a gradient, rounds three corners, announces victory, and goes home. The Gauntlet Loop replaces vibes with an adversarial acceptance system.

I adapted it for QuizGen and found it extremely useful. My version asked Claude Code to treat every major product surface as its own assignment, give each surface to a dedicated owner agent, and pair that owner with a harsh visual critic. The critics had to judge real screenshots in light and dark mode, desktop and mobile, against Duolingo, NotebookLM, and Linear.

If QuizGen lost the comparison, the work was not done.

That last sentence changes the behavior of the whole system.

What the Gauntlet Loop actually is

The loop has four parts:

  1. Decompose the product into surfaces. A homepage, onboarding flow, editor, dashboard, pricing page, and mobile experience are different problems. Treating them as one blob produces generic work.
  2. Give every surface one owner. The owner understands that surface end to end: its job, states, edge cases, responsive behavior, and implementation.
  3. Use an independent critic. The critic does not grade its own homework and does not quietly fix the work. It gathers evidence, compares, rejects, and explains why.
  4. Repeat against a real bar. The owner fixes the critic’s specific findings. The critic captures fresh evidence and judges again. “Looks good to me” is not a passing test.

It is a writer–verifier pattern with teeth.

This is a particularly good fit for Claude Opus 5. Anthropic’s Opus 5 prompting guide highlights its strengths in long-horizon agentic coding, code review, vision work, and multi-agent coordination. Those are exactly the muscles this workflow uses.

What I changed for QuizGen

The original idea is general. The useful part is making the acceptance bar painfully concrete.

For QuizGen, I specified:

  • the reference products and what each one represented;
  • every important product surface;
  • the exact screenshot matrix: 1440 desktop and 390 mobile, both light and dark;
  • production-style data rather than toy fixtures;
  • a separate owner and critic for each surface;
  • non-negotiable design tokens and component rules;
  • honesty rules banning fake stats and unsupported claims;
  • engineering boundaries around tests, API contracts, Stripe, and deployment;
  • an explicit passing verdict: “ship it, it beats the reference.”

The reference products were not there to be copied. They were there to remove ambiguity:

  • Duolingo for game feel and momentum;
  • NotebookLM for grounded trustworthiness;
  • Linear for interface precision.

“World class” means nothing by itself. “Put these screenshots side by side and tell me which product looks more deliberate” gives the critic something it can actually judge.

Why the independent critic matters

A builder agent is biased toward completion. Once it has spent time on an implementation, it wants the implementation to be accepted. Humans do this too; we just have better excuses.

A critic with no ownership of the code has a cleaner incentive. Its job is not to be nice or preserve the builder’s feelings. Its job is to find where the result loses.

The critic should judge evidence, not a summary written by the builder. For UI work, that means fresh screenshots from the real app. For an API, it might mean contract tests, latency traces, and failure fixtures. For a content workflow, it could mean a blind comparison, source checks, and examples of unsupported claims.

The medium changes. The structure does not:

owner → evidence → critic → verdict → fix → new evidence → new verdict

The general-purpose prompt

Replace the bracketed fields. Delete any section that does not apply. Specificity helps; bureaucracy does not.

I want [PRODUCT] ([URL], [REPOSITORY OR WORKSPACE]) brought to the level of the best products in its category.

OUTCOME
[Describe the user-visible and technical outcome. Be concrete about what “excellent” means.]

REFERENCE BAR
Use these products as quality references, not as designs to copy:
- [REFERENCE A] for [QUALITY]
- [REFERENCE B] for [QUALITY]
- [REFERENCE C] for [QUALITY]

Every user-facing surface should feel deliberate: information hierarchy, layout, spacing, typography, interaction, responsive behavior, accessibility, copy, empty states, loading states, error states, and recovery paths.

SURFACES
Fan out owner sub-agents only across genuinely independent surfaces. Give each owner exactly one surface end to end:
- [SURFACE 1]
- [SURFACE 2]
- [SURFACE 3]
- [SURFACE 4]

Before editing, inspect the repository instructions, current architecture, design system, existing components, test setup, Git state, and production constraints. Preserve unrelated work. Owners may share findings, but they must not overwrite one another’s files or expand their scope silently.

GAUNTLET LOOP
Pair every owner with a separate harsh-critic sub-agent. The critic must not implement the surface it judges.

For each surface:
1. The owner maps the complete user journey and all meaningful states.
2. The owner implements the smallest coherent improvement that meets the stated bar.
3. The owner runs the required validation and produces fresh evidence.
4. The critic reviews the evidence without relying on the owner’s self-assessment.
5. The critic compares the result blindly, side by side, with equivalent evidence from the reference products.
6. The critic states which result is better and exactly why, using observable details rather than taste words.
7. If our product loses, the critic returns a prioritized failure list with specific corrections.
8. The owner fixes those failures and produces new evidence.
9. The critic re-judges from scratch.

EVIDENCE
Use evidence appropriate to the surface:
- UI: production-style screenshots at [DESKTOP WIDTH] and [MOBILE WIDTH], in light and dark mode, including default, empty, loading, error, success, and long-content states where relevant.
- Interaction: real browser flows, keyboard behavior, focus states, motion, and reduced-motion behavior.
- API or backend: contract tests, representative fixtures, error cases, retry behavior, performance measurements, and data-integrity checks.
- Content or AI output: blind comparisons, citations, source verification, hallucination checks, and representative edge cases.

A critic cannot pass work based on descriptions, mocked screenshots, stale artifacts, or tests it did not run.

CRITIC VERDICT
The critic must return exactly one verdict:
- FAIL — followed by the specific reasons our product loses and the minimum changes required for another review.
- SHIP IT — followed by the evidence that it meets or beats the reference bar.

HARD RULES
Failing any hard rule is an automatic FAIL:
- Design system: [TOKENS, TYPEFACES, BORDER/SHADOW/RADIUS RULES, COMPONENT CONSTRAINTS].
- Product truth: no fake numbers, fabricated testimonials, unsupported claims, fake activity, or promises that are not implemented. If data is unavailable, do not render the claim.
- Focus: each screen has one unmistakable primary action unless its documented job genuinely requires otherwise.
- Accessibility: semantic structure, keyboard access, visible focus, useful labels, sufficient contrast, and reduced-motion support.
- Performance: [BUDGETS OR RELEVANT THRESHOLDS].
- Validation: run [TYPE CHECK], [LINT], [UNIT TESTS], [INTEGRATION TESTS], and [E2E TESTS] after changes that can affect them. Report exact commands and results.
- Contracts: do not change [PROTECTED API, BILLING, AUTH, DATA, OR GATING CONTRACTS].
- Scope: preserve unrelated changes and do not add dependencies, migrations, production configuration, or new product promises without clear need and authorization.
- Shipping: do not commit, push, open or merge a PR, deploy, or operate on production data unless the task explicitly authorizes that action.

STOP CONDITION
Continue the owner–critic loop until every surface receives SHIP IT.

Cap each surface at [MAX ROUNDS] review rounds. If a surface still fails after that, stop changing it and report the exact blocker, evidence, attempted fixes, and decision needed. Do not thrash pixels or burn tokens to manufacture agreement.

FINAL REPORT
Report:
- each surface and its owner;
- review rounds and final critic verdicts;
- before/after evidence locations;
- meaningful changes made;
- validation commands and results;
- unresolved blockers or unverified risks;
- whether the work is local, committed, pushed, in a PR, deployed, or published.

Keep progress updates brief. Make routine implementation decisions yourself. Do not declare the overall task complete until every surface has either passed the gauntlet or has a clearly evidenced blocker that requires a human decision.

The parts you should customize

Do not paste the prompt unchanged and expect magic. Fill in these five things properly:

1. Name the surfaces

“Improve the app” is lazy input. List the actual journeys: acquisition, signup, creation, core use, review, billing, account management, and return behavior. A surface should be small enough for one agent to understand and large enough to own a meaningful outcome.

2. Choose references by quality

Do not say “make it like Apple.” Say what you are borrowing as a standard: onboarding clarity, information density, motion restraint, trust, speed, or game feel. Otherwise the agent may produce a tasteful clone with no idea why it exists.

3. Define evidence before implementation

Screenshots are excellent for visual work, but they are not a universal eval. A beautiful retry system can still duplicate payments. Match the evidence to the risk.

4. Write real hard rules

Hard rules are for invariants, not preferences. API contracts, billing behavior, data integrity, accessibility, truthfulness, design tokens, and test gates belong here. “Make it feel premium” does not.

5. Put a ceiling on the loop

Matt’s framing is intentionally relentless. I like that. I still add a maximum number of rounds per surface because critics can become performative and agents can churn forever. A blocked report after four serious attempts is more useful than round eleven of shadow-angle philosophy.

When I would use it

Use the Gauntlet Loop for:

  • a product-wide polish pass;
  • a redesign with multiple independent surfaces;
  • a high-stakes launch;
  • an unfamiliar codebase with uneven quality;
  • work where screenshots or other artifacts can support an honest comparison.

I would not use it for a three-line bug fix. Spawning a miniature design court to adjust one padding value is agent cosplay.

My recommendation

Try this with Claude Code and Opus 5 on one important surface first. Give the critic real evidence and permission to reject the work. If that goes well, expand it across the product.

The clever part is not “use more agents.” More agents can create more noise at impressive speed.

The clever part is separating ownership from judgment, making quality observable, and refusing to let the builder grade its own homework.

That is the Gauntlet Loop. I used it on QuizGen, it worked extremely well, and I recommend stealing it too.