RIJUDEVx/interrogate

Was macht interrogate?

Starte pro konfiguriertem Modell einen Reviewer, um Codeänderungen adversariell zu prüfen. Jedes Modell erhält denselben Prompt und dieselbe Rubrik. Das adversarielle Signal entsteht aus der Modellvielfalt, nicht aus zugewiesenen Personas.

Ein Befund bleibt nur dann bestehen, wenn ein Durchlauf ihn beweist.

Das Ergebnis ist eine synthetisierte Bewertung. Wende Änderungen NICHT automatisch an.

Schritt 1: Umfang bestimmen

Ermittle anhand des Kontexts, was zu prüfen ist:

• Wenn der Benutzer auf bestimmte Dateien oder einen Diff zeigt, verwende diese
• Bei einem Feature-Branch führe git diff main...HEAD (oder den entsprechenden Basis-Branch) für den vollständigen Änderungssatz aus
• Wenn die Nachricht des Benutzers sich auf kürzliche Arbeit bezieht, sammle die relevanten Dateien

Verpacke den Diff (oder Dateiinhalte) sowie alle nötigen Kontextdateien, die die Reviewer zum Verständnis des Codes benötigen.

Schritt 2: Absicht formulieren

Bevor die Reviewer gestartet werden, formuliere die Absicht explizit. Leite sie ab aus:

• Der Nachricht des Benutzers
• Commit-Nachrichten
• Der PR-Beschreibung, falls vorhanden
• Dem Code selbst

Schreibe einen klaren Absatz. Wenn du dir über die Absicht unsicher bist, frage den Benutzer, bevor du fortfährst.

Schritt 3: Reviewer starten

Starte alle Reviewer in einer einzigen Nachricht, einen pro Slot, mit dem Sub-Agent-Tool der Umgebung oder delegate_task.

Ziele auf Modellvielfalt: Verschiedene Modellfamilien erkennen unterschiedliche Fehler. Wähle in T3 Code 3-4 starke Modelle aus den Favoriten des Benutzers aus verschiedenen Familien aus und starte jedes mit delegate_task (das t3-tools-Skill enthält die Schritte). Wähle woanders 3-4 verschiedene leistungsstarke Modelle, die die Umgebung bereitstellt. Wenn du kein Modell pro Sub-Agent auswählen kannst, starte Reviewer ohne Modellüberschreibung und erziele Vielfalt durch unabhängige Kontexte.

Subagent	Rolle
Reviewer A	Reasoning-schwerer Reviewer
Reviewer B	Zweite, unabhängige Modellfamilie
Reviewer C	Dritte, schnelle/andere Familie
Reviewer D	Adversarieller/strikter Codequalitäts-Reviewer

Starte für jeden Reviewer einen allgemeinen Sub-Agenten:

• OpenCode / Codex: subagent_type: general (über das task-Tool)
• Claude Code: subagent_type: general-purpose
• Andere Umgebungen: Der nächstgelegene allgemeine Sub-Agent, der das Repository lesen kann

Halte die Reviewer im Geiste schreibgeschützt: Sie dürfen keine Dateien bearbeiten. Ein Reviewer, der eine Reproduktion benötigt, führt diese in seiner eigenen Arbeitskopie oder Worktree aus, niemals direkt.

Gib jedem Reviewer diesen Kurzbefehl zusammen mit der ausgefüllten Vorlage:

Zerlege diese Änderung. Beweise jeden Befund mit einem Durchlauf gegen den echten Code, z. B. einem fehlschlagenden Test, einem Reproduktionsskript oder einer Befehlsausgabe, die das falsche Verhalten zeigt. Für einen Entwurf oder Plan führe einen Prototyp aus oder durchsuche den aktuellen Baum. Halte Reproduktionen in deinem eigenen Worktree. Melde jeden Befund mit einem Titel, dem genauen Befehl, der ausgegebenen Ausgabe und der Ausgabe, die die Absicht erfordert. Lass alles weg, was du nicht ausgeführt hast. Das deckt Stil, Benennung, Struktur und Risiken ab, die erst in einer zukünftigen Änderung relevant werden. „Keine Befunde“ ist ein gültiges Ergebnis.

Wenn ein Modell-Slug als nicht auflösbar abgelehnt wird, überprüfe die gültigen Slugs in der Fehlermeldung des Task-Tools, wähle das nächstgelegene Äquivalent (bevorzuge die höchste Reasoning-Stufe derselben Familie) und starte mit dem gültigen Slug. Blockiere den Review nicht aufgrund des Slug-Problems.

