dknchris/multimodel-review

Multi-Modell-Überprüfung (Codex + Claude)

Unabhängige Reviewer lesen denselben Prompt zum selben Commit. Diese Sitzung ist die einzige Korrekturinstanz. Führen Sie es von einer Sitzung auf Opus 5.5 mit hohem Aufwand aus.

Optionen: $ARGUMENTS

Einstellungen

• Rundenbegrenzungen: Code 20 bis 50 (Standard 20; die Auswahloptionen Standard, Lang und Max sind 20, 35 und 50), Docs 2, Final 2, plus 2 bis 6 Reserve-Runden für Evidenzrunden (Standard 2). Harte Grenze: Ihre Summe, standardmäßig 26. Jede Phase endet mit ihrer ersten sauberen Runde, daher sind die Begrenzungen Obergrenzen. Ältere Läufe behalten ihre eigenen Begrenzungen und Limits.
• Reviewer: Terra (gpt-6.1-terra) und Opus (Opus 5.5) standardmäßig. Optional: Fable (Fable 5.2), Astra (gpt-6-astra), Sol (gpt-6.1-sol), Sonnet (Sonnet 5.5), Haiku (Haiku 5.5) und Luna (gpt-6-luna). Läufe, die vor dieser Änderung gestartet wurden, nennen ihren Opus-Reviewer claude.
• Aufwand wird pro Reviewer und Lauf festgelegt: niedrig, mittel, hoch, sehr hoch oder maximal. Standard: Codex maximal, Claude-Modelle sehr hoch.
• Standard-Panel: terra:max:fast opus:xhigh code:20 spare:2.
• Codex-Schnellmodus (Prioritätsstufe) wird pro Codex-Reviewer und Lauf festgelegt. Er gilt nie für Claude-Modelle.
• Jeder Codex-Lauf wird nach 10 Minuten Stille oder 60 Minuten insgesamt gestoppt. Abstürze und leere Antworten erhalten 1 Wiederholung. Eine Antwort wird niemals aufgrund ihres Formats wiederholt.

Das folgende Hilfsprogramm erzwingt diese Grenzen und behält den gesamten Zustand in ~/.claude/multimodel-review/, außerhalb jedes Repos, weil ein langer Lauf komprimiert wird und der Bericht nicht aus dem Speicher neu erstellt werden kann. Schreiben Sie seinen Pfand jedes Mal vollständig aus und fügen Sie --repo <pfad> vor dem Unterbefehl hinzu, wenn sich die Shell nicht im Repo befindet:

python3 ~/.claude/skills/multimodel-review/scripts/mmr.py status

Im Folgenden steht mmr <befehl> kurz für diesen vollständigen Aufruf.

Starten oder fortsetzen

