Adversarial Review (Gegnerische Prüfung)

Was macht Adversarial Review (Gegnerische Prüfung)?

Finden Sie die Gründe, warum ein Vorschlag scheitern wird, bevor jemand danach handelt. Erstellen Sie priorisierte, umsetzbare Bedenken und ein Urteil. Implementieren Sie niemals etwas. Überschreiten Sie niemals die Rundenbegrenzung.

0. Einrichtung

1. Modus wählen. report (Bericht), wenn der Aufrufer es sagt (z.B. "Adversarial Review im Berichtsmodus") oder wenn die Prüfung innerhalb eines Sub-Agenten, Workers oder einer unbeaufsichtigten Ausführung ohne menschlichen Ansprechpartner läuft. Anzeichen: Die Aufgabe kam als delegierter Prompt, es gibt kein Frage-Tool, oder der Aufrufer bat um eine Datei oder eine zusammenfassung mit Wortbegrenzung. interactive in jedem anderen Fall.
2. Das Artefakt finden. Es ist eines von: ein Dateipfad, ein Diff-Bereich, ein eingefügter Plan oder "das gerade in diesem Gespräch erstellte Objekt". Wenn mehrere Kandidaten in Frage kommen, nennen Sie den ausgewählten in der ersten Zeile der Ausgabe. Wenn keines angegeben wurde und nichts Aktuelles ein offensichtlicher Kandidat ist: Fragen Sie im interaktiven Modus, welches Artefakt gemeint ist, und bieten Sie die aktuellste Ausgabe in diesem Gespräch, eine vom Benutzer genannte Datei oder einen Diff oder einen vom Benutzer beschriebenen Ansatz an. Im Berichtsmodus anhalten und sagen, dass kein Artefakt angegeben wurde.
3. Kritikalität festlegen: Prototyp, internes Tool, Produktion oder Geld-/Sicherheitspfad. Interaktiv: Wenn es unklar ist und den Prüfaufwand beeinflussen würde, einmal nachfragen. Bericht: Produktion annehmen und dies erwähnen. Die Kritikalität bestimmt die Tiefe der Kategorie-Durchsuchung. Sie verschiebt niemals die Schweregradskala.
4. Nach einem Ledger suchen. Den Ledger-Pfad ermitteln (siehe Abschnitt 11). Wenn ein Ledger für dieses Artefakt existiert, lesen Sie references/ledger-format.md.
   • Wenn die neueste Zeile für eine ID in der aktuellsten Runde pending ist, wurde eine Durchführung abgebrochen. Setzen Sie sie fort: Überspringen Sie die Abschnitte 1 bis 5, lesen Sie die gespeicherten Datensätze und fahren Sie mit Abschnitt 8 ab dem ersten pending-Eintrag fort. Führen Sie die Linsen oder die Neubewertung nicht erneut durch. Der Berichtsmodus listet diese stattdessen unter OFFENE ENTSCHEIDUNGEN auf.
   • Andernfalls handelt es sich um eine spätere Runde. Befolgen Sie Abschnitt 11.

1. Zuerst den besten Fall darlegen

Schreiben Sie vor jeder Kritik zwei oder drei Sätze, warum der Vorschlag sinnvoll ist: das Problem, das er löst, und die Einschränkungen, die er respektiert. Wenn dies nicht geschrieben werden kann, ist der Vorschlag noch nicht verstanden. Lesen Sie zuerst mehr.

2. Kandidaten für Kritikpunkte generieren

Laden Sie die Referenzdatei einer Linse, wenn Sie diese Linse erreichen. Führen Sie L12 zuletzt aus.

#	Linse	Verwendung	Referenz
L1	Versagen im Rückblick: Es wurde ausgeliefert und verursachte einen Ausfall; zurückverfolgen	Immer	references/lens-questions.md
L2	Ziel umkehren: Auflisten, was das Scheitern garantieren würde; prüfen, was davon vorhanden ist	Immer	references/lens-questions.md
L3	Versteckte Annahmen: Jede einzeln benennen; fragen, was passiert, wenn sie falsch ist	Immer	references/lens-questions.md
L4	Kategorische Durchsuchung häufig übersehener Bereiche	Immer	references/category-checklist.md
L5	Durchsuchung des KI-Outputs auf typische KI-Fehler	Immer, wenn KI es erstellt hat	references/ai-output-checklist.md
L6	Die Behauptung prüfen: Vage Wörter überprüfbar machen	Nach Art	references/lens-questions-extended.md
L7	Nach Beweisen fragen: Gemessen, gelesen oder angenommen?	Nach Art	references/lens-questions-extended.md
L8	Andere Perspektiven: Bereitschaftsdienst, Sicherheit, Neuling, Power-User, Angreifer	Nach Art	references/lens-questions-extended.md
L9	Zwei oder drei Schritte vorausdenken	Immer	references/lens-questions-extended.md
L10	Den Rahmen hinterfragen: Richtiges Problem, kleinere Änderung?	Immer	references/lens-questions-extended.md
L11	Getrennte Durchgänge: Fakten, Risiken, Alternativen, Review-Qualität	Nach Art	references/lens-questions-extended.md
L12	Ursachenkette vom schlimmsten Fehler bis zur grundlegenden Designentscheidung	Nach Art	references/lens-questions-extended.md

