Gauntlet Loop
Wandeln Sie die anfänglichen Anweisungen oder Ziele eines Benutzers in einen Gauntlet Loop um – eine autonome Builder-vs.-Critic-Feedbackschleife, die auf Matt Shumers Claude of Duty-Technik, robonuggets/gauntlet-loop, duolahypercho/gauntlet-loop und dem AI Loop Engineering Three-Elements Framework basiert.
Die meisten Agentenausgaben bleiben bei "gut genug für KI" hängen, weil der Builder seine eigenen Hausaufgaben anhand vager Wörter benotet. Ein Gauntlet Loop ersetzt das einmalige Prompting durch einen persistenten Zyklus, der auf drei Kernelementen aufbaut:
- Objective: Das konkrete Arbeitsergebnis und der Zielzustand, der wahr werden muss.
- Referenz oder Metrik (Die Messlatte & Der strenge Kritiker): Eine benannte, abrufbare, nebeneinander vergleichbare Benchmark – gepaart mit objektiven Tests oder Metriken, wo anwendbar – blind von einem separaten Kritiker mit frischem Kontext beurteilt.
- Boundary: Explizite Erfolgskriterien, Runden-/Stagnationsgrenzen, Strategiewechselregeln und Sicherheits-/Berechtigungsgates, die steuern, wann die Schleife stoppt oder eskaliert.
Schritt 1: Seed-Instruktionen & Kontext identifizieren
- Wenn der Benutzer Anweisungen inline mit
/gauntlet-loop <Instruktionen>übergeben hat, diese als Seed verwenden. - Wenn der Benutzer
/gauntlet-loopohne Argumente während eines laufenden Gesprächs aufgerufen hat, die aktuelle Aufgabe, den aktuellen Plan oder Prompt verwenden, der besprochen wird. - Wenn es in der Nachricht oder im Gesprächsverlauf keine klare Aufgabe gibt, den Benutzer fragen, was er bauen oder erreichen möchte, bevor fortgefahren wird.
- Wenn die Aufgabe eine lokale Codebasis oder einen Arbeitsbereich betrifft, schnell die Verzeichnisstruktur, den Tech-Stack, den Test-Runner oder Build-Skripte inspizieren, damit die vorgeschlagenen Standardwerte auf reale Projekt-Tools und -Befehle verweisen.
Schritt 2: Die drei Schleifenelemente klären (Standardwerte vorschlagen)
Überprüfen Sie die Anfrage des Benutzers auf die folgenden Drei Kernelemente. Wenn ein Element fehlt, zu ungenau ist oder eine vage Qualitätsvorgabe verwendet, den Benutzer bitten, die drei Elemente zu bestätigen oder anzupassen, während konkrete, meinungsstarke Standardwerte vorgeschlagen werden.
Fast-Path-Regel: Wenn der Benutzer bereits ein klares Objective, eine spezifische abrufbare Referenz/Metrik und klare Boundaries geliefert hat – oder explizit "Standardwerte verwenden" / "Schreib einfach den Prompt" gesagt hat –, das Fragen überspringen und direkt mit Schritt 3 fortfahren, wobei die besten Standardwerte verwendet werden.
1. Objective (Welches konkrete Ergebnis muss wahr werden?)
- Vage Absichten ("die Seite verbessern", "ein gutes CLI schreiben") durch einen beobachtbaren Zielzustand und ein Arbeitsergebnis ersetzen ("Baue eine responsive SaaS-Preisseite in Next.js + Tailwind, auf der ein Erstbesucher alle Pläne vergleichen und den Kauf auf dem Handy abschließen kann").
- Vorgeschlagener Standard: Ein präzises 1–2-Sätze-Objective verfassen (einschließlich des erkannten oder empfohlenen Tech-Stacks / Formats), das der Benutzer genehmigen oder anpassen kann.
2. Referenz oder Metrik (Die Qualitätsmesslatte & externer Richter)
Alles in einem Gauntlet Loop hängt von der Qualitätsmesslatte ab. Eine gültige Referenzmesslatte muss drei Tests bestehen:
- Benannt: Ein spezifisches, reales Artefakt, kein Adjektiv oder eine Kategorie. ("Stripe's live pricing page" oder "Hades-Kampfscreenshots" funktioniert; "preisgekröntes SaaS-Design" oder "AAA-Qualität" allein scheitert.)
- Abrufbar / Überprüfbar: Der Kritiker kann es während des Laufs tatsächlich abrufen und überprüfen – die Live-URL screenshoten, den veröffentlichten Artikel lesen, das Binary ausführen oder das Repository überprüfen. Wenn der Agent die Referenz nicht abrufen kann, halluziniert er den Vergleich und genehmigt mittelmäßige Arbeit.
- Vergleichbar: Sowohl unser tatsächliches Ergebnis als auch die Referenz können nebeneinanderliegen, wobei die Etiketten entfernt werden, sodass ein frischer Kritiker eine binäre blinde A/B-Auswahl ("Welches gewinnt?") treffen und die einzig größte verbleibende Lücke benennen kann. Verwenden Sie niemals eine numerische Bewertung von 1–10, die in jeder Runde nach oben abdriftet.
Geschmack + Zahl schlägt Geschmack allein: Wann immer das Ziel eine messbare Dimension hat (Unit-/Integrationstestsuite, p95-Latenz, Lighthouse/Barrierefreiheit-Score, null horizontaler Überlauf bei 360px, Benchmark-Durchsatz, Wortanzahl oder Primärquellenzitat-Nachverfolgung), die qualitative Referenzmesslatte mit einem harten objektiven Prüfer kombinieren.
| Zieltyp | Referenzmesslatte + Metrik, die funktioniert |
|---|---|
| Website, App, UI | Live-URL eines bestimmten besten Produkts (linear.app, stripe.com/pricing, vercel.com), gescreenshotet bei Desktop- und mobilen Viewports + keine Konsolen-/Barrierefreiheit-/Überlauffehler |
| Code, CLI, Bibliothek | Ein benanntes Open-Source-Repo oder die Implementierung eines Tools (ripgrep, jq, esbuild) + eine automatisierte Testsuite, Property-Fuzzer und Latenz-/Durchsatz-Benchmark-Skript |
| Spiel, 3D, interaktiv | Tatsächliche Gameplay-Screenshots oder -Footage eines benannten veröffentlichten Titels (Call of Duty, Hades, Brotato) verglichen mit In-Game-Frames in Echtzeit + Ziel-FPS / Spielbarkeitsprüfung |
| Schreiben, Docs, Erklärer | 2–3 bestimmte veröffentlichte Stücke eines benannten Autors oder Publikation (z.B. Julia Evans, Stripe Engineering Blog, Gwern) blind verglichen mit entfernten Bylines + Ziellängen-/Lesezeitprüfung |
| Forschung, Strategie, Analyse | Ein benannter Analystenbericht, Methodenabschnitt einer Benchmark-Studie oder ein forensisches Leerverkaufs-Memo + automatisierter Abgleich aller Behauptungen mit Rohdaten |
| Folienpräsentation, Arbeitsergebnis | Eine bestimmte öffentliche Präsentation oder ein Memo einer Benchmark-Firma mit gleicher Seiten-/Folienanzahl + Prüfung auf narrative Klarheit |
- Vorgeschlagener Standard: 2 bis 3 spezifische, benannte, abrufbare Kandidatenmesslatten anbieten (die toughest tatsächlich erreichbare als
(Empfohlen)markieren), gepaart mit einer konkreten objektiven Metrik/Prüfung.
3. Boundary (Stopp-Bedingungen, Budgets & Sicherheitsgates)
"Schleife bis zur vollkommenen Perfektion" motiviert den Kritiker, aber eine unbegrenzte Schleife gegen eine unerreichbare Messlatte kann ewig drehen, Tokens verbrennen oder unsichere Änderungen vornehmen. Definieren Sie explizite Grenzen entlang von drei Unterachsen:
- Erfolgs- & Konvergenzstopp: Beenden, wenn jede Komponente ihren objektiven Prüfer besteht und den blinden Vergleich gegen die Referenz gewinnt (oder wenn die menschlich festgelegte "Bremse" den Lauf stoppt).
- Iterations- & Stagnationsgrenze: Runden pro Komponente begrenzen (Standard: max. 5 Runden pro Stück oder stopp nach 2 aufeinanderfolgenden Runden ohne sinnvolle Verbesserung). Vom Builder verlangen, dass er die Strategie ändert, wenn dieselbe Lücke zweimal hintereinander fehlschlägt.
- Berechtigungen & Sicherheitsgate: Lokales Lesen, Entwerfen, Bearbeiten, Bauen, Rendern und Testen erlauben. Für irreversible oder externe Aktionen ohne explizite menschliche Genehmigung verbieten (keine Produktionsbereitstellung, zerstörerische Löschungen, kostenpflichtige API-Ausgaben, Änderungen von Anmeldeinformationen/Geheimnissen oder externe Nachrichten).
So fragen Sie den Benutzer
Wenn Klärung erforderlich ist, einen kurzen, überfliegbaren Prompt präsentieren (oder das strukturierte ask_question-Werkzeug des Harness verwenden, falls verfügbar), das nur die ungeklärten Elemente abdeckt, mit vorausgefüllten Standardwerten, sodass der Benutzer mit einer einzigen Kurzform antworten kann (z.B. "1, Standardwerte verwenden"):
- Objective: Geben Sie Ihr vorgeschlagenes geschärftes Objective + Stack an und fragen Sie, ob etwas geändert werden soll.
- Referenz & Metrik: Listen Sie 2–3 benannte, abrufbare Kandidatenmesslatten auf (
A,B,C, mitA (Empfohlen)) plus den vorgeschlagenen objektiven Prüfer/Test. - Boundary: Schlagen Sie die Standard-Stopp-Bedingung vor (z.B. "Gewinne blindes A/B + bestehe Prüfungen, max. 5 Runden/Stück, Strategiewechsel nach 2 identischen Fehlschlägen, nur lokale Bearbeitungen") ODER "Mensch als Bremse (weitermachen, bis ich stoppe)", und fragen Sie, welchen Modus sie bevorzugen.
Schritt 3: Den transformierten Gauntlet Loop ausgeben
Sobald Objective, Referenz/Metrik und Boundary ausgewählt (oder standardmäßig verwendet) sind, das Ergebnis in drei Teilen präsentieren:
1. Gauntlet Loop Designkarte
Eine prägnante Zusammenfassungstabelle ausgeben, die die Schleifenarchitektur festlegt:
- Objective: Das genaue Ergebnis und Arbeitsergebnis, das wahr werden muss.
- Referenzmesslatte (Geschmack): Das benannte, abrufbare Artefakt und wie es vor dem Bauen abgerufen/überprüft wird.
- Objektive Metrik (Zahl): Der automatisierte Test, Benchmark, Layout-Check oder die Faktenüberprüfung, die vor einer Kritikerbewertung erforderlich sind.
- Zerlegungsregel: Wie die Arbeit in kleine, unabhängig beurteilbare Stücke aufgeteilt wird (nur wirklich unabhängige Teile parallelisieren; eng gekoppelte Systeme unter kohärenter sequenzieller Zuständigkeit halten).
- Kritikerprotokoll: Separater Unteragent mit frischem Kontext; inspiziert das echte gerenderte/ausgeführte Artefakt (niemals die Zusammenfassung des Builders); führt einen blinden A/B-Vergleich mit entfernten Etiketten durch; trifft eine binäre Auswahl und benennt die einzig größte verbleibende Lücke.
- Zustand & Fortschritt: Die Datei, die zum Speichern des Schleifengedächtnisses verwendet wird (
GAUNTLET_PROGRESS.mdoder eine Live-Fortschrittsseite), die abgeschlossene Teile, Beweise, fehlgeschlagene Ansätze und verbleibende Lücken aufzeichnet, damit der Kontext nicht verfällt. - Boundary: Die aktiven Stopp-Regeln, Rundengrenzen und Sicherheitsgates.
2. Der Gauntlet Loop Prompt
Einen in sich geschlossenen, kopierfertigen Prompt innerhalb eines umschlossenen markdown-Blocks ausgeben. Den Universellen Gauntlet Loop Prompt unten bereitstellen (angepasst an die Aufgabe, Werkzeuge und den Stack des Benutzers), und wenn der Benutzer den ultra-kompakten 3-Absatz-Matt-Shumer-Stil oder schleifenspezifische Harness-Befehle wünscht, das abschließende Ende entsprechend anpassen (siehe references/examples.md).
Baue [ARBEITSERGEBNIS / OBJECTIVE] in [STACK / FORMAT].
## 1. Die Qualitätsmesslatte & Metrik (Zuerst abrufen)
Die Qualitätsmesslatte ist [BENANNTE, ABRUFBARE REFERENZ]. Vor dem Bauen oder Beurteilen die echte Referenz direkt abrufen und überprüfen ([WIE ABRUFEN: Live-URL bei Desktop & Mobile screenshoten / den veröffentlichten Text ziehen / die Referenzimplementierung klonen oder ausführen]) – niemals mit einer Erinnerung oder Beschreibung davon vergleichen.
Jedes Stück muss auch diese objektiven Prüfungen bestehen: [OBJEKTIVE METRIKEN / TESTS / BENCHMARKS].
## 2. Zerlegung & Zuständigkeit
Die Arbeit in die kleinsten Stücke zerlegen, die unabhängig gebaut, verifiziert und beurteilt werden können: [ERSTE KANDIDATENSTÜCKE].
- Parallele Builder-Unteragenten NUR für Stücke ausrollen, die wirklich unabhängig sind.
- Eng gekoppelte Systeme unter sequenzieller, kohärenter Zuständigkeit halten, damit Komponenten nicht kollidieren.
## 3. Der Builder-vs.-strenger-Kritiker-Loop
Für jedes Stück einen Builder und einen separaten Kritiker-Unteragenten mit frischem Kontext (kein Zugriff auf die Gedankenkette oder Ausreden des Builders) ausführen:
1. **Bauen & Prüfen**: Der Builder erstellt oder überarbeitet das Stück und führt die objektiven Prüfungen durch ([TESTS / LINT / BENCHMARK / RENDER]).
2. **Das echte Artefakt überprüfen**: Der Kritiker öffnet und inspiziert die tatsächliche Ausgabe ([SCREENSHOTS / LAUFENDES BINARY / TESTLOGS / ENTWURFSTEXT]) – niemals die Zusammenfassung des Builders.
3. **Blinde A/B-Auswahl**: Der Kritiker platziert unser Artefakt neben [BENANNTE REFERENZ] blind mit entfernten Etiketten, trifft eine binäre Auswahl, welches besser ist, und – wenn unseres verliert – identifiziert er die **einzig größte verbleibende Lücke** mit konkreten Beweisen und schickt sie an den Builder zurück.
4. **Keine weiche Benotung**: Der Kritiker muss rücksichtslos streng sein. Lob und numerische Bewertungen von 1–10 sind verboten. Wenn unseres den blinden Vergleich nicht gewinnt und alle objektiven Prüfungen nicht bestanden werden, weitermachen.
## 4. Zustandsverfolgung & Strategiewechsel
Nach jeder Runde ein kompaktes `GAUNTLET_PROGRESS.md` (und/oder Live-Fortschrittsansicht) führen, das Folgendes aufzeichnet: aktuelles Stück, Rundennummer, Kritikerurteil, die gezielte Lücke, fehlgeschlagene Ansätze und Ergebnisse objektiver Prüfungen. Wenn dieselbe Lücke zweimal hintereinander fehlschlägt, den aktuellen Ansatz aufgeben und eine strukturell andere Strategie versuchen.
## 5. Abschließender Integrationsdurchlauf & Grenzen
- **Integrationskritiker**: Sobald einzelne Stücke gewinnen, einen frischen Integrationskritiker beauftragen, das vollständig zusammengesetzte Artefakt Ende-zu-Ende auf Konsistenz, Nähte, Leistung und Passung mit dem ursprünglichen Objective zu überprüfen.
- **Boundaries**: [STOPP-BEDINGUNGEN: z.B. Stopp, wenn alle Stücke + Integration das blinde A/B gewinnen und alle objektiven Prüfungen bestehen, oder nach N Runden pro Stück / 2 aufeinanderfolgenden Runden ohne messbaren Gewinn]. Erlaubte Aktionen: [ERLAUBTE LOKALE AKTIONEN]. Nicht [VERBOTENE AKTIONEN: In Produktion bereitstellen, Daten löschen, Geld ausgeben oder Anmeldeinformationen ändern] ohne explizite menschliche Genehmigung.
[SCHLEIFENENDE DES HARNESS: Weitermachen, bis der Kritiker unseres über jedes Stück hinweg auswählt, mit Buildern und Kritikern als Unteragenten. / Oder für Claude Code: `/loop` auf jedem Stück, bis es gewinnt; Unteragenten und `ultracode` ausrollen. / Oder für Codex: `/goal` bis jedes Stück gewinnt.]
3. Ausführungsangebot
Zum Abschluss fragen:
"Möchtest du, dass ich diesen Gauntlet Loop jetzt als leitender Orchestrator ausführe, eines der drei Elemente (Objective, Referenz/Metrik, Boundary) anpasse oder den Prompt-Stil wechsele (Universell Begrenzt vs. Klassischer 150-Wort-Aim-Prompt für Claude
/loopoder Codex/goal)?"
Wenn der Benutzer zustimmt, den generierten Prompt sofort als aktive Betriebsanweisung übernehmen: zuerst die Referenz abrufen, GAUNTLET_PROGRESS.md initialisieren, die Stücke zerlegen und mit Runde 1 beginnen.
Was einen Gauntlet Loop zerstört (Schutzmaßnahmen)
Niemals diese Fehlermodi in einen generierten Gauntlet-Prompt einfließen lassen:
- Eine vage oder nicht abrufbare Messlatte: "Mach es erstklassig" oder das Nennen einer paywall-geschützten/unerreichbaren Referenz zwingt den Kritiker, den Vergleich zu halluzinieren und alles durchzuwinken.
- Der Builder, der seine eigene Arbeit beurteilt: Ein Builder erinnert sich an jeden Kompromiss, den er gemacht hat, und rationalisiert sie. Der Kritiker muss ein Unteragent mit frischem Kontext sein (oder ein sauberer Verifikationsdurchlauf, der von Builder-Rechtfertigungen befreit ist).
- Numerische 1–10-Bewertungen anstelle einer binären Auswahl: Bewertungen von 1–10 driften im Laufe der Runden automatisch von 7/10 auf 9/10. Eine binäre blinde A/B-Auswahl verlangen ("Welches gewinnt?") plus die einzig größte verbleibende Lücke.
- Kritiker lesen Zusammenfassungen anstatt das Artefakt zu überprüfen: Ein glänzender Markdown-Statusbericht ist kein Beweis. Der Kritiker muss gerenderte Pixel überprüfen, das Binary/die Tests ausführen oder den tatsächlichen Text lesen.
- Parallelisieren von eng gekoppeltem Code: Das Ausrollen von 10 Unteragenten auf derselben Zustandsschleife oder gemeinsam genutzten Rendering-Pipeline verursacht Merge-Konflikte und visuelle Nähte. Nur unabhängige Stücke ausrollen und einen Zwischenintegrationskritiker verlangen.