/gauntlet — Gauntlet Loop

Run an ambitious goal through a Gauntlet Loop: split, build, score against a real bar with a separate critic, fix the biggest gap, repeat. Do not stop after one "pretty good" pass. Default stop for quality is 10/10 on critical pieces.

Method source of truth: https://somethingbig.ai/gauntlet-loop
Reference prompt style: https://github.com/mshumer/Claude-of-Duty/blob/main/prompt.md

Usage

/gauntlet <goal>
/gauntlet <goal> — bar: <reference and/or acceptance criteria>

Examples:

• /gauntlet build a AAA-feeling FPS in Three.js — bar: modern Call of Duty screenshots
• /gauntlet rewrite the landing page — bar: linear.app and stripe.com homepage quality
• /gauntlet harden the auth service — bar: OWASP ASVS L2 + our test suite green + p99 < 50ms
• /gauntlet ship checkout — bar: acceptance criteria: guest checkout in <3 min; card + wallet; clear error copy; WCAG AA on payment form

If the user only says /gauntlet with no goal, ask once for the goal (and optional bar).

Core rules (never violate)

1. Goal, not architecture. Tell workers what to achieve. Do not prescribe full architecture, exact file trees, or step-by-step implementation unless the user already constrained them.
2. Hard bar only. "Make it amazing / production-ready / better" is not a bar. The bar must be inspectable. It may be any of:
   • Reference — screenshots, URLs, products, style samples, repos
   • Acceptance criteria — explicit checklist, tests, SLOs, security bars
   • Hybrid — both (common and preferred when available)
3. Split into smallest improvable pieces. The lead agent decomposes. Vague "improve everything" loops fail; focused pieces succeed.
4. Builder never grades itself. Every piece gets a separate critic with fresh context (no builder history, rationales, or excuses).
5. Inspect the real artifact. Critics look at pixels, running product, rendered pages, test output, or finished text — never a builder summary.
6. Score out of 10. Loop to 10/10. Every critic returns an integer SCORE: 0–10. PASS only at 10/10. Scores 0–9 are FAIL. Keep looping on each piece until it is 10/10, the user stops, or the user explicitly accepts a lower score after you show the board.
7. Score the bar, not a contest. The only pass condition is 10/10 against the bar. A reference (URL, screenshot, product) is evidence and a quality standard — use it to judge gaps. Do not report OURS vs REFERENCE winners. When the bar is criteria-only, check the checklist; do not invent a fake competitor.
8. Board first. Right after you parse the request, create gauntlet-progress.html from the skill template and open it in the browser. Do this before bar debate, the lead plan, or any builders. Keep the open tab alive with edit-in-place updates.

Agent harness mapping

If subagents are unavailable, simulate the same separation with clearly labeled BUILDER vs CRITIC phases and a full context reset between them (new prompt that omits builder history). Prefer real subagents.

Workflow

0. Parse the request

Extract:

• GOAL — destination outcome
• BAR — reference and/or acceptance criteria the user supplied
• CONSTRAINTS — stack, repo, time/compute budget, things not to touch

If the user only said /gauntlet with no goal, ask once — then go to step 1 as soon as you have a goal.

1. Create and open the progress board (do this first)

This is the first action of every gauntlet run. Do it immediately after parse. Do not establish the bar in depth, write the lead plan, or spawn builders until the board exists and is open in the browser.

Prefer: gauntlet-progress.html at the project root (or cwd).

1. Copy references/progress-template.html to gauntlet-progress.html (overwrite only if this run owns the file; if a board from a prior run is still open and relevant, update it in place).
2. Edit only the JSON in <script type="application/json" id="gauntlet-state">. Fill goal, provisional bar if known, as-of, and stub pieces. Write all prose fields in ASD-STE100 Simplified Technical English (see references/progress-html.md).
3. Do not hand-edit cards, columns, pills, or counts. The page script renders the kanban (and banner / latest / log) from that JSON on every load.
4. Open the file in the user's browser right away:
   • macOS: open gauntlet-progress.html (or open -a Safari gauntlet-progress.html)
   • Linux: xdg-open gauntlet-progress.html
   • Windows: start gauntlet-progress.html
