Review Loop

Iterativer Worker-Reviewer-Zyklus innerhalb einer einzigen Sitzung. Du erledigst die Arbeit, startest einen Reviewer-Subagenten, der sie kritisiert, überarbeitest sie basierend auf dem Feedback und wiederholst den Vorgang, bis die Qualitätsschwelle erreicht ist.

Kernprinzip: Erste Entwürfe sind niemals endgültig. Iterative Kritik liefert bessere Ergebnisse als ein einzelner Durchlauf.

Hinweis zur Plattform: Dieses Skill funktioniert am besten mit Agenten, die das Starten von Sub-Agenten unterstützen. Auf Plattformen ohne diese Fähigkeit simulierst du den Reviewer-Schritt, indem du einen neuen Chat-Kontext öffnest, nur das Arbeitsergebnis (ohne vorherige Überlegungen) einfügst und es bittest, mit einer Bewertung von 1-10 und spezifischem Feedback zu bewerten.

Kurzanleitung

Sage: "implementiere X, nutze review-loop" oder "führe review-loop für die gerade geschriebene Datei aus"
Der Agent erledigt die Arbeit (oder liest vorhandene Arbeit)
Ein separater Kritik-Subagent bewertet sie mit 1–10 und gibt spezifisches Feedback
Der Agent überarbeitet und wiederholt, bis die Punktzahl >= 8 ist (Standard-Qualitätsschwelle)
Eine Zusammenfassung der Schleife wird zusammen mit dem endgültigen Ergebnis ausgegeben

Wann verwenden

Benutzer sagt "nutze review-loop", "polier das", "iteriere darüber", "/review-loop"
Komplexe Implementierungen, bei denen Qualität wichtiger ist als Geschwindigkeit
Entwurfsdokumente, Spezifikationen oder technische Texte
Code, der robust sein muss (Sicherheit, Datenpipelines, Finanzlogik)
Wenn der Benutzer eine kontradiktorische Kritik in den Prozess integriert haben möchte

Wann NICHT verwenden

Einfache Korrekturen, schnelle Bearbeitungen, Einzeiler-Änderungen
Aufgaben, bei denen Tests das Qualitätskriterium sind (verwende stattdessen TDD + CI)
Wenn der Benutzer es einfach schnell erledigt haben möchte
Erkundungs-/Spike-Arbeiten, bei denen das Ziel Lernen und nicht Ausliefern ist
Aufgaben ohne klare Annahmekriterien – definiere diese zuerst, dann verwende review-loop

Standardeinstellungen

Einstellung	Standard
Mindestschleifen	2
Maximalschleifen	4
Qualitätsschwelle	8/10
Worker-Modell	(dein aktuelles Modell)
Reviewer-Modell	(dein aktuelles Modell oder schnelle/ausgewogene Alternative)

Modellauswahl

Die Reviewer-Aufgabe bewertet Logik und Randbedingungen. Die Worker-Aufgabe schreibt und ändert Code. Wähle die Subagent-Fähigkeiten entsprechend aus.

KRITISCHE REGEL: Der Reviewer muss immer GLEICH ODER LEISTUNGSFÄHIGER sein als der Worker. Wenn der Reviewer schwächer ist als der Worker, kann er komplexe Logik nicht richtig kritisieren oder subtile Regressionen erkennen.

Aufgabenkomplexität	Worker-Fähigkeit	Reviewer-Fähigkeit	Begründung
Einfach/mechanisch (CRUD, Formatierung, Boilerplate)	Schnell / Leichtgewichtig	Ausgewogen	Leichtgewichtiger Worker ist schnell, ausgewogener Reviewer erkennt Probleme leicht
Standard (Features, Refactorings, Dokumentation)	Ausgewogen	Ausgewogen	Gute Mischung aus Kosten, Geschwindigkeit und Qualität
Komplex (mehrere Dateien, Integration, Design)	Ausgewogen	Fortgeschritten / Reasoning	Fortgeschrittener Reviewer erkennt subtile Architekturprobleme, ausgewogener Worker kann sie umsetzen
Sehr komplex (Sicherheit, Quant, verteilte Systeme)	Fortgeschritten / Reasoning	Fortgeschritten / Reasoning	Beide benötigen vollständigen Kontext und Reasoning-Fähigkeit. Reviewer MUSS die Leistung des Workers erreichen.

Die goldene Regel: Der Worker muss intelligent genug sein, um auf das Feedback des Reviewers zu REAGIEREN. Wenn der Reviewer sagt "Behebe die Race-Condition mit einem kanalbasierten Semaphor" und der Worker kann nicht über Nebenläufigkeit nachdenken, wird die Schleife nicht konvergieren.

