Gauntlet Loop a Developer Landing Page

Use builder and critic subagents to iteratively polish a landing page.

Introduction

30 Second Summary

When you review your own work, you're biased. You remember how hard a tricky section was, so you give yourself a pass on flaws a stranger would spot in seconds.

In this project, you will use the Gauntlet Loop technique in Claude Code to build a developer landing page. You'll write a quality bar and create competing builder and critic agents that iterate until the page meets every criterion.

What You'll Build

You'll demo a developer landing page that was built entirely by AI agents competing against a quality bar you wrote, with a workbench log showing every round of improvement.

By the end of this project, you'll have:

A quality bar specification detailed enough that you can point any future critic agent at it and get a deterministic pass/fail verdict.
A builder/critic subagent pair that separates creation from evaluation, so the builder never grades its own work.
A Gauntlet Loop workflow you can trigger with a single /goal command and watch converge autonomously until the critic picks the generated page.
Secret Mission: Add a Lighthouse gate so the critic enforces accessibility and performance scores alongside spec fidelity.

Are there any prerequisites?

This project assumes you're comfortable with Claude Code basics like running prompts and navigating the terminal. You'll need a paid Claude plan (Pro, Max, Team, or Enterprise) with Claude Code access.

Before We Start

Before we dive in, let's lock in what you're about to build and why it matters to you.

Set Up the Project and Write the Quality Bar

The Gauntlet Loop technique depends on one thing above all else: a concrete, inspectable quality bar. Without one, the critic agent has nothing specific to compare against. It invents its own comparison criteria and approves everything.

In this step, you'll create the project directory and write a detailed specification for a developer landing page. This spec needs to be precise enough that two people reading it independently would agree on whether a given page passes or fails each criterion.

In this step, get ready to:

Create the project directory structure with folders for specs, agents, and source code.
Write a detailed quality bar specification for a developer landing page.
Initialize a Git repository and commit the scaffold.

Create the project scaffold

The Gauntlet Loop needs a clear separation between specifications, agent definitions, and output. You'll create four things: a spec/ folder for the quality bar, a .claude/agents/ folder for subagent definitions, a src/ folder for the landing page output, and a workbench.md progress tracker at the root.

Move to your Desktop by running this command:

cd ~/Desktop

Create the project folder and its directory structure, then move into it by running these commands:

mkdir -p gauntlet-loop/spec gauntlet-loop/.claude/agents gauntlet-loop/src
cd gauntlet-loop

Confirm the directories exist by running:

ls -a

You should see .claude, spec, and src listed in the output.

Not seeing all three directories?

The .claude directory starts with a dot, which makes it hidden by default. The -a flag in ls -a shows hidden files. If you don't see it, make sure you used -p in the mkdir command to create nested directories.

Help me troubleshoot my project directory structure.

The workbench.md file tracks every builder/critic round as the loop runs. It starts empty and fills up as iterations happen.

Create the progress tracker by running this command:

cat > workbench.md << 'EOF'
# Gauntlet Loop Workbench

Progress tracker for builder/critic iterations.

## Rounds

(No rounds yet.)
EOF

What is workbench.md?

The workbench pattern comes from the Gauntlet Loop technique. You tell the agent to create a simple progress document and update it as it works. This gives you a human-readable log of what changed each round and why.

Verify the file was created correctly by running:

cat workbench.md

You should see the heading "Gauntlet Loop Workbench" and the empty "Rounds" section.

Write the quality bar specification

The most common Gauntlet Loop failure mode is a vague bar. If you write "make it look professional" or "award-winning design," the critic has nothing concrete to inspect. It will approve almost anything.

Your quality bar needs exact hex values, pixel sizes, breakpoint numbers, and named content. Specific enough that a critic agent can read each criterion and make a binary pass/fail judgment.

Why does the bar need to be this specific?

The critic agent is going to read this document and compare it section by section against the HTML page the builder creates. Vague criteria like "clean layout" let the critic approve anything that looks roughly okay.

Concrete criteria like "3-column grid at 1024px, 2-column at 768px, 1-column below 768px" give the critic something to actually verify. The more inspectable the bar, the more useful the critic's feedback becomes.

Open spec/quality-bar.md in your code editor and paste the following as the first two sections:

# Quality Bar: Developer Landing Page