Lies references/reviewer-prompt.md und fülle die Vorlage mit:

1. Der formulierten Absicht
2. Dem Diff oder Dateiinhalten
3. Der Review-Rubrik aus references/rubric.md
4. Der Codequalitäts-Perspektive aus references/code-quality-review.md

Die gleiche ausgefüllte Vorlage geht an alle Reviewer, sodass jedes Modell die Codequalitäts-Perspektive anwendet.

Schritt 4: Synthese

Wenn Ergebnisse eingehen, erstelle ein einheitliches Bild:

1. Überprüfe jeden Befund, indem du seinen Befehl erneut ausführst. Behalte einen Befund, wenn die Ausgabe den Fehler zeigt und der Fehler die Absicht verletzt. Verwerfe den Rest. Fasse Befunde mit derselben Ursache zusammen.
2. Analysiere alle Befunde aus den Reviewern
3. Identifiziere Konsens. Befunde, die von 2+ Modellen unabhängig gemeldet werden, haben das höchste Signal.
4. Identifiziere Einzelmodell-Befunde. Trotzdem lesenswert, aber entsprechend gewichten.
5. Entdoubliere. Unterschiedliche Modelle können dasselbe Problem unterschiedlich beschreiben. Führe diese zusammen und notiere, welche Modelle es gemeldet haben.
6. Notiere Meinungsverschiedenheiten. Wenn ein Modell etwas beanstandet und ein anderes explizit das Gegenteil sagt, ist das ein nützlicher Kontext für die Bewertung.

Schritt 5: Leitendes Urteil

Du bist der leitende Reviewer, ein pragmatischer Senior-Ingenieur, kein neutraler Zusammensteller.

Lies references/lead-judgment.md für das vollständige Framework.

Kategorisiere jeden Befund in diese Kategorien:

• Handeln. Echte Probleme, die Korrektheit, Sicherheit oder Wartbarkeit angesichts der tatsächlichen Ziele betreffen. Diese würden einen echten PR blockieren.
• Überlegen. Legitime Punkte, aber du bist nicht sicher, ob die Kosten für die Behebung jetzt die Vorteile überwiegen. Der Aufmerksamkeit des Benutzers wert.
• Vermerkt. Technisch gültig, aber nicht handlungsrelevant. Kontextabhängig, vorzeitige Optimierung oder geringe Auswirkung in der aktuellen Phase.
• Abgewiesen. Falsch, pingelig oder fehlender Kontext. Kurze Begründung.

Für jeden Befund füge hinzu:

• Welches Modell(e) ihn gemeldet hat
• Die Kategorie (handeln / überlegen / vermerkt / abgewiesen)
• Eine einzeilige Begründung für die Kategorisierung

Ausgabeformat

Präsentiere die Bewertung in dieser Struktur:

Absicht

[Der Absatz der Absicht aus Schritt 2]

Reviewer

• Reviewer [Label]: [Modellname], [N Befunde] (ein Aufzählungspunkt pro Reviewer)

Handeln

[Befunde, die adressiert werden sollten. Für jeden: Beschreibung, welche Modelle es gemeldet haben, warum es wichtig ist.]

Überlegen

[Befunde, über die es sich nachzudenken lohnt. Für jeden: Beschreibung, welche Modelle es gemeldet haben, der Zielkonflikt.]

Vermerkt

[Gültig, aber niedrige Priorität. Kurze Liste.]

Abgewiesen

[Abgelehnte Befunde mit kurzer Begründung, einschließlich Befunde, die kein Durchlauf bewiesen hat.]

Übereinstimmungslandkarte

[Wo stimmten Modelle überein, wo gingen sie auseinander, und was sagt uns das Muster von Übereinstimmung/Nichtübereinstimmung?]

Sprengradius

Verwende diesen Modus, wenn eine Änderung klein, aber noch nicht vertrauenswürdig ist und die Frage ist, was sie über den Diff hinaus zerbricht. Die Aufrufer aufzulisten ist nicht die Aufgabe. grep findet diese in einer Sekunde. Die Aufgabe ist der Schaden, den grep nicht zeigt.

Vertraue deiner eigenen Beschreibung nicht

Eine Beschreibung, was eine Änderung zerbricht, die richtig klingt, ist wertlos. Sie liest sich unabhängig davon, ob sie wahr ist oder nicht, überzeugend. Gib also nicht die Beschreibung zurück. Finde die eine oder zwei Tatsachen, von denen das Ganze abhängt, und beweise sie durch das Ausführen von Code.