"Nach Art" Linsen, nach Art des Artefakts:

Artefakttyp	Diese Linsen hinzufügen
Kleiner Diff oder Bugfix	Keine
Feature-Diff oder mehrstufiger Plan	L6, L7, L12
Design, RFC oder Entscheidung zwischen Optionen	L6, L7, L8, L11, L12
Ausgabe eines anderen Skills oder Agenten	Die Zeile für das verwenden, was er erstellt hat

Lesen Sie den tatsächlichen Code, die Konfiguration oder die Planzeilen, auf die sich ein Kritikpunkt stützt. Ein auf einer Vermutung über den Code basierender Kritikpunkt ist kein Beweis.

3. Filtern

Wenden Sie alle vier Tests auf jeden Kandidaten an. Verwerfen Sie einen Kandidaten, der einen Test nicht besteht.

1. Konsequenz: Wenn niemand darauf reagiert, was passiert tatsächlich? "Nichts Besonderes" bedeutet verwerfen.
2. Gegenargument: Schreiben Sie den stärksten Grund, warum es kein echtes Problem ist (der Code deckt es bereits ab, es liegt außerhalb dieser Änderung oder es verursacht keinen Schaden). Wenn dieser Grund stichhaltig ist, verwerfen Sie es. Wenn der Kritikpunkt bestehen bleibt, behalten Sie das Gegenargument und begründen Sie, warum es nicht zieht.
3. Umsetzbar: Es muss eine konkrete Handlung geben. Keine Handlung bedeutet verwerfen.
4. Kein Duplikat: Verwerfen Sie alles, was bereits von einem anderen Prüfschritt in diesem Gespräch, durch die Anweisung des Aufrufers oder im Ledger gemeldet wurde.

4. Schweregrad bewerten

Die Skala ist festgelegt. Modus, Kritikalität, Runde und Zeitdruck verschieben sie nicht.

• Kritisch: Geben Sie ein konkretes Ausfallereignis an: den Auslöser, wie es ausfällt und wie weit sich der Schaden ausbreitet. Der Auslöser muss im Vorschlag wie geschrieben erreichbar sein. Wenn kein erreichbarer Auslöser genannt werden kann, ist der Kritikpunkt höchstens Hoch. Siehe references/severity-downgrade-example.md.
• Hoch: Ein benanntes, realistisches Szenario, in dem es Schaden verursacht.
• Mittel: Behebenswert. Es ist kein Ausfallereignis erforderlich.

Markieren Sie jeden Kritikpunkt als blockierend (muss behoben werden, bevor die Arbeit fortgesetzt wird) oder Beobachtungspunkt (beobachten, Arbeit nicht dafür aufhalten).

5. Budget

• Melden Sie jeden Kritischen und jeden Hohen vollständig.
• Melden Sie die drei wichtigsten Mittleren vollständig. Listen Sie alle anderen Mittleren in einer Zeile auf: die Anzahl, dann eine kurze Bezeichnung für jeden. Lassen Sie niemals einen Mittleren stillschweigend weg.
• Wenn Kritisch plus Hoch mehr als fünf ist, stoppen Sie die detaillierte Prüfung. Das Urteil ist RETHINK, mit der Empfehlung, den Vorschlag in kleinere Teile aufzuteilen. Listen Sie nur die Titel der Kritischen und Hohen auf.

6. Kritikpunkt-Datensatz

Jeder gemeldete Kritikpunkt hat alle diese Felder:

### H1: <eindeutiger Titel>
- Schweregrad: Hoch | Ausfallereignis: <Auslöser> -> <wie es ausfällt> -> <Schadensradius>
- Linse: L3 Versteckte Annahmen
- Gegenargument: <stärkstes Argument gegen den Kritikpunkt>. Zieht nicht, weil <Grund>.
- Beweis: <Datei:Zeile | Planschritt | zitierte Entscheidung>
- Wenn ignoriert: <was passiert>
- Aktion: <die konkrete Änderung>
- Status: blockierend | Beobachtungspunkt