1. Führen Sie mmr status aus. Wenn ein unvollendeter Lauf existiert, fahren Sie mit dem fort, was er anzeigt, mit den Reviewern, die er auflistet. Wenn "Alter Speicherort" angezeigt wird, führen Sie mmr migrate aus, sobald alle Reviewer fertig sind, und verwenden Sie dann nur den neuen Pfad.
2. Wählen Sie Optionen, vor jedem anderen Schritt, damit der Besitzer sie sofort sieht:
   • Wenn die Optionszeile oben nur pick (oder picker) ist: Zeigen Sie die Auswahl (nächsten zwei Aufzählungspunkte).
   • Andernfalls, ob sie leer ist oder nicht: Führen Sie mmr options "<optionen>" aus und zeigen Sie keine Auswahl an. Leer bedeutet die Standardwerte, terra:max:fast opus:xhigh code:20 spare:2. Wenn es fehlschlägt, zeigen Sie dem Besitzer den einzeiligen Fehler an und stoppen Sie. Jeder Reviewer ist name[:aufwand][:fast]: Aufwand standardmäßig maximal für Codex und sehr hoch für Claude-Modelle, und ein Codex-Modell läuft mit Standardgeschwindigkeit, es sei denn, :fast wird angegeben. code:<20-50> und spare:<2-6> sind optional (Standard 20 und 2).
   • Auswahl, wenn show_widget verfügbar ist: Rufen Sie read_me einmal mit den Modulen ["interactive"] auf. Führen Sie dann mmr picker aus und übergeben Sie alles nach seiner Widget code:-Zeile unverändert als widget_code, mit dem Titel multimodel_review_options. Beenden Sie die Runde und warten Sie. Sein Button sendet "Start the review with .", in derselben getippten Form, zum Beispiel "terra:max:fast opus:xhigh code:20 spare:2". Führen Sie mmr options "<optionen>" darauf aus. Wenn die Nachricht des Besitzers besagt, dass die Auswahl nicht geladen wurde, führen Sie mmr picker --offline aus und zeigen Sie stattdessen diese an.
   • Auswahl in einem Terminal (kein show_widget): Ein AskUserQuestion-Aufruf mit vier Fragen: Reviewer (Mehrfachauswahl: Terra, Opus, Fable, Astra; Sol, Sonnet, Haiku und Luna über Sonstige), Codex-Modelle im Schnellmodus (Mehrfachauswahl: Terra, Astra, Sol, Keiner; Luna über Sonstige), Aufwand (Codex maximal und Claude sehr hoch, alles hoch, alles mittel) und Überprüfungslänge (Standard code:20, Lang code:35, Max code:50). Ignorieren Sie eine Schnellauswahl, die kein ausgewählter Reviewer ist. Schreiben Sie die Antworten in der getippten Form und führen Sie mmr options "<optionen>" darauf aus.
3. Schreiben Sie eine 3-5-zeilige Absicht in eine Scratchpad-Datei mit dem Write-Tool: Was die Änderung tun soll und für wen. Nehmen Sie es aus der Anfrage, diesem Gespräch, PR-Text, Commits oder dem nicht committeten Diff. Reviewer können "falsches Verhalten" ohne diese nicht beurteilen. Wenn es unklar ist, fragen Sie den Besitzer eine Frage mit Buttons.
4. Lesen Sie git status --short. Alles Nicht-Ignorierte wird in den Snapshot committet, daher wählen Sie alles aus, das nichts mit dieser Änderung zu tun hat (ein fremder Ordner, Notizen) und übergeben Sie es als --leave-out <pfad>. Wenn Sie es nicht sagen können, fragen Sie mit Buttons.
5. Führen Sie mmr init --intent-file <datei> --trailer "<attributionszeile>" --spec "<optionen>" aus, mit den Optionen genau wie die Init:-Zeile von mmr options sie ausgegeben hat, und fügen Sie --base <basis> nur hinzu, wenn der Besitzer eine genannt hat, und --leave-out <pfad> nach Bedarf. Die Basis standardmäßig auf den Standard-Branch des Remotes, und die Überprüfung beginnt vom Merge-Base. Die Verwendung dieses Skills ist die Zustimmung des Besitzers zu dem, was init tut:
   • Auf dem Basis-Branch oder einem detached HEAD erstellt es zuerst multimodel-review/<zeit>, sodass WIP-Commits niemals auf der Basis landen.
   • Nicht committete Arbeit wird zu einem WIP-Snapshot-Commit, sodass alle Reviewer denselben Commit lesen. Es wird nichts gepusht.
   • Exit-Code 5 bedeutet, dass einige Dateien wie Geheimnisse aussehen, über 20 MB groß sind oder eingebettete Repositories sind. Es hat sich noch nichts geändert. Fragen Sie den Besitzer mit Buttons: Lassen Sie sie aus (--leave-out) oder schließen Sie sie ein (--allow-flagged).
   • "Nichts zu überprüfen" bedeutet keine Commits und keine nicht committete Arbeit. Fragen Sie den Besitzer, welche Commits überprüft werden sollen, und übergeben Sie dann --base <commit>.
6. Teilen Sie dem Besitzer in einer Zeile mit, ob init einen Branch oder einen Snapshot erstellt hat.