Eskalationssignal: Wenn sich die Punktzahl nach 2 aufeinanderfolgenden Schleifen mit demselben Feedback nicht verbessert, ist das Worker-Modell zu schwach. Eskaliere:

Option A: Bitte den Benutzer, auf ein leistungsfähigeres Modell zu wechseln
Option B: Senke die Qualitätsschwelle vorübergehend und weise den Benutzer auf die Lücke hin
Option C: Zerlege die Aufgabe in kleinere Unteraufgaben und führe review-loop für jede aus

Standardverhalten: Da du (der Hauptagent) DER Worker bist, starte einen Reviewer-Subagenten, der deiner aktuellen Fähigkeit entspricht oder sie übertrifft – basierend auf der Aufgabe:

Die meisten Aufgaben → Standard/ausgewogener Reviewer
Spezialisierte/schwierige Aufgaben → Fortgeschrittener/Reasoning-Reviewer
Schnelle Prüfungen → Schneller/leichter Reviewer (nur wenn du auch als leichter Worker agierst)

Benutzerüberschreibungen

Benutzer können jede Standardeinstellung inline mit ihrer Anfrage überschreiben. Parse diese natürlich:

"implementiere X mit review-loop, Qualitätsschwelle 9, verwende fortgeschrittenes Modell für Review, maximal 5 Schleifen"
"polier das, mindestens 2 Schleifen, Schwelle bei 8"
"führe review-loop mit schnellem Reviewer aus, maximal 2 Schleifen"
"nutze review-loop, Reasoning-Reviewer, Qualitätsschwelle 9, mindestens 3 maximal 6"

Parser-Regeln:

"Qualitätsschwelle N" oder "Schwelle N" → quality_gate = N
"[Modell] Reviewer" oder "review mit [Modell]" → Reviewer-Modell-Überschreibung
"maximal N Schleifen" → max_loops = N
"mindestens N Schleifen" → min_loops = N
Wenn der Benutzer nichts angibt, verwende die Standardeinstellungen
Wenn der Benutzer "gründlich" oder "streng" sagt → interpretiere als Qualitätsschwelle 8, min_loops 2
Wenn der Benutzer "schnell" oder "flott" sagt → interpretiere als max_loops 2, Qualitätsschwelle 6

Der Prozess

flowchart TD
    A[Arbeit erledigen] --> B[Reviewer-Subagent starten]
    B --> C{Mindestschleifen erreicht?}
    C -- nein, immer fortfahren --> E[Auf Basis des Feedbacks überarbeiten]
    C -- ja --> D{Punktzahl >= Qualitätsschwelle?}
    D -- ja --> F[Letzter Feinschliff]
    D -- nein --> G{Maximalschleifen erreicht?}
    G -- ja, trotzdem anhalten --> F
    G -- nein --> E
    E --> B
    F --> H([Fertig])

Schritt-für-Schritt

Schritt 1: Arbeit erledigen

Erledige die Aufgabe wie gewohnt. Schreibe den Code, erstelle die Spezifikation, implementiere das Feature. Halte dich nicht zurück – liefere deinen besten ersten Versuch.

Schritt 2: Reviewer-Subagent starten

Verwende das Agent-Tool, um einen Reviewer zu beauftragen. Der Reviewer muss:

Ein separater Subagent sein (frischer Kontext, keine Verankerung an deine Überlegungen)
Nur das Arbeitsergebnis erhalten (Dateien, Diffs) – nicht deinen Gedankengang
Mit 1–10 bewerten mit spezifischem, umsetzbarem Feedback
Standardmäßig ein ausgewogenes/Standard-Modell verwenden (oder ein fortgeschrittenes Reasoning-Modell für komplexe/spezialisierte Aufgaben)

Vorlage für den Reviewer-Prompt:

Du bist ein kritischer Reviewer. Bewerte die folgende Arbeit mit 1–10 und gib spezifisches, umsetzbares Feedback.

## Was gemacht wurde
{kurze Beschreibung der Aufgabe}

## Bewertungskriterien
{aufgabenspezifische Kriterien – was für DIESE Aufgabe wichtig ist}

