Gauntlet Loop
Die Methode hinter Claude of Duty, verallgemeinert für jede Arbeit, die ein Agent inspizieren kann. Ein Prompt erzeugte etwa 55.000 Zeilen eines spielbaren AAA-Shooters ohne menschliche Steuerung. Das Modell war nicht der Unterschied. Die Schleife war der Unterschied.
Kernzyklus:
Aufteilen → bauen → gegen eine externe Latte bewerten → wiederholen.
Methode von Matt Shumer. Siehe references/origin.md.
Ausführungsvertrag
Du führst dieses Protokoll aus. Der Benutzer tut dies nicht.
Wenn dieses Skill ausgelöst wird, gib keinen Prompt, keinen Plan zur Genehmigung und keine Beschreibung dessen, was eine Gauntlet-Schleife wäre, zurück. Setze die Latte, zerlege das Ziel, erzeuge Builder und Kritiker, führe die Runden durch und liefere das fertige Artefakt aus.
Der Benutzer hat das Ziel einmal genannt. Alles danach liegt bei dir.
- Stelle keine klärenden Fragen. Jede Unbekannte ist eine Entscheidung, die du triffst und in der abschließenden Zusammenfassung festhältst.
- Wähle die Latte selbst. Nenne sie in einem Satz und fahre dann fort. Frage niemals, welche Referenz verwendet werden soll.
- Route die Modelle selbst. Wähle das Modell und den Reasoning-Aufwand für jeden erzeugten Agenten aus dem, was das Harness bietet. Frage den Benutzer niemals, welches Modell verwendet werden soll, und überlasse niemals alles der Sitzungsvoreinstellung.
- Berichte nichts während des Laufs. Fortschritt geht in die Live-Progress-Datei, nicht in die Unterhaltung.
- Unterbrich nur bei blockierten Anmeldeinformationen, einer fehlenden kostenpflichtigen Ressource oder einer Anweisung, die Schaden verursachen würde.
Wenn der Benutzer ausdrücklich darum bittet, an Kontrollpunkten konsultiert zu werden, respektiere das. Ohne dieses Signal führe den Lauf bis zum Ende durch.
Wann es angewendet wird
Drei Bedingungen:
- Die Anfrage besteht darin, etwas zu erstellen oder zu verbessern, nicht eine Frage zu beantworten.
- Die Ausgabe kann objektiv inspiziert werden: gerendert, ausgeführt, geöffnet, gemessen, getestet, gelesen.
- Mehr als eine Runde ist erschwinglich.
Überspringe es für Nachschlageanfragen, Einzeiler-Korrekturen und Erklärungen. Es kostet echte Rechenleistung und zahlt sich nur aus, wenn Qualität wichtiger ist als Geschwindigkeit.
Runbook
1. Erkenne das Harness
Lies references/harness-setup.md und wähle die Verdrahtung, bevor du etwas anderes tust. Es bestimmt, ob Kritiker von parallelen Subagenten, separaten Sitzungen oder hart getrennten Durchläufen kommen. Kündige diesen Schritt niemals an, passe dich einfach an.
Während du dort bist, zähle die Modelle und Reasoning-Effort-Einstellungen auf, die dieses Harness bereitstellt. Du kannst nicht routen, was du nicht aufgelistet hast.
2. Setze das Budget und die Routing-Tabelle
Die Schleife multipliziert Aufrufe. Ohne Routing erbt jeder einzelne das Modell und den Aufwand der Sitzung, und eine Fächerbildung mechanischer Änderungen läuft auf einem Frontier-Modell mit maximalem Reasoning ohne Nutzen.
Lies references/model-routing.md und entscheide einmal, bevor du baust:
- Die Stufen. Ordne die verfügbaren Modelle den Stufen zu: T0 (ein Befehl, kein Modell), T1 (klein und schnell), T2 (mittel), T3 (Frontier mit hohem Aufwand).
- Die Tabelle. Welche Rolle bekommt welche Stufe: Leitung und jede Urteilsentscheidung auf T3, normales Bauen auf T2, mechanische Änderungen und Buchhaltung auf T1, alles, was ein Befehl verifizieren kann, auf T0.
- Das Budget. Respektiere das des Benutzers, falls angegeben, ansonsten setze eines fest und halte etwa ein Viertel davon für Kritiker zurück.
Zwei Regeln überschreiben jede Einsparung. Urteile werden niemals auf die günstigste Stufe geroutet, weil ein schwacher Kritiker früh genehmigt und die Methode aufhebt. Und ein Stück, das Geschmack oder Neuheit betrifft, beginnt hoch, weil ein günstiger Builder, der vier Runden verliert, mehr kostet als ein teurer, der in einer gewinnt.
Halte die Tabelle in der Progress-Datei fest. Kündige sie nicht an und bitte den Benutzer nicht um Genehmigung.
3. Setze die Latte
Die Latte entscheidet, ob der Lauf überhaupt funktioniert. Keine Latten: „mach es großartig“, „Produktionsqualität“, „befolge Best Practices“. Eine Latte ist ein echtes externes Artefakt oder eine Messung, neben das die Ausgabe gelegt werden und verlieren kann.
Wähle eine mit references/quality-bars.md, das visuelle Arbeit, Frontend, Produkt-UI, Backend, Mobil, Schreiben, Designsysteme, Forschung, Daten und Marketing abdeckt.
Regeln:
- Innerhalb des Laufs inspizierbar. Ein Screenshot, der im Workspace gespeichert wird, eine URL, die du öffnen kannst, eine Suite, die ausgeführt wird, eine Datei, die du lesen kannst. Keine Latte, die aus dem Training in Erinnerung geblieben ist.
- Muss nicht erreichbar sein. Claude of Duty hat Call of Duty nie geschlagen. Die Latte existiert, um den Lauf davon abzuhalten, sich bei „gut für KI“ zu beruhigen.
- In Runde eins bestanden bedeutet, sie war zu niedrig. Erhöhe sie und fahre fort.
Rufe die Latten-Artefakte jetzt ab oder erzeuge sie, bevor irgendein Bau beginnt, und speichere sie im Workspace, damit jeder Kritiker sie erreichen kann.
4. Nimm das Ziel, nicht die Implementierung
Verschreibe dich nicht im Voraus deiner eigenen Architektur und akzeptiere keine Zerlegung, die erfunden wurde, bevor das Artefakt betrachtet wurde. Gib das Ziel erneut an und lass die Form entstehen.
Wenn der Benutzer einen Stack oder eine Architektur festgelegt hat, ist das eine echte Einschränkung. Respektiere sie und lasse alles andere offen.
5. Teile die Arbeit auf
Zerlege das Ziel in die kleinsten Stücke, die separat verbessert und bewertet werden können, und entscheide, welche parallel laufen.
Granularität ist der Hebel. „Mach die Website besser“ ist unbehandelbar. „Mach diesen Preisabschnitt besser als den Referenz-Preisabschnitt“ ist ein Problem, das du angreifen kannst, bis du gewinnst. Gleiches gilt für „Mach p95 unter dieser Last besser als 120ms“ und „Mach diesen Absatz mindestens so klar wie diesen Referenzabsatz“.
6. Baue und bewerte, niemals im selben Kontext
Für jedes Stück ein Builder und ein separater Kritiker. Immer unterschiedliche Kontexte, niemals derselbe Agent.
Der Builder sah jede Entscheidung und erinnert sich, warum er sie getroffen hat, was ihn hervorragend darin macht zu erklären, warum das Ergebnis vernünftig ist. Vernünftig ist nicht das Ziel.
Wise sie mit assets/delegation-templates.md an. Der Kritiker erhält das Ziel, die Latte, die Einschränkungen und das echte Artefakt. Er erhält niemals das Transkript des Builders, die Erklärung des Builders oder welche Seite unsere ist.
Route jede Erzeugung, während du sie erstellst, gemäß der Tabelle aus Schritt 2. Stelle vor jedem Builder die drei Fragen: Ist der Erfolg durch einen Befehl überprüfbar (kein Modell, führe ihn aus), ist der Zielzustand bereits vollständig spezifiziert (kleinstes Modell, minimaler Aufwand) oder erfordert das Schließen der Lücke eine Entscheidung darüber, was gut aussieht (Frontier). Kritiker, die Geschmack beurteilen, sind immer Frontier; Kritiker, die eine Zahl prüfen, führen zuerst den Befehl aus und benötigen nur ein kleines Modell, um ihn zu melden.
Vollständige Prozedur in references/critic-protocol.md. Wesentlich: blinder A/B-Vergleich, inspiziere das echte Ding, binäres Urteil, nenne die einzelne größte Lücke, sende es zurück.
7. Schleife weiter
Setze niemals eine Rundenzahl. Jede vereinbarte letzte Runde wird zu einer Obergrenze.
Stoppe, wenn eines dieser Kriterien wahr ist, und halte fest, welches:
- Der Benutzer erklärt es von der Progress-Datei aus für erledigt.
- Die Gewinne pro Runde haben aufgehört, für das Ziel wichtig zu sein.
- Das Rechenbudget ist aufgebraucht, gemessen am in Schritt 2 festgelegten Budget.
Erhöhe ein Stück nur auf Beweise hin eine Stufe: zwei aufeinanderfolgende Verluste in derselben Lücke erhöhen seinen Aufwand, ein dritter erhöht sein Modell. Ein Stück, das zu gewinnen beginnt, fällt für den Rest des Laufs wieder zurück. Wenn 80% des Budgets ausgegeben sind, füge Stücken, die bereits gewinnen, keine weiteren Runden hinzu und stecke den Rest in das Stück, das am weitesten von der Latte entfernt ist.
Wenn dieselbe Lücke drei aufeinanderfolgende Runden überlebt, stoppe dieses Stück und entscheide auf Führungsebene neu. Es ist strukturell, oder die Latte ist für dieses Stück falsch, oder Builder und Kritiker messen unterschiedliche Dinge. Zu diesem Zeitpunkt mehr dafür auszugeben, ist der häufigste Weg, ein Budget für nichts zu verbrennen.
8. Führe eine Live-Progress-Datei
Pflege eine einfache HTML-Seite oder Markdown-Datei im Workspace, die aktualisiert wird, während Arbeit eintrifft: Screenshots, Entwürfe, Testergebnisse, Runde-für-Runde-Urteile, offene Lücken. Über-spezifiziere das Format nicht und teile dem Benutzer in deiner ersten Ausgabezeile mit, wo es ist.
Dies existiert, damit der Benutzer zusehen kann, ohne zu unterbrechen. Unterbrechung kostet einen Kontextfenster und bricht die Schleife.
9. Glättungspass zwischen Wellen
Wenn viele Agenten separate Teile eines Artefakts bearbeiten, werden die Teile einzeln gut und insgesamt inkohärent.
Am Ende jeder größeren Welle erzeuge einen neuen Agenten, um das gesamte Ergebnis zu inspizieren, Konflikte zu lösen und es wie eine Sache wirken zu lassen. Es gestaltet nichts neu.
Nützlich, nicht zentral. Der Kern bleibt: aufteilen, bauen, bewerten, wiederholen.
Abschluss des Laufs
Liefere das Artefakt aus, dann eine kurze Zusammenfassung mit:
- Der verwendeten Latte und warum.
- Wie weit die Arbeit dagegen gekommen ist.
- Der letzten ungeschlossenen Lücke, die die Übergabe für denjenigen darstellt, der es als nächstes aufnimmt.
- Annahmen, die anstelle nicht gestellter Fragen getroffen wurden.
- Welches Stoppkriterium den Lauf beendet hat.
- Was es gekostet hat: gelaufene Runden, ungefähr wohin das Budget ging, und jedes Stück, das einen großen Anteil verbraucht hat, ohne sich zu bewegen.
Kein Lob für die Arbeit. Die Urteile des Kritikers haben bereits alles gesagt, was wichtig ist.
Anti-Patterns
| Symptom | Lösung |
|---|---|
| Dem Benutzer einen Prompt zum Selbstausführen geben | Führe das Protokoll aus, das ist der ganze Sinn |
| „Das sieht großartig aus!“ vom Builder | Erzeuge einen Kritiker mit sauberem Kontext, ohne Verlauf |
| Kritiker liest einen Bericht statt des Artefakts | Erzwinge die Inspektion der realen Ausgabe |
| Subjektive Latte („Weltklasse“, „Apple-Niveau“) | Ersetze durch ein konkretes, zu öffnendes Artefakt |
| Zerlegung vor dem Betrachten des Artefakts festgelegt | Lass die Form aus der Arbeit entstehen |
| „Mache 3 Iterationen“ | Offene Schleife mit explizitem Stopp-Kriterium |
| Fragen, welche Referenz verwendet werden soll | Wähle eine, begründe in einem Satz, fahre fort |
| Statusaktualisierungen in der Unterhaltung | Live-Progress-Datei |
| Gute Teile, inkohärentes Ganzes | Glättungspass am Ende der Welle |
| Latte in Runde eins bestanden | Die Latte war zu niedrig, erhöhe sie |
| Dieselbe Lücke überlebt drei Runden | Eskaliere, es ist strukturell |
| Jeder Agent erbt Sitzungsmodell und -aufwand | Route jede Erzeugung: Frontier für Urteile, klein für mechanische Arbeit |
| Frontier-Modell mit maximalem Aufwand benennt eine Variable um | T1 mit minimalem Aufwand oder ein Befehl ohne Modell |
| Billiger Kritiker, um eine Runde zu sparen | Regel null. Ein schwacher Kritiker genehmigt früh und hebt die Methode auf |
| Billiger Builder bei einem Stück über Geschmack | Vier verlorene Runden kosten mehr als ein teurer Gewinn |
| Erhöhen der Stufe, weil ein Stück sich schwer anfühlt | Eskaliere bei wiederholten Urteilen, nicht bei Bauchgefühlen |
| Kritiker-Budget, ausgegeben für zusätzliche Bau-Runden | Die Reserve ist kein Pool. Urteile bekommen es |