Eine Runde

1. Führen Sie mmr next --phase <code|docs|final|evidence> aus. Es erstellt die Prompt-Datei und gibt ihren Pfad, die Einstellungen des Laufs und eine Claude Agent-Zeile pro Claude-Reviewer mit seinem Modell, Aufwand und Antwortdatei aus. Exit-Code 3 bedeutet, dass eine Grenze erreicht wurde: Gehen Sie zu Fertig.
2. Starten Sie jeden Reviewer, den mmr status auflistet, in einer Nachricht:
   • Jeder Codex-Reviewer (terra, astra, sol, luna): Bash mit run_in_background: mmr codex --reviewer <name>. Das Hilfsprogramm führt Codex mit -s read-only, ausgeschalteten Apps, Plugins und Subagenten, eingeschalteter Websuche, eigenen Logs und den Zeitlimits aus. Verwenden Sie niemals workspace-write oder --dangerously-bypass-approvals-and-sandbox, das Begleitskript oder den Rettungs-Subagenten.
   • Ein Monitor pro Codex-Reviewer: mmr monitor --reviewer <name>, mit timeout_ms: 1800000. Es prüft alle 60 Sekunden und entscheidet "fertig" anhand des PID-Exits, niemals anhand des Ausgabetextes.
   • Jeder Claude-Reviewer (opus, fable, sonnet, haiku; claude in älteren Läufen): Ein neuer Agent mit subagent_type: "multimodel-reviewer", model und effort aus seiner Claude Agent-Zeile und dem Prompt "Review round file: ". Dieser Agent hat Lese- und Web-Tools, aber keine Shell- oder Edit-Tools. Wenn der Typ nicht verfügbar ist, verwenden Sie Plan mit demselben Modell und Aufwand und sagen Sie ihm, dass es nur Read, Grep und Websuche verwenden soll.
3. Behandeln Sie Monitor-Ereignisse:
   • FINISHED: Nichts zu tun.
   • FAILED: Wiederholen Sie wie in Schritt 5 und teilen Sie es dem Besitzer nur in einer Zeile mit, wenn die Wiederholung ebenfalls fehlschlägt.
   • QUIET: Kein Fehler, da hoher Aufwand minutenlang still denken kann. Ergreifen Sie keine Maßnahmen; das Hilfsprogramm stoppt einen Reviewer nach 10 stillen Minuten.
   • RE-ARM: Starten Sie diesen Monitor erneut.
4. Wenn ein Claude-Agent zurückkommt, schreiben Sie seine letzte Nachricht unverändert in seine Antwortdatei aus Schritt 1 und führen Sie dann mmr claude-result --reviewer <name> --seconds <dauer_ms / 1000> aus.
5. Führen Sie mmr barrier aus. Bearbeiten Sie nichts, bis es bestanden ist. Wenn ein Ergebnis leer oder fehlend ist, wiederholen Sie nur diesen Reviewer, zum selben Commit; die Runde zählt nicht erneut. Für einen Claude-Reviewer starten Sie einen neuen Agenten und wiederholen Schritt 4. Das Hilfsprogramm verweigert einen dritten Versuch und jede Wiederholung nach einem Stillstand oder Timeout: Führen Sie dann mmr stop --reason "<warum>" aus und gehen Sie zu Fertig. Ausnahme: Ein Lauf von vor dem Entfernen der Formatregeln kann malformed bei einer echten Antwort anzeigen. Führen Sie mmr reread --reviewer <wer> aus, das die gespeicherte Antwort erneut liest, ohne einen neuen Reviewer-Lauf.
6. Triage (siehe Fixer-Regeln) und schreiben Sie triage.tsv in den Rundenordner mit dem Write-Tool.
7. Korrigieren Sie akzeptierte Funde, führen Sie die betroffenen Tests aus und machen Sie einen WIP-Commit. Ein fehlgeschlagener Test blockiert die Runde, sodass eine schlechte Korrektur nicht das nächste Delta erreichen kann.
8. Führen Sie mmr close --tests "<genauer testbefehl>" aus, oder --tests "none: docs only". Wenn nichts akzeptiert wurde, lassen Sie --tests weg. Folgen Sie der Next:-Zeile, die es ausgibt.