Beispiele für gut formulierte Kriterien:
  Für einen REST-API-Endpoint:
    - Korrekte HTTP-Statuscodes verwendet
    - Eingabevalidierung für alle Parameter vorhanden
    - Authentifizierung erzwungen; kein unauthentifizierter Zugriff
    - Keine N+1-Abfragemuster

  Für ein Entwurfsdokument:
    - Problemstellung ist eindeutig
    - Alternativen mit Abwägungen betrachtet
    - Keine vagen Aussagen zur Implementierungskomplexität
    - Erfolgsmetriken sind messbar

  Für eine Datenpipeline:
    - Idempotent – sicher erneut ausführbar
    - Schema-Änderungen werden elegant behandelt
    - Fehlermodi dokumentiert
    - PII-Handling adressiert

## Anweisungen
1. Lies die Arbeit sorgfältig
2. Bewerte mit 1–10, wobei:
   - 1-3: Grundlegend fehlerhaft oder wichtige Anforderungen fehlen
   - 4-6: Funktioniert, hat aber erhebliche Mängel
   - 7-8: Gut, nur kleinere Probleme
   - 9-10: Hervorragend, versandbereit
3. Liste spezifische Probleme mit Datei:Zeile-Referenzen auf, wo zutreffend
4. Erkläre bei jedem Problem, WARUM es wichtig ist und WAS zu beheben ist
5. Sei nicht höflich – sei ehrlich und direkt
6. Gib deine Bewertung klar an als "Punktzahl: N/10"

## Zu prüfende Dateien
{füge Dateiinhalt ein oder liste Dateipfade mit relevanten Auszügen auf}

Schritt 3: Feedback parsen

Extrahiere aus der Reviewer-Antwort:

Punktzahl (die Zahl)
Probleme (kategorisiert als Kritisch / Wichtig / Geringfügig)
Spezifische Korrekturen (was zu ändern ist)

Melde dem Benutzer:

Schleife {N}/{max}: Punktzahl {X}/10
- {Zusammenfassung der wichtigsten Feedback-Punkte}

Schritt 4: Stoppbedingungen prüfen

In dieser Reihenfolge:

Wenn Schleifen < min_loops → weitermachen (immer)
Wenn Punktzahl >= Qualitätsschwelle → anhalten, zum letzten Feinschliff
Wenn Schleifen >= max_loops → anhalten, zum letzten Feinschliff
Sonst → überarbeiten und Schleife wiederholen

Schritt 5: Überarbeiten

Adressiere das Feedback des Reviewers. Behebe kritische und wichtige Probleme. Geringfügige Probleme sind optional. Gehe dann zurück zu Schritt 2.

Wichtig: Jede Überarbeitung sollte gezielt sein. Schreibe nicht alles neu – behebe, was der Reviewer beanstandet hat. Behalte eine mentale Liste ALLER vorherigen Rückmeldungen, um Regressionen zu vermeiden.

Schritt 6: Letzter Feinschliff

Sobald die Schleife beendet ist (Qualitätsschwelle erreicht oder max. Schleifenanzahl erreicht):

Behebe verbleibende geringfügige Probleme, wenn sie trivial sind
Überprüfe, ob das endgültige Ergebnis kohärent ist (keine Artefakte aus Überarbeitungszyklen)
Melde dem Benutzer die endgültige Punktzahl und Schleifenanzahl

Anpassung der Reviewer-Kriterien nach Aufgabentyp

Aufgabentyp	Reviewer sollte sich konzentrieren auf
Code	Korrektheit, Randfälle, Fehlerbehandlung, Lesbarkeit, keine Sicherheitsprobleme
Spezifikation/Design	Vollständigkeit, Machbarkeit, keine vagen Aussagen, Umsetzbarkeit
Refactoring	Keine Verhaltensänderungen, keine Regressionen, sauberer als zuvor
Text	Klarheit, Struktur, zielgruppengerecht, kein Füllmaterial
Fehlerbehebung	Ursache behoben, Regressionstest vorhanden, keine Nebenwirkungen
Infrastruktur / IaC	Idempotenz, Least-Privilege, keine hartcodierten Geheimnisse, Löschsicherheit
Datenbankmigration	Rückgängig machbar, Indexstrategie, Datenverlustrisiko, Leistung bei Skalierung
API-Design	Abwärtskompatibilität, Authentifizierung, Versionierung, Fehlervertrag
Testsuite	Randfallabdeckung, keine Testabhängigkeiten, aussagekräftige Assertions

Zwei Betriebsmodi

Modus A: "Erledigen und Überprüfen" (vollständiger Zyklus)

Benutzer gibt eine Aufgabe + sagt, review-loop zu verwenden. Du erledigst die Arbeit UND führst den Review-Zyklus aus.

