Was macht Claudex Loop?
Die aktuelle Konversation besitzt die Anforderungen, Planung und Koordination. Der andere Anbieter prüft den Plan. Beide Anbieter können bauen; der Anbieter, der nicht gebaut hat, inspiziert den endgültigen Code in einer neuen Sitzung.
Rollen einmalig festlegen
Ermittle den tatsächlichen Host aus deiner Laufzeitumgebung, nicht aus PATH, installierten Skills, Modellnamen-Ratereien oder dem Repository. Beide CLIs können installiert sein. Verwende host=claude in Claude Code und host=codex in Codex. Falls die Laufzeitidentität nicht verfügbar ist, frage den Benutzer einmal, welchen Host er verwendet.
| Host | Anforderungen und Plan | Planprüfer | Standard-Builder | Endprüfer |
|---|---|---|---|---|
| Claude Code | Aktuelle Claude-Sitzung | Codex | Claude | Neue Codex-Sitzung |
| Codex | Aktuelle Codex-Sitzung | Claude | Codex | Neue Claude-Sitzung |
Beachte builder=claude|codex. Der Prüfer ist immer der andere Anbieter. Der Host bleibt Koordinator, auch wenn der andere Anbieter baut. Um den Planer zu tauschen, starte die Konversation im anderen Host; gib nicht vor, dass ein CLI-Prüfer die Planungskonversation des Benutzers ist.
Die Modellauswahl ist unabhängig von den Anbieterrollen. Behalte das ausgewählte Modell des Hosts bei. Prüf-/Build-CLI-Aufrufe übernehmen ihre eigene Konfiguration, es sei denn, reviewer_model, builder_model oder inspector_model wird angegeben; ordne diese dem --model des Ausführenden für diesen Aufruf zu. Wende ein explizites *_effort ähnlich an. Fable 5.1 und GPT-6 Astra sind geeignete explizite Wahlmöglichkeiten, keine zwingenden Vorgaben. Ein Modell in der Host-Oberfläche beweist nicht, welches Modell eine separate CLI verwenden wird. Melde angeforderte und beobachtete Modellinformationen getrennt; melde eine ungelöste CLI-Standardauswahl ehrlich. Falle niemals stillschweigend auf ein anderes Modell/Anbieter bei einem Fehler zurück.
Lies die Laufzeitreferenz, bevor du eine CLI startest. Ermittle deren Ausführungspfad relativ zu dieser installierten SKILL.md, niemals relativ zum zu prüfenden Projekt. Verwende absolute Pfade beim Starten.
Wenn der Benutzer codex_cli oder claude_cli angibt, ordne den ausgewählten ausführbaren Pfad des Anbieters dem Parameter --cli zu. Eine Host-App kann eine neuere funktionierende Binärdatei haben als die CLI im PATH; überprüfe den Pfad und die Version, ohne stillschweigend die globale Installation oder Konfiguration zu ändern.
Einstellungen
| Argument | Standard | Bedeutung |
|---|---|---|
PLAN_FILE / plan | PLAN.md | Planpfad, der im gesamten Ablauf inklusive Build-Übergabe verwendet wird |
LOG_FILE / log | PLAN-REVIEW-LOG.md | Append-Only-Protokoll |
rounds / MAX_ROUNDS | 5 | Maximale abgeschlossene Plan-Prüf-Runden |
builder | host | Anbieter, der den Plan implementiert |
research | angemessen zur Aufgabe | none, web oder explizites Opt-in deep |
mode | full | full beinhaltet Aufklärung/Interview; review startet mit einem bestehenden Plan |
inspect | on | off nur, wenn der Benutzer explizit abwählt; dokumentieren |
MAX_FIX_ROUNDS | 2 | Begrenzte Build-Fix-Versuche vor Meldung oder Übernahme |
MAX_INSPECTION_ROUNDS | 2 | Erste Inspektion plus eine nach Korrekturen |
Gib Rollen, Pfade, Rundenlimits, angeforderte Modelle und den Inspektionsverzicht vor dem Start aus. Bewahre bestehende Autorisierungen: Eine Aufforderung zum Planen autorisiert kein Bauen; eine Aufforderung zum Planen und Implementieren hingegen schon. Führe autorisierte Vorbereitungen durch, bevor du nach verbleibenden Freigaben suchst.
Phase 0 – Aufklärung
Für bestehende Projekte: Prüfe relevanten Code, Abhängigkeiten, Aufrufer und Schreiber von gemeinsam genutztem Status. Lies bestehende CONTEXT.md / CONTEXT-MAP.md und relevante ADRs. Bei Neuanfang: Recherchiere Stand der Technik, einen angemessenen Stack und konkrete Fehlermodi, wenn sinnvoll. Respektiere eine explizite Forschungstiefe. Tiefgehende Multi-Agenten-Recherche erfordert explizites Opt-in und ein verfügbares Werkzeug; verwende andernfalls unterstützte gezielte Recherche und melde die Einschränkung. Kein proprietäres Workflow-Tool erforderlich; hinterlege kein festes Modell für den Recherche-Agenten.
Entdecke relevante Fähigkeiten über den verfügbaren Katalog des Hosts und die dokumentierten Skill-Speicherorte des anderen Anbieters, wenn zugänglich. Dokumentiere nur relevante vorgeschlagene Abhängigkeiten. Gehe nicht davon aus, dass Host-MCP, Browser, Anmeldedaten oder Fähigkeiten auf die andere CLI übertragbar sind. Überprüfe erforderliche Build-Fähigkeiten, bevor du dich auf sie verlässt.
Lege ein Annahmen-Register mit Quellpfaden oder Forschungslink vor. Bitte um Korrekturen bei wesentlichen Unsicherheiten als Stapel. Löse routinemäßige reversible Entscheidungen selbst, wenn der Benutzer die Arbeit autorisiert hat; Stillschweigen ist keine Zustimmung zu einer Handlung, die eine Genehmigung erfordert.
Phase 1 – Anforderungen festlegen
Führe eine kurze sichtbare Entscheidungskarte. Frage nur nach ungelösten Entscheidungen, die das Ergebnis ändern. Gib bei jeder folgenreichen Frage die Empfehlung, warum es wichtig ist und die Kosten einer falschen Annahme. Bündele unabhängige Fragen; stelle abhängige sequentiell. Wenn der Code die Antwort geben kann, prüfe ihn stattdessen. Biete „Alle verbleibenden Empfehlungen annehmen“ an, wenn eine lange Entscheidungsliste den Benutzer ausbremsen würde.
Respektiere bestehende Glossardefinitionen; löse mehrdeutige Fachsprache auf. Pflege glossarbasierten Kontext träge mit CONTEXT-FORMAT.md. Dokumentiere ein ADR nur für teure, nicht-offensichtliche Abwägungen mit ADR-FORMAT.md.
Schreibe die aufgelöste PLAN_FILE mit:
- Ziel und beobachtbaren Abnahmekriterien.
- Konkreter Ansatz, wichtige Entscheidungen, Abwägungen und Nicht-Ziele.
- Bestätigte Annahmen mit Quellen und verbleibenden Risiken.
- Relevante Toolchain-Anforderungen pro Anbieter, falls vorhanden.
- Verifizierung: exakte Beweiskommando(s), erwartete Ergebnisse und manuelle/visuelle Prüfungen, wenn nötig.
Leite Beweiskommandos nach Möglichkeit aus dem Repository ab. Frage nur, wenn unklar bleibt, was als Erfolg zählt. Starte das Append-Only-LOG_FILE mit Rollen, Modellanforderungen, Umfang, Autorisierung und Rundenlimits. Halte Ausführungsdiagnosen außerhalb des Checkouts.
Mit mode=review lade den bereitgestellten Plan, fülle nur wesentliche Lücken bei Bedarf mit dem Benutzer und fahre direkt mit der Prüfung fort; starte kein Anforderungsinterview neu.
Phase 2 – Unabhängige Planprüfung
Verwende den gemeinsamen Ausführer im review-Modus mit dem tatsächlichen --host, aufgelöstem --plan und optionalem Modell/Aufwand. Die erste Runde erstellt eine Sitzung. Weitere Runden verwenden --resume <vorheriges-erfolgreiches-ergebnis.json> mit demselben Anbieter/Modell/Aufwand und einer vom Host erstellten --feedback-Datei mit Verfügungen. Verwende niemals eine geratene Sitzungs-ID, --last oder eine Build-Sitzung als Prüfer.
Jede erfolgreiche Antwort enthält ein Urteil, evidenzgestützte Befunde, tatsächliche Abdeckung und Einschränkungen. Bewahre die gesamte Antwort und den Ergebnis-Pfad des Ausführers in LOG_FILE auf.
- APPROVED: keine ungelösten wesentlichen Mängel. Die Genehmigung ist an den exakten Planpfad und SHA256 gebunden. Nenne verbleibende Ratschläge mit niedriger Priorität und Einschränkungen; null Befunde ist gültig und kein Beweis für erschöpfende Korrektheit.
- REVISE: der Host entscheidet über jeden Befund. Nimm berechtigte Planänderungen vor; lehne unbegründete Vorschläge mit Begründung ab. Dokumentiere Verfügungen und sende den überarbeiteten Plan an denselben Prüfer. Vermeide die Wiederaufnahme gelöster Punkte ohne neue Beweise.
- BLOCKED / fehlgeschlagener Prozess / fehlerhaftes Ergebnis: zähle dies niemals als Genehmigung. Erkläre die tatsächlichen fehlenden Beweise oder betrieblichen Fehler. Verbrenne keine verbleibenden Runden mit blinden Wiederholungen oder wechsle nicht stillschweigend den Anbieter.
Stoppe bei MAX_ROUNDS. Präsentiere ungelöste Befunde und die Position des Hosts, anstatt Konvergenz zu erzwingen. Ein geänderter Plan erfordert eine erneute Prüfung. Führe vor dem Bauen die Genehmigungsprüfung des endgültigen Plans durch. Wenn der Benutzer sich ausdrücklich dafür entscheidet, ohne unabhängige Genehmigung fortzufahren, dokumentiere diese Überschreibung und verwende den eigenständigen, nicht geprüften Spezifikationspfad; bezeichne es niemals als genehmigt.
Phase 3 – Bauen und Prüfen
Präsentiere den geprüften Plan, Verbesserungen und verbleibende Grenzen. Falls die Implementierung noch nicht autorisiert ist, bitte um diese finale Entscheidung. Verwende den ausgewählten Builder, standardmäßig den Host. Lies die Build-Referenz.
Der Host kann direkt mit seinen normalen Werkzeugen implementieren. Für einen anderen Builder verwende den build-Modus des gemeinsamen Ausführers. Beide Pfade müssen den Pre-Build-Commit erfassen, nicht zugehörige Benutzerarbeit bewahren und denselben aufgelösten Plan und Verifizierungsvertrag tragen.
Führe die vereinbarten Beweisprüfungen durch, inspiziere alle geänderten Dateien und überprüfe das Ergebnis durch den anderen Anbieter in einer neuen inspect-Sitzung. Gib den Pre-Build-Commit und die Builder-Identität an. Eine erneute Inspektion nach akzeptierten Korrekturen verwendet ebenfalls eine neue Sitzung. Protokolliere Befunde und Verfügungen; führe betroffene Beweisprüfungen nach Korrekturen erneut aus.
Wenn der Koordinator die Codierung übernimmt, wird er zum Builder. Fordere eine neue Inspektion durch den anderen Anbieter seiner Änderungen an; beschreibe die frühere Inspektion niemals als Abdeckung späterer Bearbeitungen. Wenn beide Anbieter Code beigesteuert haben, dokumentiere die Autorenschaft und lasse jeden die Änderungen des anderen inspizieren; behaupte nicht, dass ein Modell unabhängig Code überprüft hat, den es selbst verfasst hat. Wenn das Inspektionsbudget erschöpft ist, melde verbleibende Befunde und nicht überprüfte Änderungen explizit zur Entscheidung des Benutzers.
Präsentiere das endgültige Diff, die Beweisergebnisse, die Inspektionsabdeckung, ungelöste Befunde, Abweichungen und verbrauchte Runden. Respektiere bestehende Commit/Push-Autorisierung; hinterlasse andernfalls das konkrete Diff zur Freigabe bereit. Eine externe Veröffentlichung wird niemals allein durch das Ausführen des Loops impliziert.