gauntlet-loop

Gauntlet Loop

Use this skill when the user asks for Matt Shumer's Gauntlet Loop, asks for an unusually high-quality autonomous build, or wants work repeatedly judged against a concrete external standard.

This is an independent adaptation of the method described by Matt Shumer. It is not an official Matt Shumer skill.

The core idea

A lead agent receives:

1. A clear outcome.
2. Non-negotiable constraints.
3. A concrete quality bar that can be inspected.

The lead agent decomposes the outcome into the smallest meaningful pieces that can be built and evaluated independently. Each important piece goes through a loop:

build → inspect the real output → compare against the bar → identify the largest gap → improve → repeat

The builder must not grade its own work. Use a separate critic with fresh context.

Non-negotiable rules

1. Give the destination, not a micromanaged implementation. Preserve the user's required stack and constraints, but let the lead agent choose architecture and decomposition unless the user explicitly specifies them.
2. Use a real quality bar. “Amazing,” “polished,” and “production-ready” are aspirations, not evaluation criteria.
3. Evaluate the artifact, not the builder's explanation. Inspect running software, screenshots, recordings, test output, benchmarks, rendered pages, final prose, or other direct evidence.
4. Separate builder and critic. The critic receives the goal, constraints, quality bar, and artifact, but not the builder's rationale or chain of decisions.
5. Attack the largest remaining gap first. Do not produce long undifferentiated feedback lists while leaving the dominant defect untouched.
6. Do not stop after an arbitrary number of rounds. Continue while meaningful improvement is possible, subject to explicit user, compute, safety, or environment limits.
7. Be honest about the result. Never claim the artifact meets the reference when the evidence says it does not.
8. Preserve correctness while improving quality. A visual or stylistic pass may not break business rules, accessibility, security, performance, or existing tests.

When not to use it

Do not force a Gauntlet Loop onto:

• Tiny edits with an obvious answer.
• Tasks with no inspectable artifact or meaningful evaluation signal.
• Work where the cost of repeated evaluation clearly exceeds the value.
• Requests that prohibit autonomous iteration or external comparisons.

For a small task, perform a direct build-and-review pass instead.

Execution workflow

1. Convert the request into an outcome brief

Write a compact internal brief containing:

• Goal: What must exist or be true at the end.
• User outcome: What the user should be able to do.
• Non-negotiables: Stack, format, compatibility, deadline, policy, performance, brand, and other hard constraints.
• Quality bar: The concrete reference or measurement.
• Verification surface: How the actual artifact will be inspected.

Do not ask the user to define implementation details the agent can determine itself.

2. Choose an inspectable quality bar

Prefer bars in this order:

1. User-provided reference artifacts.
2. Best-in-class real products or examples in the same category.
3. Objective acceptance tests or measurable thresholds.
4. A small reference set combining visual, functional, and performance standards.

A useful bar must be concrete enough that an independent critic can say what wins and why.

Examples:

Task	Strong quality bar
Website	Reference screenshots plus responsive, accessibility, and performance checks
Game	Reference gameplay footage/screenshots plus frame-time, input, collision, and playability tests
Backend	Contract tests, failure-injection tests, latency target, security review, and reference behavior
Product UI	Reference flows plus task-completion, hierarchy, responsiveness, and accessibility criteria
Writing	Exemplars for clarity and compression plus factual, structural, and audience requirements
Research	Primary-source coverage, claim-to-source traceability, counterevidence, and reproducibility
Marketing	Reference creative set plus message clarity, brand fit, legibility, and channel constraints

References are standards for quality, not permission to copy protected expression, branding, or proprietary implementation.

3. Build the evaluation harness before polishing

Create the fastest repeatable way to inspect progress. Depending on the task, this can include:

• Automated tests and linters.
• Reproducible screenshots or video captures.
• Browser automation for real user flows.
• Image-diff or layout-diff checks.
• Performance profiling with p50, p95, p99, and worst-case measurements.
• Accessibility checks.
• Security and failure-mode tests.
• A rubric that forces direct comparison to the reference.

Prefer deterministic captures and repeatable scenarios. A critic cannot reliably compare moving targets.

4. Let the lead agent decompose the work

Break the goal into the smallest pieces that can be independently improved and judged.

Good decomposition targets a concrete concern, such as:

• Camera behavior.
• Vehicle handling.
• Lighting.
• Navigation.
• Checkout state transitions.
• Empty states.
• Article opening.
• Evidence quality.

Avoid vague workstreams such as “make the whole thing better.”

The lead agent owns interfaces between workstreams and records dependencies.

5. Decide what can run in parallel

Fan out independent concerns. Keep tightly coupled concerns sequential or under one owner.

Parallelize when agents can change separate surfaces without invalidating one another. Examples include isolated assets, independent test cases, separate research questions, or clearly bounded components.

Use sequential ownership when concerns share a global system, such as:

• Lighting, tonemapping, materials, and exposure.
• Physics, controls, camera, and animation.
• Database invariants and API transaction behavior.
• Argument structure, evidence, and conclusion.
• Global design tokens and page-level hierarchy.

Do not maximize agent count for its own sake. Coordination quality matters more than fan-out.

6. Run builder–critic loops

For each important piece:

Builder

Give the builder:

• The local objective.
• Relevant constraints and interfaces.
• The selected quality bar.
• Current artifact and critic feedback.
• Permission to use available tools and inspect the actual result.