triage.tsv ist tabstoppgetrennt, eine Zeile pro zusammengeführtem Fund und kann nur weggelassen werden, wenn jeder Reviewer "NO BLOCKING ISSUES." geantwortet hat:

reviewers	sev	loc	status	summary	note
terra,opus	P1	src/a.py:42	accepted	Retry drops the last item	src/a.py: Keep the last item on retry
terra	P1	src/b.py:9	rejected	Null token crashes	Token is non-null: src/auth.py:30 returns early

• status ist accepted, rejected oder open. open ist nur für die letzte erlaubte Runde, in der eine Korrektur nicht überprüft würde.
• note ist, was sich geändert hat (akzeptiert), der code-begründete Grund (abgelehnt) oder warum es offen gelassen wird (offen). Akzeptierte und abgelehnte Notizen speisen die Korrekturliste und das Register des nächsten Prompts.
• Lehnen Sie phasenfremde Funde als "Out of phase" ab.
• Reviewer können in jedem Format antworten, daher lesen Sie jede Antwort selbst. Fundzahlen sind beste Schätzungen. Eine Antwort ohne P0/P1/P2-Tags zählt als ein Fund: Fügen Sie eine Zeile für das hinzu, was sie aufwirft, oder eine rejected-Zeile, wenn sie nichts aufwirft.

WIP-Commits: Nachricht WIP multimodel-review round <N>, in eine Datei geschrieben und mit git commit -F übergeben, plus die Attributionszeilen der Sitzung. Niemals pushen.

Phasen

1. Code: Runden 1-2 überprüfen den vollständigen Diff gegen die Basis. Ab Runde 3 nur das Delta plus die Korrekturliste. Reviewer können jede Datei für Kontext öffnen. Außerhalb des Deltas melden sie nur P0, es sei denn, das Delta verursacht den Fehler: Dann verankert der Fund in der Delta-Zeile mit seiner tatsächlichen Schwere.
2. Cleanup (nur Fixer): Läuft vor Docs, sodass jeder hier geschriebene Text eine P2-Überprüfung erhält.
   • Docs: Aktualisieren Sie nur Docs, die durch diese Änderung veraltet wurden. Kürzen, nicht erweitern.
   • Tests: Löschen Sie nur Debugging- oder Gerüsttests und Tests für entfernten Code. Behalten Sie Regressionstests.
   • Führen Sie die vollständige Testsuite aus. Wenn sie fehlschlägt, korrigieren Sie sie; wenn Sie es nicht mit einer kleinen Korrektur schaffen, stoppen und melden.
   • Committen, dann schreiben Sie cleanup.md in den Lauf-Ordner: Jede Löschung mit ihrem Grund und der genaue Testbefehl und das Ergebnis. next --phase docs verweigert ohne diese.
3. Docs: Eine vollständige Diff-Runde bei P2, korrigieren, dann eine Delta-Runde. Dann endet die Phase; alles Übriggebliebene wird als offen aufgezeichnet.
4. Final: Eine vollständige Diff-Runde mit allen Reviewern, nur P0/P1. Wenn ein Fund akzeptiert wird, korrigieren Sie ihn und führen eine Delta-Runde aus. Wenn diese immer noch fehlschlägt, markieren Sie ihn als offen; das Hilfsprogramm stoppt den Lauf.

Konvergenz