Wie sicher bist du

Bringe jede Tatsache, von der die Sicherheit der Änderung abhängt, so weit wie günstig möglich in dieser Liste nach unten und gib an, wo sie aufgehört hat.

1. Du hast es gesagt. Allein wertlos.
2. Du hast auf die Zeile gezeigt. Ein echter datei:zeile oder der Quellcode der Bibliothek selbst.
3. Du hast gezeigt, dass der schlechte Fall nicht eintreten kann. Du bist den Fehler Schritt für Schritt durchgegangen und hast gezeigt, dass er nicht erreicht wird.
4. Du hast es ausgeführt. Ein Skript oder Test, der den echten Code aufruft und laut fehlschlägt, wenn du falsch liegst.
5. Du hast es in der laufenden Anwendung reproduziert.

Gib für jede Sicherheitstatsache, die du nicht auf Stufe 4 bringen kannst, an. Beschreibe sie nicht als gesichert. Stufe 4 ist normalerweise ein kleines Skript, das dieselbe Bibliothek importiert, die die Anwendung ausliefert, und genau die Funktion aufruft, die dich beunruhigt.

Schritte

1. Lies die Änderung. Den Diff, die Symbole, die sie hinzufügt, ändert und löscht, und was sie jetzt anders macht, einschließlich des Teils, den der Diff nicht buchstabiert. Ziehe die PR- und Commit-Nachrichten für die Begründung dahinter heran.
2. Finde die eine Tatsache, deretwegen sie sicher ist. Die meisten Änderungen, die riskant aussehen, sind aufgrund einer einzigen Tatsache sicher, wie „dieser Aufruf löscht nur bereits tote Cache-Einträge und tut nichts anderes“. Finde diese Tatsache. Wenn sie gilt, sind die meisten riskanten Fälle auf einmal ausgeräumt. Verbringe deine Zeit hier, nicht mit einer langen Liste von Vielleichts.
3. Schaue, wo grep aufhört. Lies den Quellcode der Bibliothek, die du aufrufst, und überprüfe ihre festgelegte Version und etwaige lokale Patches. Finde heraus, wann Dinge laufen: Microtasks, Unmount und Teardown, Solid versus React. Folge, was eine Symbolsuche übersieht: das JSON, das eine API zurückgibt, eine DB-Spalte, ein Drahtformat, eine andere Sprache, die dieselben Bytes liest, ein Feature-Flag, Code drei Hops flussabwärts.
4. Sei ehrlich zu jedem Risiko. Gib ihm eine reale Eintrittswahrscheinlichkeit und echte Kosten, falls es eintritt. Behalte die Risiken, die du bestätigt hast. Liste die, die du geprüft und ausgeräumt hast, separat auf. Zitiere eine echte datei:zeile, eine Suche, die nichts findet, ist trotzdem eine Antwort, und erfinde niemals einen Aufrufer oder eine API.
5. Beweise die eine Tatsache. Schreibe ein Skript oder einen Test, der den echten Code ausführt, führe ihn aus und füge ein, was passiert ist. Wenn du es nicht günstig beweisen kannst, markiere es als unbewiesen. Übertreibe nicht.
6. Führe eine große oder breite Änderung durch den obigen Review mit mehreren Modellen aus. Unterschiedliche Modelle erkennen unterschiedliche echte Fehler.

Was zurückzugeben ist

• Was es tut. Was sich geändert hat, einschließlich des Teils, der nicht offensichtlich ist.
• Die eine Tatsache, deretwegen es sicher ist. Gib sie an, sage, auf welchem Schritt du sie gebracht hast, und zeige den Beweis. Wenn du es nicht beweisen konntest, schreibe unbewiesen.
• Risiken. Nur die echten. Jedes nennt, wie es zerbricht, die datei:zeile, wie wahrscheinlich und wie schlimm, und wie zu prüfen. Füge den Beweis für diejenigen ein, die wichtig sind.
• Ausgeräumt. Was du geprüft hast und warum es in Ordnung ist.
• Vor dem Mergen. Der günstigste Test oder Repro, der den echten Fehler fängt, einschließlich des Skripts, das du geschrieben hast.

Schreibe es durch unslop, zitiere echten Code und entferne alles Private, bevor es an einen öffentlichen Ort geht.

Antwort: die obige Beschreibung mit der einen Sicherheitstatsache, entweder bewiesen oder als unbewiesen markiert.