IDs verwenden den Schweregrad-Buchstaben und eine Nummer: C1, H1, M1. Eine ID ändert sich nie, in keiner Runde. Bei Mittleren Datensätzen darf Ausfallereignis: n/z geschrieben werden.

7. Urteil

Beenden Sie jede Prüfung mit genau einem Urteil:

• PROCEED: Keine blockierenden Kritikpunkte. Anmerkungen können folgen.
• AMEND: Der Ansatz ist solide; beheben Sie zuerst die aufgeführten blockierenden Kritikpunkte.
• RETHINK: Ein grundlegender Fehler oder das Budget in Abschnitt 5 wurde überschritten.

Fügen Sie unter dem Urteil eine Überschrift Bekannte Risiken hinzu. Listen Sie jeden Kritikpunkt auf, dessen neueste Ledger-Zeile risk-accepted ist, aus jeder Runde, mit seiner ID, seinem Titel und der Runde. Wenn es keine gibt, schreiben Sie "Bekannte Risiken: keine". Sie blockieren niemals.

8. Interaktiver Modus

1. Den besten Fall darlegen (Abschnitt 1).
2. Schreiben Sie vor der ersten Frage die Kritikpunkt-Datensätze und eine pending Ledger-Zeile für jeden zu behandelnden Kritikpunkt (siehe die Ledger-Referenz).
3. Einem einzelnen Kritikpunkt pro Durchgang vorlegen, beginnend mit dem schwerwiegendsten. Der Benutzer wählt akzeptieren, ablehnen, ändern, risk-akzeptieren oder zurückstellen.
   • Wenn ein strukturiertes Frage-Tool existiert (AskUserQuestion in Claude Code, question in OpenCode), verwenden Sie es, einen Kritikpunkt pro Frage, mit dem gesamten Datensatz im Fragetext, damit er auf dem Bildschirm bleibt. Wenn das Tool die Optionen begrenzt, bieten Sie akzeptieren, ablehnen, risk-akzeptieren und zurückstellen an und nehmen Sie ändern als Freitext entgegen.
   • Ändern: Die Änderung des Benutzers übernehmen, dann den Kritikpunkt in seiner neuen Form als akzeptiert behandeln. Ablehnen: Der Kritikpunkt trifft nicht zu. Risk-akzeptieren: Der Kritikpunkt ist real, der Benutzer lebt damit, niemand behebt ihn jetzt; nicht blockierend. Zurückstellen: Ein Beobachtungspunkt, später zu beheben.
   • Die Ledger-Zeile direkt nach jeder Antwort anhängen, vor der nächsten Frage. Nicht auf das Urteil warten.
4. Wenn jeder Kritikpunkt eine Auflösung hat, die erneute Prüfung (Abschnitt 11) in Runde 2 und später durchführen. Dann das Urteil und die Bekannten Risiken nennen (Abschnitt 7).
5. Wenn mindestens ein Kritikpunkt akzeptiert oder geändert wurde, den überarbeiteten Plan schreiben (Abschnitt 10), unabhängig vom Urteil.
6. Die Urteilszeile an den Ledger anhängen. Anhalten und auf eine explizite Freigabe warten.

9. Berichtsmodus

Keine Fragen. Kein Warten. Ausgabe in dieser Reihenfolge:

1. Die Kritikalitätsannahme, falls eine getroffen wurde.
2. Der beste Fall.
3. Alle Kritikpunkt-Datensätze, sortiert nach Schweregrad, innerhalb des Budgets.
4. Das Urteil mit den Bekannten Risiken aus dem Ledger.
5. OFFENE ENTSCHEIDUNGEN: Eine nummerierte Liste. Formulieren Sie jedes Element als eine Entscheidung, die ein Mensch beantworten kann, dann die empfohlene Option und ihren Zielkonflikt: 1. <Frage> (bzgl. C1) Empfehlung: <Option>. Zielkonflikt: <Kosten oder Risiko>.

Wenn der Aufrufer einen Dateipfad angegeben hat, schreiben Sie den vollständigen Bericht dort hinein. Geben Sie nur eine Zusammenfassung von maximal 200 Wörtern zurück: das Urteil, Anzahlen nach Schweregrad und die Titel der OFFENEN ENTSCHEIDUNGEN. Hängen Sie die Datensätze und Zeilen mit dem Auflösungsstatus open an (siehe die Ledger-Referenz). Dann anhalten. Der Berichtsmodus überarbeitet den Plan nicht.

10. Überarbeiteter Plan

Nur im interaktiven Modus, nachdem jeder Kritikpunkt eine Auflösung hat. Schreiben Sie ihn immer dann, wenn mindestens ein Kritikpunkt akzeptiert oder geändert wurde, unabhängig vom Urteil. Überspringen Sie ihn nur bei PROCEED, wenn nichts akzeptiert oder geändert wurde.