• Eine Runde ist sauber, wenn der Fixer keinen Fund auf der Schwere der Phase akzeptiert. Funde, die mit einer code-begründeten Begründung abgelehnt wurden, blockieren nicht.
• Eine Phase konvergiert bei ihrer ersten sauberen Runde.
• Neue Evidenz nach Code-Konvergenz (Geräte- oder Emulatorlauf): Aktualisieren Sie den betroffenen Code oder Text einmal, committen, dann führen Sie mmr next --phase evidence --note "<was der Lauf zeigte und was sich geändert hat>", eine Delta-Runde bei P0/P1/P2. Code wird nur wieder geöffnet, wenn ein P0/P1 akzeptiert wird, und close sagt dies.
• Bei einer Phasengrenze oder dem harten Stopp: Stoppen und melden, was übrig ist.

Fixer-Regeln

• Zusammenführen und deduplizieren, wobei jeder Reviewer, der einen Fund aufgeworfen hat, erhalten bleibt, damit die Statistiken ehrlich bleiben. Überprüfen Sie jeden Fund am Code; lehnen Sie nicht verifizierbare mit einem einzeiligen Grund ab.
• Beurteilen Sie Funde allein am Code, unabhängig davon, wer sie aufgeworfen hat. Sie sind auch ein Claude-Modell, also halten Sie die Funde der Claude-Reviewer an denselben Standard. Das Ablehnen eines Funds, der von 2+ Reviewern aufgeworfen wurde, oder jedes P0, erfordert eine spezifische Code-Zitation; der Bericht listet diese als strittig für den Besitzer auf.
• Kleinste Korrektur. Keine Refactorings, keine neuen Funktionen. Fügen Sie nur für echte P0/P1-Fehler einen Regressionstest hinzu.
• Weniger Prosa schreiben: Bevorzugen Sie das Löschen oder Eingrenzen eines falschen Satzes gegenüber dem Hinzufügen eines neuen. Neue Kommentare sind höchstens eine Zeile lang. Fügen Sie während der Überprüfung keine neuen Dokumentationsabschnitte hinzu.
• Wenn ein Hook einen Pfad ablehnt, stoppen und an den Besitzer melden. Niemals umgehen, weder mit einer Shell-Kopie noch auf andere Weise.
• Shell-Befehle dcg-sicher halten: Dateien mit dem Write-Tool schreiben und keine Variablen, Globs oder Umleitungen zu variablen Pfaden in Befehle setzen.

Fertig

Führen Sie dies bei Konvergenz und bei jedem Stopp aus.

1. Führen Sie mmr archive aus, um jeden Codex-Chat, einschließlich Wiederholungen, zu archivieren.
2. Führen Sie mmr report aus. Es gibt Runden pro Phase, die Reviewertabelle, offene Punkte, strittige Funde, Testbefehle und den Squash-Befehl aus und speichert report.md.
3. Berichten Sie dem Besitzer, kurz und Antwort zuerst: Runden pro Phase, offene Punkte, genaue Validierungsbefehle und -ergebnisse.
4. Zeigen Sie eine einfache visuelle Darstellung pro Reviewer inline an: Aufgeworfene Funde, akzeptierte, abgelehnte, einzigartige, P0-P1 vs. P2, saubere Runden, durchschnittliche Minuten pro Runde. Nennen Sie Ihren Gewinner in einer Zeile. Die Standardregel ist die meisten akzeptierten einzigartigen P0/P1, und Sie sollten sagen, ob Sie sie überstimmen, da Sie auch Ihr eigenes Modell beurteilen.
5. Lassen Sie die WIP-Commits an Ort und Stelle, da Evidenzrunden den Delta-Bereich benötigen. Fragen Sie mit einem Button, ob jetzt gesquasht werden soll, und führen Sie den Squash nur bei einem Ja aus dem Bericht aus.

Ändern dieses Skills

Dieser Ordner ist das öffentliche Repo github.com/dknchris/multimodel-review. Committen Sie jede Änderung und pushen Sie nur, wenn der Besitzer es sagt. Der Code des Auswahl-Tools ist assets/picker.js: mmr picker lädt es vom CDN, sobald sein neuester Commit gepusht ist, und sendet es bis dahin inline, was langsamer ist. Führen Sie nach jeder Änderung python3 tests/test_mmr.py aus.