5. Tell the user the path once. Later updates = small JSON edits only so the open tab keeps working (auto-refresh meta is already in the template).

How every later update works: open gauntlet-progress.html, change fields inside #gauntlet-state only, save. Never regenerate the HTML shell.

Status strings (exact): pending · building · review · pass · fail.

• pass = critic score 10/10 only.
• fail = scored 0–9.
• score: null shows —/10 until the first critique.

No OURS / REFERENCE / TIE fields. Load references/progress-html.md for the schema and STE rules.

2. Establish the bar

If the user gave a bar, restate it and say how it will be scored out of 10. Write the bar onto the open board (banner) as soon as it is set.

Classify the bar:

If they did not give a bar, find one as part of the task. Do not invent vague quality adjectives. Prefer:

• Real competitor / gold-standard products (URLs, screenshots, repos)
• Explicit acceptance criteria (checklist, tests, latency, a11y, security)
• User-supplied references (paste, paths, brands)
• Measurable engineering bars (tests, benches, security checklists, SLOs)

Explain the bar in one or two STE sentences (what it is + how scored), then proceed unless the user already overrode it.

Scoring guide (critics must use this spirit):

Be harsh. "Pretty good for AI" is at most mid-scale. Only 10 is PASS.

3. Lead plan (short)

Write a brief plan (keep it short — Matt's original prompt was minimal):

1. Restated goal
2. The bar (reference / criteria / hybrid) and how score is assigned
3. Decomposition into independent pieces (smallest units that can improve alone)
4. Which pieces can run in parallel
5. Progress board path (already open)
6. Target: 10/10 on every critical piece

Do not over-specify architecture. Pieces might be: a component, a scene prop, a section of copy, an API surface, a shader, a motion system, etc.

Then update the open board JSON: set each piece in pieces with status: "pending" (or the right status), fill detail / artifact, bump asOf / wave / round, prepend [wave 0] Board + plan. to waveLog.

4. Fan out builders

For each piece (parallelize independents):

Builder prompt template (fill in, keep focused):

You are a BUILDER in a Gauntlet Loop. Implement only this piece.

GOAL (overall): <goal>
PIECE: <piece name and scope>
BAR (do not grade yourself; aim for 10/10 against this): <bar>
BAR KIND: reference | acceptance criteria | hybrid
CONSTRAINTS: <constraints>
REPO / PATHS: <where to work>
PRIOR CRITIC (if any): SCORE n/10 · BIGGEST_GAP · NEXT_FIX — omit on round 1

Rules:
- Produce the real artifact (code, assets, copy, running feature).
- Do not claim victory. Do not write a self-critique or self-score.
- When done, report: what changed, where to inspect it (paths, URLs, commands),
  and how to render/run it for a critic.

5. Fan out critics (fresh each time)

After a builder finishes a piece, spawn a new critic. Never resume the builder as critic.

Critic prompt template:

You are a HARSH CRITIC in a Gauntlet Loop. Fresh context. No loyalty to the builder.

OVERALL GOAL: <goal>
PIECE UNDER REVIEW: <piece>
BAR KIND: reference | acceptance criteria | hybrid
BAR: <concrete bar>
ACCEPTANCE CRITERIA (if any): <checklist — one line per criterion>
REFERENCE (if any): <paths, URLs, screenshots, benchmarks used as the standard>
ARTIFACT: <paths, URLs, commands to see the real output under review>

Rules:
- Inspect the REAL artifact (run it, open it, read pixels, run tests). Never
  grade a summary.
- Score only against the bar. PASS means the bar is fully met for this piece
  (10/10). Do not declare OURS vs REFERENCE winners.
- If a reference is part of the bar, use it as the quality standard (side-by-side
  when useful) and name concrete gaps vs that standard.
- If the bar is criteria-only, check each criterion against the real artifact.
  Do not invent a reference product.
- Score the piece from 0 to 10 using the scale: 10 = full bar met for this
  piece; 8–9 = one clear gap; 5–7 = partial; 1–4 = weak; 0 = unusable.
- Be harsh. "Pretty good for AI" is not a 10.
- VERDICT is PASS only when SCORE is 10. Any score 0–9 is FAIL.
- Name the single biggest gap that blocks a higher score (empty only at 10).

Output EXACTLY this structure at the end:

SCORE: <0-10>/10
VERDICT: PASS
or
VERDICT: FAIL

BAR_KIND: reference | acceptance criteria | hybrid
CRITERIA_MET: <e.g. 4/5 or all or N/A>
BIGGEST_GAP: <one concrete, fixable gap — empty if SCORE is 10>
EVIDENCE: <what you inspected and what you saw>
NEXT_FIX: <single highest-leverage change for the builder — empty if SCORE is 10>

CRITERIA_MET is N/A when there are no explicit criteria.

6. Loop

For each piece:

build → critique (score /10) → if SCORE < 10: feed SCORE + BIGGEST_GAP + NEXT_FIX to builder → repeat

Orchestration rules:

• Prefer fixing the one biggest gap per round (depth over scatter).
• Re-criticize with a new critic after each fix (new score every time).
• Run independent pieces in parallel; serialize only when pieces share a conflict surface (same file, global style, shared protocol).
• Do not stop a piece at 8/10 or 9/10 by default. Continue until 10/10 unless the user stops or accepts a lower score on the board.
• If the user messages "stop", "ship it", or "good enough", stop cleanly and summarize scores — do not keep spending.

7. Smoothing pass (between major waves)

After a wave where several pieces hit 10/10 or stabilize, spawn one fresh agent:

You are a SMOOTHER. Do not redesign.
Inspect the full integrated result. Fix conflicts, inconsistent style, broken
integration seams, and anything that makes the whole feel like separately
improved parts. Preserve piece-level quality wins. Do not lower a piece that
already scored 10/10 unless integration forces a real regression (then flag it
for re-critique).

Then continue the next wave of gauntlet loops if any critical piece is below 10/10 or the whole product still fails the bar.

8. Stop conditions

Stop when any of:

1. User stops the run
2. Every critical piece is 10/10 against the bar
3. User accepts remaining scores below 10 after you show the progress board
4. Further gains are clearly below the cost (state this explicitly with current scores; do not silent-quit)

On stop, deliver:

• Final artifact locations / how to run
• Progress board path
• Per-piece scores (honest)
• What still blocks 10/10
• Highest-leverage next loops if they resume later

Domain tips (bar ideas)

Anti-patterns

• Stopping because the first draft "looks fine"
• Treating 8/10 or 9/10 as done without user approval
• Builder writing its own critique or self-score
• Critic that only reads the builder's report
• Bar = "professional" / "clean" / "modern" with no reference and no criteria
• Inventing a fake reference when the user only gave acceptance criteria
• OURS / REFERENCE / TIE winner framing instead of score against the bar
• One giant agent doing all pieces in one context until exhausted
• Fixed "do 3 iterations" and ship regardless of score
• Over-prescribing architecture in the lead prompt
• Progress board prose that is vague, promotional, or non-STE
• Ad-hoc progress HTML that ignores the skill template
• Regenerating full board HTML each wave instead of editing #gauntlet-state
• Hand-moving cards / editing pills so status ≠ column ≠ score
• Board without visible scores
• Planning or spawning builders before gauntlet-progress.html exists and is open
• Creating the board late "when there is something to show"

Minimal lead brief (what you optimize for)

Your own working brief should stay as short as Matt's Claude of Duty prompt in spirit:

First: create gauntlet-progress.html from the skill template and open it in the browser. Then achieve GOAL against BAR (reference and/or acceptance criteria). Split into the smallest pieces that can improve independently. For each piece, builder + separate harsh critic with fresh context. Critic inspects real output, scores 0–10, returns the biggest gap. PASS only at 10/10. Loop until critical pieces are 10/10 or the user stops. Keep the live STE progress page updated with scores. Fan out subagents hard.

Then do the orchestration — the skill is the loop, not a long essay to the user.

References