## 1. Layout Structure

The page is a single-page layout with sections in this order:

- **Hero**: Full-width section with a headline, subheadline, and a primary CTA button. Centered content with max-width of 960px.
- **Features Grid**: 3-column grid of feature cards. Each card has an icon placeholder, a title, and a short description.
- **Code Snippet Showcase**: Dark-themed code block with syntax-highlighted text and a copy button.
- **Testimonials**: Row of 3 testimonial cards with a quote, author name, and role each.
- **CTA**: Full-width dark section with a headline and a centered primary CTA button.
- **Footer**: Copyright text and 3 navigation links.

## 2. Color Palette

- Primary: #6C63FF (violet)
- Primary hover: #5A52D5
- Background: #0F0F1A (deep navy)
- Surface: #1A1A2E (card backgrounds)
- Text primary: #FFFFFF
- Text secondary: #A0A0B8
- Accent: #00D4AA (teal, for highlights and badges)
- Code block background: #12121F
- Border: #2A2A3E

What do these sections do?

The Layout Structure section tells the critic exactly which sections must exist and in what order. The Color Palette gives exact hex values so the critic can verify them against the CSS. "Dark background" is vague. #0F0F1A is inspectable.

Save the file, then add the typography and responsive sections below the color palette:


## 3. Typography Hierarchy

- Font family: Inter for body text, JetBrains Mono for code.
- Hero headline: 56px, weight 800, line-height 1.1.
- Section headings: 36px, weight 700.
- Feature card titles: 20px, weight 600.
- Body text: 16px, weight 400, line-height 1.6.
- Small text and labels: 14px, weight 500.

## 4. Responsive Behavior

- Desktop (above 1024px): Full layout as described. 3-column feature grid. Side-by-side testimonials.
- Tablet (768px to 1024px): Feature grid becomes 2 columns. Testimonials stack to 2 + 1. Hero headline shrinks to 40px.
- Mobile (below 768px): Single column layout. All grids become 1 column. Testimonials stack vertically. Hero headline shrinks to 32px. Horizontal padding increases to 24px.

Why exact breakpoint numbers?

Responsive behavior is one of the easiest things for a critic to verify. "Mobile-friendly" is subjective. "Below 768px, single column, hero headline 32px" is a checklist the critic can inspect structurally in the CSS.

Save the file, then add the final two sections below the responsive behavior:


## 5. Interaction Specifications

- CTA buttons: Scale to 1.05 on hover with a 0.2s ease transition. Background shifts from #6C63FF to #5A52D5.
- Feature cards: Subtle lift on hover (translateY(-4px)) with a 0.3s ease transition. Faint box-shadow appears.
- Code block copy button: Visible on hover over the code block. Shows "Copied!" text for 2 seconds after click.
- Footer links: Underline appears on hover with a 0.2s transition.
- Scroll: Smooth scrolling enabled on the html element.

## 6. Content Requirements

- Hero headline: "Build. Ship. Iterate."
- Hero subheadline: "The developer platform that turns your ideas into production-ready applications."
- Feature card headings: "Lightning Fast Builds", "Smart Deployments", "Real-Time Analytics".
- Each feature card description: 1-2 sentences, under 20 words.
- Code snippet: A realistic JavaScript or TypeScript example of at least 6 lines.
- Testimonial quotes: Each between 15 and 30 words.
- CTA headline: "Ready to build something great?"
- CTA button text: "Get Started Free"
- Footer copyright: "2025 DevLaunch. All rights reserved."
- Footer links: "Documentation", "GitHub", "Contact".

What makes these sections useful to the critic?

Interaction Specifications give the critic hover states and transition values to check in the CSS. Content Requirements list exact strings the critic can search for in the HTML. Together, all six sections cover layout, visuals, responsiveness, interactions, and content. The critic can evaluate each dimension independently.

Save spec/quality-bar.md.
Verify all six sections are present by running:

grep "^## " spec/quality-bar.md

You should see six lines, one for each numbered section heading from Layout Structure through Content Requirements.

Seeing fewer than six headings?

Each heading must start with ## (two hashes and a space) at the very beginning of its line. Check that you pasted all three chunks in order and that none of the headings were accidentally indented or merged into the previous section.

Help me fix my quality bar specification.