The builder implements the next improvement and supplies direct artifact evidence, not a self-score.

Critic

Spawn a fresh critic. Give it:

• The goal.
• The relevant constraints.
• The quality bar.
• The actual output or reproducible inspection command.

Do not include the builder's reasoning or a persuasive summary.

The critic must:

1. Inspect the real output.
2. Compare it directly with the bar.
3. Use blind A/B comparison when practical.
4. State which output wins.
5. Identify the single largest meaningful gap.
6. Provide a concrete correction or testable next target.
7. Reject regressions in previously passing requirements.

Return the critic's result to the builder and repeat.

7. Maintain a progress ledger

For long runs, maintain GAUNTLET_PROGRESS.md or a simple live HTML page with:

• Goal and non-negotiables.
• Quality bar and source references.
• Current decomposition.
• Current status of each workstream.
• Latest artifact evidence.
• Critic verdicts.
• Largest remaining gaps.
• Objective test and benchmark results.
• Regressions and unresolved risks.

Update it after meaningful rounds, not after every trivial edit.

8. Run integration and smoothing passes

After a major wave, use a fresh integration agent to inspect the complete artifact.

Its job is to:

• Resolve inconsistencies between individually improved pieces.
• Repair interface conflicts and regressions.
• Check end-to-end user flows.
• Make the artifact feel coherent.
• Preserve the strongest local work rather than redesigning everything.

Then run the complete artifact through a final independent critic.

9. Stop responsibly

Stop when one of the following is true:

• The artifact meets the explicit acceptance criteria and wins or reaches parity against the selected bar on the dimensions that matter.
• Further rounds produce no meaningful improvement.
• A hard environment, safety, budget, or compute limit is reached.
• The user stops the run.

Do not conceal remaining gaps. Report them precisely.

Critic prompt template

Use this as the basis for each independent critic:

You are the independent critic for one Gauntlet Loop workstream.

Goal:
[LOCAL GOAL]

Non-negotiable constraints:
[CONSTRAINTS]

Quality bar:
[REFERENCE ARTIFACTS OR MEASUREMENTS]

Artifact to inspect:
[FILES, URL, SCREENSHOTS, COMMANDS, TEST OUTPUT, OR TEXT]

Inspect the actual artifact. Do not rely on the builder's description.
Compare it directly against the quality bar, using a blind A/B comparison when practical.

Return:
1. Verdict: ours wins, parity, or reference wins.
2. Evidence for the verdict.
3. The single largest meaningful remaining gap.
4. One concrete, testable instruction for the next builder pass.
5. Any regression in a previously passing requirement.

Be demanding, specific, and honest. Do not reward effort or explain why the current result is reasonable.

Lead-agent launch template

Adapt this minimally to the user's task:

Run a Gauntlet Loop for this goal:

[GOAL]

Non-negotiable constraints:
[CONSTRAINTS]

Concrete quality bar:
[REFERENCES AND/OR MEASUREMENTS]

Act as the lead agent. Choose the implementation approach and divide the goal into the smallest important pieces that can be improved and judged independently. Establish a repeatable evaluation harness first.

For each important piece, assign a builder and a separate critic with fresh context. The critic must inspect the real output, compare it directly with the quality bar, identify the largest remaining gap, and send that gap back for another builder pass. Use blind A/B comparisons when practical.

Fan out only genuinely independent work. Keep tightly coupled systems sequential or under one owner. After major waves, run a fresh integration pass over the complete artifact.

Maintain GAUNTLET_PROGRESS.md with evidence, verdicts, metrics, regressions, and remaining gaps. Continue while meaningful improvement is possible or until I stop the run. Do not claim the reference was matched unless the evidence supports it.

Tool-use requirements

Use the strongest available inspection tools for the artifact:

• For web applications, open the running site, exercise core flows, inspect multiple viewport sizes, capture screenshots, and check console/network errors.
• For visual work, compare rendered pixels or frames—not only source files.
• For code, run tests, type checks, linters, builds, and realistic failure cases.
• For performance, test representative motion or load rather than only idle conditions.
• For stateful systems, test concurrency, retries, expiry, partial failure, and idempotency where relevant.
• For writing and research, audit claims, structure, evidence, counterarguments, and final-reader experience.

When the environment lacks true subagents, emulate role separation with fresh, isolated passes and explicitly note that limitation in the final report.

Final report format

At completion, report:

1. Built: What now exists.
2. Verified: Tests, captures, benchmarks, and flows completed.
3. Reference verdict: Where the artifact wins, reaches parity, or still loses.
4. Remaining gaps: Specific unresolved issues, ordered by impact.
5. Run evidence: Relevant files, screenshots, recordings, test output, or progress ledger.

Never replace evidence with adjectives.

Sources and attribution

This skill is based on Matt Shumer's public description of the Gauntlet Loop and the public Claude of Duty prompt and repository:

• Original X post: https://x.com/mattshumer_/status/2081830214384886228
• Guide announcement on X: https://x.com/mattshumer_/status/2081857631254372509
• Official guide: https://somethingbig.ai/gauntlet-loop
• Original Claude of Duty prompt: https://github.com/mshumer/Claude-of-Duty/blob/main/prompt.md
• Public repository and process notes: https://github.com/mshumer/Claude-of-Duty