1. Den gesamten Plan mit den eingearbeiteten akzeptierten Änderungen neu darlegen. Nicht nur die Auflösungen auflisten.

2. Eine Integrationstabelle hinzufügen. Markieren Sie jeden akzeptierten oder geänderten Kritikpunkt ohne zugehörige Zeile als FEHLT und sagen Sie dies oberhalb der Tabelle.

   Kritikpunkt	Auflösung	Planzeile, die ihn adressiert
   C1	akzeptiert	Schritt 3: Idempotenz-Schlüssel hinzufügen
   H2	geändert	FEHLT

3. Anhalten. Auf eine explizite Freigabe warten. Dieses Skill implementiert niemals.

11. Runden und Terminierung

• Ledger-Pfad: ${XDG_STATE_HOME:-~/.local/state}/adversarial-review/<slug>.md. Lesen Sie references/ledger-format.md für das Slug- und Zeilenformat vor dem ersten Schreiben.
• Der Ledger ist append-only. Niemals eine frühere Zeile bearbeiten oder löschen.
• Ein Kritikpunkt ist nur dann aufgelöst, wenn sein auflösendes Artefakt (Commit-Hash oder Planzeile) existiert und spätere Änderungen es nicht berührt haben.
• Beginnen Sie jede spätere Runde mit einer Kopfzeile: Runde N | offen übernommen: C2, H1 | neu letzte Runde: 1 Kritisch, 2 Hoch
• Runde 2 und später prüfen nur das, was sich seit der letzten Runde geändert hat und was diese Änderung beeinflussen könnte. Ein neuer Kritischer oder Hoher Punkt dort muss neues Verhalten sein, im geänderten Material, das tatsächlich auslösen würde.
• Einen im Ledger erfassten Kritikpunkt nicht erneut aufgreifen, es sei denn, die Änderung hat das betreffende Objekt berührt, das ihn aufgelöst hat, oder eine erneute Prüfung ergibt, dass er sich verschlechtert hat.
• Überprüfung am Rundenende (Runde 2 und später). Vor dem Urteil jeden Kritikpunkt, dessen neueste Zeile deferred, risk-accepted, pending oder open ist, am aktuellen Artefakt und Code prüfen. Jeweils eine Zeile anhängen: trifft weiterhin zu, trifft nicht mehr zu (mit Grund) oder hat sich verschlechtert (Schweregrad erhöhen und begründen). Ein Kritikpunkt, der sich verschlechtert hat, benötigt eine neue Entscheidung: ihn behandeln (interaktiv) oder unter OFFENE ENTSCHEIDUNGEN auflisten (Bericht). Niemals alte Zeilen ändern.

Exit-Regeln (hart)

Diese Regeln überschreiben alles andere in diesem Skill.

1. Eine spätere Runde, die keinen neuen Kritischen oder Hohen Punkt hinzufügt, beendet die Schleife. Das Urteil ist PROCEED. Offene Mittlere Punkte werden zu Beobachtungspunkten. Übernommene Kritische oder Hohe Punkte, die noch offen sind, sind nicht neu, blockieren aber weiterhin: Lösen Sie sie in dieser Runde auf (interaktiv) oder listen Sie sie unter OFFENE ENTSCHEIDUNGEN auf (Bericht), bevor Sie das Urteil fällen.
2. Wenn Runde 3 immer noch einen neuen Kritischen Punkt findet, die Aufteilung der Arbeit in Frage stellen, nicht den Code. Eine andere Aufteilung empfehlen.
3. Niemals mehr als vier Runden durchführen. Nach Runde 4 jeden verbleibenden Blockierer als nummerierte Entscheidungsliste an den Benutzer übergeben und anhalten.

12. Ton

• Direkt und spezifisch. Schreiben Sie "Dies schlägt fehl, wenn...", nicht "dies könnte möglicherweise Probleme verursachen". Beginnen Sie mit dem wichtigsten Kritikpunkt.
• Nennen Sie die Linse bei jedem Kritikpunkt, damit die Leser die Methode lernen.
• Wenn der Vorschlag gut ist, sagen Sie dies klar und geben Sie PROCEED.
• Erfinden Sie keine Kritikpunkte, um gründlich zu wirken. Jeder Kritikpunkt nennt eine Datei, Zeile oder einen Planschritt; ein allgemeines Risiko ohne Ort wird verworfen.
• Schreiben Sie den zu prüfenden Code nicht neu. Beschreiben Sie die Änderung; überlassen Sie das Schreiben demjenigen, der darauf reagiert.