Benutzer: "Implementiere die Caching-Schicht. Nutze review-loop, Qualitätsschwelle 8."

Du:
1. Implementiere Caching-Schicht
2. Starte Reviewer → Punktzahl 6, Feedback: fehlendes Eviction, kein TTL
3. Überarbeite: Eviction + TTL hinzufügen
4. Starte Reviewer → Punktzahl 8, Feedback: kleiner Namensnörgler
5. Letzter Feinschliff, fertig

Modus B: "Vorhandenes überprüfen" (nur Review)

Benutzer hat bereits gearbeitet oder du hast bereits gearbeitet. Führe einfach den Review-Zyklus für das Vorhandene aus.

Benutzer: "Führe review-loop für das Auth-Modul aus, das ich gerade geschrieben habe"

Du:
1. Lese das Auth-Modul
2. Starte Reviewer → Punktzahl 5, Feedback: SQL-Injection, kein Rate-Limiting
3. Behebe: Parameterisierte Abfragen, Rate-Limiter hinzufügen
4. Starte Reviewer → Punktzahl 8, genehmigt
5. Fertig

Warnsignale

Nie:

Selbst-Review anstelle des Startens eines Subagenten (Verankerungsfehler)
Eine Überarbeitungsrunde überspringen, weil "das Feedback falsch ist", ohne Begründung
Die eigene Punktzahl aufblähen ("Ich denke, das ist eigentlich eine 9")
Über max_loops hinaus fortfahren ohne Zustimmung des Benutzers
Den Reviewer mit deiner vollständigen Überlegung/Historie starten (er muss die ARBEIT prüfen, nicht deine Absicht)

Wenn der Reviewer falsch liegt:

Widerspreche mit Beweisen (zeige Code/Tests, die das Feedback widerlegen)
Überspringe diesen spezifischen Punkt bei der Überarbeitung
Vermerke es in deinem Bericht an den Benutzer
Senke NICHT die Qualitätslatte, um dies auszugleichen

Beispiel-Berichtsformat

--- Review-Loop: {Aufgabenname} ---

Schleife 1/4: Punktzahl 6/10
  Reviewer: Fehlende Eingabevalidierung, keine Fehlerbehandlung für Netzwerk-Timeout,
            Funktion zu lang (80 Zeilen).
  Aktion: Alle drei Probleme beheben.

Schleife 2/4: Punktzahl 8/10
  Reviewer: Sauber. Geringfügig: Variablenname `d` könnte aussagekräftiger sein.
  Aktion: Qualitätsschwelle erreicht (8 >= 8). Letzter Feinschliff.

Ergebnis: 8/10 in 2 Schleifen. Fertig.

Bekannte Einschränkungen

Der Reviewer-Subagent hat kein Gedächtnis an vorherige Schleifen – füge den Kontext des vorherigen Feedbacks explizit in jeden Reviewer-Prompt ein, um die Wiederholung gelöster Probleme zu vermeiden
Eine Aufblähung der Punktzahl ist möglich, wenn die Reviewer-Prompt-Kriterien zu vage sind – investiere Zeit in das Formulieren spezifischer, messbarer Kriterien
Dieses Skill ersetzt keine menschliche Code-Überprüfung für sicherheitskritischen oder compliance-relevanten Code; betrachte das Ergebnis als starken ersten Durchlauf
Die Konvergenz der Schleife ist nicht garantiert, wenn die Aufgabe zu vage definiert ist – definiere klare Annahmekriterien vor Beginn

Kosten und Geschwindigkeit

Jede Schleife = 1 Reviewer-Subagent-Aufruf
Für einen vollständigen 3-Schleifen-Zyklus solltest du etwa das 1- bis 2-fache der Zeit eines einzelnen Implementierungsdurchlaufs einplanen
Das ist günstig im Vergleich zum Ausliefern fehlerhaften Codes, vager Spezifikationen oder dem Auslösen einer späten Review-Runde
Verwende dein Standard-/Standardmodell für die meisten Reviews; upgrade nur auf fortgeschrittene Reasoning-Modelle für spezialisierte Bereiche (Sicherheitsaudits, verteilte Systeme, Quantenfinanz)

Lizenz

MIT – kostenlos nutzbar, anpassbar und mit jedem KI-Tool oder jeder KI-Plattform weiterverteilbar. Namensnennung geschätzt. Beiträge sind willkommen.

2dmurali/review-loop

Was ist review-loop?

In Ihrer bevorzugten KI fragen

Dokumentation