✔️ Awesome, I've got everything!

Great. Double check you've saved the file before moving on.

ⓧ I'd like to double check the full code

Your spec/quality-bar.md file is over 30 lines, so scroll through it and confirm these sections appear in order:

Title: # Quality Bar: Developer Landing Page.
Section 1: Layout Structure (hero, features grid, code snippet showcase, testimonials, CTA, footer).
Section 2: Color Palette (9 hex values from #6C63FF through #2A2A3E).
Section 3: Typography Hierarchy (Inter, JetBrains Mono, sizes from 56px to 14px).
Section 4: Responsive Behavior (three breakpoints: above 1024px, 768px to 1024px, below 768px).
Section 5: Interaction Specifications (CTA buttons, feature cards, copy button, footer links, scroll).
Section 6: Content Requirements (exact headline text, feature card headings, CTA text, footer content).

If any section is missing, scroll up to the corresponding chunk and paste it into your file.

Initialize Git and make the first commit

Git checkpoints let you compare the landing page before and after the loop runs. They also make Claude Code's /rewind command work, so you can roll back if an iteration goes sideways.

Initialize the Git repository by running:

git init

Stage and commit the scaffold by running:

git add .
git commit -m "Add project scaffold and quality bar specification"

Why commit now?

This baseline commit captures the project before any builder agent touches it. After the loop runs multiple iterations, you can compare the final src/index.html against this commit to see exactly how far the page evolved.

Before you run the next command, how many specification sections do you think your quality bar contains?

Verify the quality bar is complete by running:

cat spec/quality-bar.md | head -3 && echo "..." && grep "^## " spec/quality-bar.md

You should see the file title followed by all six section headings. That confirms your specification has the layout, colors, typography, responsive behavior, interactions, and content criteria the critic needs.

Commit failed or file missing?

If git commit says "nothing to commit," you may have already committed or forgotten to run git add . first. Run git status to see what Git sees.

If cat spec/quality-bar.md says the file doesn't exist, make sure you created it inside the spec/ directory and that you're still inside the gauntlet-loop folder.

Help me fix my Git commit or file structure.

Your project scaffold is committed and your quality bar is locked in. Next up, you'll create the builder and critic subagents that read this specification and put it to work.

Create the Builder and Critic Subagents

You have a quality bar that describes exactly what a great landing page looks like. Now you need two agents to do the work: one that builds and one that judges.

The Gauntlet Loop's power comes from this separation. If the builder grades itself, it drifts toward self-approval. A separate critic with fresh context and no knowledge of the builder's reasoning is what makes the loop converge.

In this step, get ready to:

Write a builder subagent with full write access to create and improve the landing page.
Write a critic subagent with read-only access that returns a binary PASS/FAIL verdict.
Commit both subagents to Git.

Write the builder subagent

Claude Code uses subagents to delegate tasks to specialized workers. Each subagent is a Markdown file with YAML frontmatter for configuration and a system prompt in the body.

The builder's job is to read the quality bar, create or improve the landing page, and log what changed. It needs full write access so it can create and edit files.

Create the builder subagent file by running this command:

cat > .claude/agents/builder.md << 'EOF'
---
name: builder
description: Builds and improves HTML/CSS landing pages based on a quality bar specification
tools: Read, Write, Edit, Bash, Grep, Glob
model: inherit
---

You are a landing page builder. Your job is to create or improve a developer landing page.

## Workflow

1. Read the quality bar specification at `spec/quality-bar.md`
2. Build or improve `src/index.html` to meet all specification dimensions
3. Use a single HTML file with inline CSS and any inline JavaScript needed
4. After building, update `workbench.md` with a summary of what you changed this round

## Rules

- Address every dimension in the quality bar: layout, color, typography, responsive behavior, interactions, and content
- Write clean, semantic HTML
- Keep all styles inline in a `<style>` tag within the HTML file
- When improving an existing version, focus on the specific gap identified by the critic
EOF

What does this file do?

The YAML frontmatter between the --- lines configures the subagent:

name and description tell Claude Code when to delegate to this agent.
tools grants the builder Read, Write, Edit, Bash, Grep, and Glob access. This is full write access so it can create and modify files.
model: inherit means the builder uses whatever model your main Claude Code session is running.

Everything below the frontmatter becomes the subagent's system prompt. It tells the builder exactly where to find the spec, where to write output, and how to log progress.

Confirm the file was created by running:

cat .claude/agents/builder.md

You should see the full YAML frontmatter and system prompt you just wrote.

File looks empty or missing?

Make sure you ran the command from your project root directory (the folder containing .claude/).
Check that the .claude/agents/ directory exists by running ls .claude/agents/. If it does not exist, create it with mkdir -p .claude/agents and try again.
help me debug why my builder.md file is missing

Write the critic subagent

The critic is the Gauntlet Loop's secret weapon. It starts with fresh context, has no idea how hard the builder tried, and can only read files. Its sole job is to compare the page against the spec and return a binary pick: PASS or FAIL.

Create the critic subagent file by running this command:

cat > .claude/agents/critic.md << 'EOF'
---
name: critic
description: Compares a landing page against the quality bar specification using blind comparison. Returns a binary PICK, never a score.
tools: Read, Grep, Glob, Bash
model: inherit
permissionMode: plan
---

You are a landing page critic. Your job is to compare a page against a specification and deliver a verdict.

## Workflow

1. Read the quality bar specification at `spec/quality-bar.md`
2. Read the landing page at `src/index.html`
3. Evaluate each specification dimension independently
4. Return your verdict

## Verdict format

Return one of:

**PASS** - The page meets the quality bar on all specification dimensions.

**FAIL** - The page falls short. Identify the single biggest remaining gap. Be specific: name the spec dimension, quote the requirement, and describe exactly how the page fails to meet it.

## Rules

- Never give a numeric score. Binary pick only: PASS or FAIL.
- Never read `workbench.md` or any builder conversation history.
- Never write to any file. You are read-only.
- Evaluate each dimension (layout, color, typography, responsive, interactions, content) before deciding.
- Your verdict must be based solely on `spec/quality-bar.md` and `src/index.html`.
EOF

How is the critic different from the builder?

Two things enforce the separation:

The tools list omits Write and Edit. The critic physically cannot modify any files.
permissionMode: plan puts the critic in read-only exploration mode. This is a Claude Code permission mode that restricts the agent to reading and analyzing without making changes.

The system prompt also tells the critic to never read workbench.md or builder history. This ensures a blind comparison: the critic knows only the spec and the page.

Confirm both subagent files exist by running:

ls .claude/agents/

You should see both builder.md and critic.md listed.

Only seeing one file?

Run cat .claude/agents/critic.md to check if the critic file has content. If it is empty, re-run the creation command above.
help me figure out why my critic subagent file is missing

Why binary picks instead of scores?

A numeric score ("7 out of 10") gives the builder nowhere specific to go. A binary FAIL with a single named gap gives the builder exactly one task for the next round.

This is a core Gauntlet Loop principle: the critic does a blind comparison and makes a pick, not a rating. It forces convergence because each round has a clear, falsifiable target.

Commit the subagents to Git

With both subagents written, commit them so you have a checkpoint to return to if anything goes wrong during the loop.

Stage and commit the subagent files by running these commands:

git add .claude/agents/builder.md .claude/agents/critic.md
git commit -m "Add builder and critic subagents"

Confirm the commit landed by running:

git log --oneline -1

You should see a commit message containing Add builder and critic subagents.

Commit failed?

If git says "nothing to commit", the files may already be committed. Run git status to check.
If you see an error about user identity, set your Git name and email with git config user.name and git config user.email first.
help me fix my git commit error

✔️ Awesome, I've got everything!

Great. Double check that both files are saved and committed.

ⓧ I'd like to double check the full code

Here is the full builder.md file:

---
name: builder
description: Builds and improves HTML/CSS landing pages based on a quality bar specification
tools: Read, Write, Edit, Bash, Grep, Glob
model: inherit
---

You are a landing page builder. Your job is to create or improve a developer landing page.

## Workflow

1. Read the quality bar specification at `spec/quality-bar.md`
2. Build or improve `src/index.html` to meet all specification dimensions
3. Use a single HTML file with inline CSS and any inline JavaScript needed
4. After building, update `workbench.md` with a summary of what you changed this round

## Rules

- Address every dimension in the quality bar: layout, color, typography, responsive behavior, interactions, and content
- Write clean, semantic HTML
- Keep all styles inline in a `<style>` tag within the HTML file
- When improving an existing version, focus on the specific gap identified by the critic

Here is the full critic.md file:

---
name: critic
description: Compares a landing page against the quality bar specification using blind comparison. Returns a binary PICK, never a score.
tools: Read, Grep, Glob, Bash
model: inherit
permissionMode: plan
---

You are a landing page critic. Your job is to compare a page against a specification and deliver a verdict.

## Workflow

1. Read the quality bar specification at `spec/quality-bar.md`
2. Read the landing page at `src/index.html`
3. Evaluate each specification dimension independently
4. Return your verdict

## Verdict format

Return one of:

**PASS** - The page meets the quality bar on all specification dimensions.

**FAIL** - The page falls short. Identify the single biggest remaining gap. Be specific: name the spec dimension, quote the requirement, and describe exactly how the page fails to meet it.

## Rules

- Never give a numeric score. Binary pick only: PASS or FAIL.
- Never read `workbench.md` or any builder conversation history.
- Never write to any file. You are read-only.
- Evaluate each dimension (layout, color, typography, responsive, interactions, content) before deciding.
- Your verdict must be based solely on `spec/quality-bar.md` and `src/index.html`.

Your builder and critic are ready. Next up, you will unleash the builder on its first pass and see what it creates from the quality bar alone.

Run the First Builder Pass

Your builder and critic subagents are in place, each with the right tools and permissions.

Before you can experience why the Gauntlet Loop exists, you need a naive first version. The builder will produce a rough but working landing page from your quality bar specification. It will have obvious gaps compared to the full spec, and that gap is exactly the point.

In this step, get ready to:

Delegate to the builder subagent to create the initial landing page.
Open the result in a browser and note what the builder produced.
Commit the first version as a baseline for comparison.

Prompt the builder

The builder subagent already knows how to read your quality bar and produce HTML. You just need to delegate the task using an @-mention, which guarantees Claude Code routes it to the builder instead of handling it directly.

In your Claude Code session, type @ and select builder (agent) from the typeahead menu that appears.
After selecting the builder, type the rest of your prompt so the full message reads:

@builder Read spec/quality-bar.md and create the initial version of src/index.html. Build a complete landing page that addresses as many specification dimensions as you can. Update workbench.md with what you built and which spec dimensions you addressed.

What happens when you send this prompt?

The @builder mention guarantees Claude Code delegates this task to your builder subagent instead of handling it in the main conversation.

The builder reads spec/quality-bar.md, generates the HTML/CSS landing page, and writes it to src/index.html. It also updates workbench.md with a summary of what it built and which spec dimensions it addressed.

Claude Code will prompt you to approve file writes as the builder works. Allow each permission when prompted. The builder may take a minute or two to generate the full page.

Once the builder finishes, confirm it created the landing page by running:

ls src/

You should see index.html in the output.

Verify that the progress tracker was updated by running:

cat workbench.md

You should see a new entry under Rounds documenting what the builder created and which spec dimensions it addressed.

Builder didn't create the file?

If you denied a permission prompt during the builder's run, the builder could not write the file. Run the prompt again and allow all file write permissions when prompted.
Make sure you selected the builder from the @-mention typeahead. If you just typed "use the builder" without the @-mention, Claude may have handled the task in the main conversation instead of delegating.
If the builder finished but workbench.md was not updated, add the entry yourself based on what the builder reported in its output.

Still stuck? Help me figure out why the builder subagent didn't create src/index.html.

Open the result in a browser

The builder has produced its first attempt at the landing page. Before you open it, take a moment to predict what you will see.

Do you think the builder's first pass covers every section in your quality bar, or does it prioritize some dimensions and skip others?

Open src/index.html in your default browser by running:

open src/index.html

You see a styled landing page with a hero section, feature cards, and a footer. It looks decent at first glance.

How does it compare to the quality bar?

The builder typically addresses layout structure, color palette, and typography first. These are the most concrete dimensions in the spec and the easiest to implement in a single pass.

Responsive breakpoints, hover states, animations, and some sections like testimonials and the CTA are often missing or incomplete. These gaps are expected. The quality bar is detailed enough that a single pass cannot cover everything.

Compare what you see in the browser against your spec/quality-bar.md. Note which sections are present and which are missing.

Why note the gaps yourself?

In the next step, the critic subagent will evaluate this page with fresh eyes and no knowledge of how hard the builder tried. Comparing your own assessment to the critic's verdict is the core learning moment of the Gauntlet Loop.

Commit the first version

Saving this version as a Git commit lets you compare it against later iterations. You can also use /rewind in Claude Code to return to this checkpoint if needed.

Commit the current state by running:

git add -A
git commit -m "Round 1: initial builder pass"

You should see a commit summary listing the files that were added, including src/index.html and the updated workbench.md.

Your first builder pass is committed and you have a baseline to measure progress against. Next up, you will unleash the critic on this page and see exactly how many gaps a fresh pair of eyes can find.

The Critic Tears It Apart

Your landing page is live in the browser. It has a hero section, feature cards, and a footer. It looks like a legitimate developer portfolio.

Here is the catch. When you watched the builder create the page, you instinctively forgave its rough edges because you saw the effort. A fresh evaluator with zero context and only the quality bar to compare against will not be so generous. That gap between "looks decent" and "meets the bar" is exactly what the Gauntlet Loop is built to close.

In this step, get ready to:

Spawn the critic subagent to evaluate the landing page with fresh context.
Record the critic's verdict in workbench.md.

Spawn the critic with fresh context

The critic subagent you built in Step 2 has a critical design constraint. It can only read spec/quality-bar.md and src/index.html. It has no access to the builder's conversation history, no access to workbench.md, and no knowledge of what tradeoffs the builder made. This isolation is the whole point.

Before you run the critic, think about this: you have seen the first version of the landing page in your browser. Do you expect it to pass every dimension of the quality bar, or fall short somewhere? Which spec dimension do you think is weakest?

In Claude Code, delegate to the critic subagent by typing this prompt:

@critic Evaluate the current landing page against the quality bar.

What does this prompt do?

The @critic prefix guarantees Claude Code invokes the critic subagent specifically, not the main conversation. You can also type @ and pick the critic from the typeahead menu that appears.

The critic's own system prompt (in .claude/agents/critic.md) handles the rest. It reads the quality bar, inspects the page, and returns a structured PASS or FAIL verdict with the single biggest gap.

The verdict is FAIL. The critic found specific gaps in the landing page that you might have been willing to overlook.

Maybe the responsive breakpoints are missing at 768px. Maybe the hover states on the feature cards are not implemented. Whatever the gap, it is a dimension of the quality bar that the builder did not fully address.

Why does the critic find gaps you didn't?

When you watched the builder create the page, you saw the progress. You forgave missing hover states because the layout looked good. The critic has none of that context. It reads the spec, reads the page, and asks one question: does this meet the bar?

This is the core insight of the Gauntlet Loop. Self-grading agents approve their own work too easily. A fresh evaluator with no sunk cost in the work is a harsher, more honest judge.

Record the verdict in workbench.md

The critic is read-only by design. It cannot and should not update workbench.md. You record its verdict manually so the workbench stays as a single source of truth that only you and the builder write to.

Open workbench.md in your code editor.
Below the Round 1 builder entry, add the critic's verdict by pasting the following:

## Round 1 — Critic Verdict

**Verdict:** FAIL

**Biggest gap:** [[CRITIC_GAP="the specific gap from the critic's output, e.g. responsive breakpoints not implemented at 768px"]]

*(Recorded by learner from critic output.)*

What goes in the biggest gap?

Copy the critic's exact finding from the terminal output. It will name a specific spec dimension that the page fails on, like missing responsive breakpoints or unimplemented hover states. Paste that finding into the Biggest gap field so the builder knows exactly what to fix in the next round.

Save workbench.md.
Confirm the file now has both entries by running:

cat workbench.md

You should see both the Round 1 builder entry and the Round 1 critic verdict, with the critic's specific gap recorded.

Critic not returning a verdict?

Make sure .claude/agents/critic.md exists and has the correct frontmatter. Run cat .claude/agents/critic.md to verify.
If Claude Code does not recognize the @critic mention, try restarting Claude Code. This can happen if the .claude/agents/ directory was created after the session started.
If the critic returns PASS on the first attempt, your quality bar may be too vague. Review spec/quality-bar.md and check that each section has specific, measurable criteria the critic can inspect.

Help me troubleshoot my critic subagent

The critic found the first gap. In the next step, you will close the loop. The builder will fix this gap, the critic will evaluate again, and the cycle will repeat until the page passes every dimension of the quality bar.

Run the Full Loop and Watch It Converge

You've now seen both halves of the Gauntlet Loop in isolation. The builder created a rough landing page, and the critic found a concrete gap the builder missed. Running those rounds manually taught you the pattern, but doing it by hand defeats the purpose.

The real power of the Gauntlet Loop is sustained, autonomous iteration with no fixed round count. In this step, you'll use Claude Code's /goal command to let the builder and critic run back-to-back until the critic returns PASS on every specification dimension.

In this step, get ready to:

Write a /goal prompt that orchestrates the full builder/critic loop.
Execute the loop and monitor convergence in workbench.md.
Review the final landing page against the first version from Step 3.

Write the loop prompt

Until now, you've been prompting Claude Code one turn at a time. The /goal command changes that. It sets a completion condition, and Claude keeps working across turns until a small evaluator model confirms the condition is met.

What is /goal?

When you type /goal followed by a condition, Claude Code starts working immediately. After every turn, a fast evaluator model reads the conversation transcript and checks whether your condition holds. If not, Claude takes another turn automatically.

The evaluator only reads the transcript. It does not run commands or read files on its own. That means your condition needs to be something Claude's output can demonstrate, like a verdict printed in the conversation.

Your prompt needs to orchestrate the full Gauntlet Loop: delegate to the builder, then delegate to the critic with fresh context, record each verdict, and repeat until the critic returns PASS.

Type this prompt into Claude Code:

/goal The critic subagent returns PASS on all specification dimensions.

Run the Gauntlet Loop:
1. Delegate to @builder to read the latest critic gap from workbench.md, improve src/index.html to address it, and log what changed in workbench.md.
2. Delegate to @critic with fresh context to compare src/index.html against spec/quality-bar.md. The critic returns PASS or FAIL with the single biggest remaining gap.
3. Record the critic's verdict in workbench.md.
4. If the critic returns FAIL, repeat from step 1.

Continue until the critic returns PASS on all specification dimensions.

What does this prompt do?

The first line after /goal is the stop condition. The evaluator checks this after every turn. As long as the critic has not returned PASS, Claude keeps going.

The numbered steps tell Claude how to spend each iteration. The @builder and @critic mentions guarantee that Claude delegates to those specific subagents rather than doing the work itself. Recording the verdict in workbench.md creates the convergence log you'll review at the end.

Why no fixed round count?

A fixed count ("do 5 rounds") means the loop might stop before the page is good enough, or keep running after it already passed. The Gauntlet Loop's exit condition is always binary: the critic's pick. The loop runs as long as it needs to, and no longer.

If you want to cap the maximum runtime, you can add a turn bound to the condition (e.g., or stop after 20 turns). The evaluator respects this and stops Claude if the cap is reached.

Run the loop and monitor convergence

Setting the goal starts a turn immediately. You do not need to send a separate prompt.

Press Enter to submit the prompt. You'll see a ◎ /goal active indicator appear, showing how long the goal has been running.
Watch the conversation. Claude delegates to the builder, then to the critic, then records the verdict. Each cycle is one round of the Gauntlet Loop.

Handle permission prompts

A goal does not change permissions. In default permission mode, Claude still asks before tool calls it has not been allowed previously. When a permission prompt appears, review and approve it so the loop continues. If you want the loop to run fully unattended, you can approve tool permissions for the session when prompted.

While the loop runs, open workbench.md in your code editor to watch it update in real time.
Let the loop run until the goal clears automatically. Claude prints a confirmation when the condition is met.

The loop typically takes 3 or more rounds. Each round adds a builder entry and a critic verdict to workbench.md.

Confirm the loop has converged by running this command:

cat workbench.md

You should see at least 3 rounds of builder/critic iterations. The final critic verdict should read PASS.

Loop stalled or running too long?

If Claude keeps looping beyond 5-6 rounds without converging, the quality bar may have conflicting criteria. Run /goal clear to stop the loop, review the critic's latest gap in workbench.md, and check whether the spec asks for something contradictory.
If the loop stops after one round with an immediate PASS, the critic's bar may be too lenient. Review critic.md and ensure it evaluates each specification dimension independently, not just the overall impression.
If you see a permission prompt that blocks progress, approve it. The loop pauses on permission requests and resumes after you respond.

Help me debug why my Gauntlet Loop isn't converging in Claude Code.

Review the final result

The loop has converged. Before you look at the result, take a moment to predict: how different do you think src/index.html looks now compared to the rough first version from Step 3?

Open src/index.html in your browser by running:

open src/index.html

Compare what you see now to the rough first version from Step 3. The improvement should be visually obvious. The page now has all the sections from your quality bar: hero, features grid, code snippet showcase, testimonials, and CTA. Responsive breakpoints, hover states, and animations are all in place.

Open workbench.md to review the full arc of convergence.

Walk through each round. Notice how the critic found different gaps each time, and how the builder addressed exactly that gap in the next round. The page did not improve randomly. It converged against a concrete specification.

What does convergence look like?

In the early rounds, the critic finds large structural gaps: missing sections, broken responsive behavior, absent interactions. In later rounds, the gaps shrink to polish-level details: a hover transition duration, a font weight mismatch, spacing at a specific breakpoint.

That progression from structural to cosmetic is the signature of a converging Gauntlet Loop. If the gaps stay large across many rounds, the quality bar likely has a conflict or the builder is ignoring the critic's feedback.

Commit the final version by running:

git add -A && git commit -m "Final version after Gauntlet Loop convergence"

Secret mission

Add a Lighthouse Gate

Your critic evaluates the page against a written quality bar. But a written spec has blind spots. A page can match every spec dimension while having poor color contrast, missing ARIA labels, or bloated scripts. Can you add a second, quantitative quality gate that the builder cannot talk its way past?

Clean Up Your Resources

This project runs entirely locally using your existing Claude Code plan, so there are no ongoing costs. Decide whether to keep your project files, pause to come back later, or delete them entirely.

Resources you used:

Project directory on your Desktop (contains spec/, src/, .claude/agents/, workbench.md, and Git history).
Lighthouse CLI (globally installed npm package, installed during the Secret Mission).

Keep everything running

No action needed. Choose this if you plan to reuse the Gauntlet Loop setup for a different project.

Your subagents, quality bar specification, and workbench are all saved locally and fully reusable.
To iterate on a completely different artifact, swap out spec/quality-bar.md with a new specification and point the builder at it.
Your workbench.md is a useful record of how the loop converged across rounds.
If you completed the Secret Mission, Lighthouse CLI remains installed globally and is available for future projects.

Pause - I'll come back to this later

No running processes to shut down. Your project files stay on disk until you return.

Everything is saved locally in your project directory.
To resume, open a terminal in the project folder and start Claude Code again.
Your Git history preserves every version the builder created, so you can always compare or revert.

Delete - I don't want to use this again

Remove all project files and start fresh. No cloud resources to tear down.

Delete your project directory from your Desktop by running the appropriate command for your operating system.

macOS

cd ~/Desktop
rm -rf [[PROJECT_DIR="your project folder name"]]

Windows

cd ~\Desktop
rmdir /s /q [[PROJECT_DIR="your project folder name"]]

If you completed the Secret Mission, uninstall Lighthouse CLI by running:

npm uninstall -g lighthouse

Nice Work!

You just built a polished developer landing page without writing a single line of HTML yourself. Instead, you wrote the quality specification and the agent infrastructure, then let Claude Code's subagents iterate until the output met the bar.

What you learned:

You wrote a detailed quality bar specification with inspectable, measurable criteria and learned why vague bars are the most common Gauntlet Loop failure mode.
You created builder and critic subagents with proper separation. The builder has full write access, the critic is read-only with fresh context and no access to builder reasoning. You experienced the core insight firsthand: a fresh critic immediately found gaps in work you might have accepted.
You ran a full autonomous loop using /goal that iterated until the critic's binary pick converged on PASS. You tracked convergence through workbench.md and can see the full arc of improvement across rounds.
Secret Mission: You added Lighthouse scoring as a quantitative gate, combining subjective spec fidelity with objective accessibility and performance metrics for a dual-dimension quality bar.

Ready to quiz yourself?