SamuelChien/mega-skills-collection

Adversarischer Code-Reviewer

Beschreibung

Adversarische Code-Review-Fähigkeit, die echte Perspektivwechsel durch drei feindselige Prüfer-Personas (Saboteur, New Hire, Security Auditor) erzwingt. Jede Persona MUSS mindestens ein Problem finden – kein „LGTM“ kommt durch. Die Ergebnisse werden nach Schweregrad klassifiziert und bei Erkennung durch mehrere Personas hochgestuft.

Funktionen

• Drei adversarische Personas — Saboteur (Produktionsausfälle), New Hire (Wartbarkeit), Security Auditor (OWASP-informiert)
• Verpflichtende Ergebnisse — Jede Persona muss mindestens ein Problem aufdecken, wodurch Gummistempel-Reviews eliminiert werden
• Schweregrad-Hochstufung — Probleme, die von 2+ Personas erkannt werden, werden um eine Schweregradstufe erhöht
• Selbstüberprüfungs-Fallenbrecher — Konkrete Techniken zur Überwindung gemeinsamer mentaler Modell-Bindstellen
• Strukturierte Bewertungen — BLOCK / CONCERNS / CLEAN mit klaren Merge-Anleitungen

Verwendung

/adversarial-review              # Staged/unstaged Änderungen überprüfen
/adversarial-review --diff HEAD~3  # Letzte 3 Commits überprüfen
/adversarial-review --file src/auth.ts  # Bestimmte Datei überprüfen

Beispiele

Beispiel: Überprüfung eines PRs vor dem Zusammenführen

/adversarial-review --diff main...HEAD

Erzeugt einen strukturierten Bericht mit Ergebnissen aller drei Personas, dedupliziert und nach Schweregrad sortiert, endend mit einer BLOCK/CONCERNS/CLEAN-Bewertung.

Problem, das dies löst

Wenn Claude Code überprüft, den es selbst geschrieben (oder gerade gelesen) hat, teilt es dasselbe mentale Modell, dieselben Annahmen und blinden Flecken wie der Autor. Dies führt zu „Sieht gut aus“-Reviews für Code, den ein frischer menschlicher Prüfer sofort beanstanden würde. Benutzer berichten dies als eine der größten Frustrationen bei KI-gestützter Entwicklung.

Diese Fähigkeit erzwingt einen echten Perspektivwechsel, indem sie die Annahme feindseliger Personas erfordert – jede mit unterschiedlichen Prioritäten, unterschiedlichen Ängsten und unterschiedlichen Definitionen von „schlechtem Code“.

Inhaltsverzeichnis

1. Schnellstart
2. Review-Workflow
3. Die drei Personas
4. Schweregrad-Klassifikation
5. Ausgabeformat
6. Anti-Patterns
7. Wann dies zu verwenden ist

Schnellstart

/adversarial-review              # Staged/unstaged Änderungen überprüfen
/adversarial-review --diff HEAD~3  # Letzte 3 Commits überprüfen
/adversarial-review --file src/auth.ts  # Bestimmte Datei überprüfen

Review-Workflow

Schritt 1: Änderungen sammeln

Bestimmen Sie, was basierend auf dem Aufruf überprüft werden soll:

• Keine Argumente: Führen Sie git diff (unstaged) + git diff --cached (staged) aus. Wenn beide leer sind, führen Sie git diff HEAD~1 (letzter Commit) aus.
• --diff <ref>: Führen Sie git diff <ref> aus.
• --file <path>: Lesen Sie die gesamte Datei. Konzentrieren Sie die Überprüfung auf die gesamte Datei, nicht nur auf Änderungen.

Wenn keine Änderungen gefunden werden, stoppen und melden: „Nichts zu überprüfen.“

Schritt 2: Vollständigen Kontext lesen

Für jede Datei im Diff:

1. Lesen Sie die gesamte Datei (nicht nur die geänderten Zeilen) – Fehler verstecken sich in der Interaktion von neuem Code mit vorhandenem Code.
2. Identifizieren Sie den Zweck der Änderung: Fehlerbehebung, neues Feature, Refactoring, Konfigurationsänderung, Test.
3. Notieren Sie alle Projektkonventionen aus CLAUDE.md, .editorconfig, Linting-Konfigurationen oder vorhandenen Mustern.

Schritt 3: Alle drei Personas ausführen

Führen Sie jede Persona nacheinander aus. Jede Persona MUSS mindestens einen Befund liefern. Wenn eine Persona nichts Falsches findet, hat sie nicht gründlich genug gesucht – gehen Sie zurück und suchen Sie erneut.

WICHTIG: Weichen Sie Befunde nicht auf. Drücken Sie sich nicht vage aus. Sagen Sie nicht „das könnte in Ordnung sein, aber...“ – entweder es ist ein Problem oder nicht. Seien Sie direkt.

Schritt 4: Deduplizieren und Synthetisieren

Nachdem alle drei Personas berichtet haben:

1. Führen Sie doppelte Befunde zusammen (gleiches Problem, von mehreren Personas erkannt).
2. Stufen Sie Befunde, die von 2+ Personas erkannt wurden, auf die nächste Schweregradstufe hoch.
3. Erzeugen Sie die endgültige strukturierte Ausgabe.

Die drei Personas

Persona 1: Der Saboteur

Denkweise: „Ich versuche, diesen Code in der Produktion zu brechen.“

Prioritäten:

• Eingaben, die nie validiert wurden
• Zustand, der inkonsistent werden kann
• Gleichzeitiger Zugriff ohne Synchronisation
• Fehlerpfade, die Ausnahmen verschlucken oder irreführende Ergebnisse zurückgeben
• Annahmen über Datenformat, -größe oder -verfügbarkeit, die verletzt werden könnten
• Off-by-one-Fehler, Ganzzahlüberlauf, Null/Undefined-Dereferenzierungen
• Ressourcenlecks (Dateihandles, Verbindungen, Abonnements, Listener)

Review-Prozess:

1. Fragen Sie bei jeder geänderten Funktion/Methode: „Was ist die schlimmste Eingabe, die ich senden könnte?“
2. Fragen Sie bei jedem externen Aufruf: „Was, wenn dies fehlschlägt, zeitüberschreitet oder Müll zurückgibt?“
3. Fragen Sie bei jeder Zustandsänderung: „Was, wenn dies zweimal ausgeführt wird? Gleichzeitig? Nie?“
4. Fragen Sie bei jeder Bedingung: „Was, wenn kein Zweig korrekt ist?“

Sie MÜSSEN mindestens ein Problem finden. Wenn der Code wirklich unverwundbar ist, nennen Sie die zerbrechlichste Annahme, auf die er sich stützt.

---

Persona 2: Der New Hire

Denkweise: „Ich bin gerade zu diesem Team gestoßen. Ich muss diesen Code in 6 Monaten ohne Kontext des ursprünglichen Autors verstehen und ändern.“

Prioritäten:

• Namen, die keine Absicht vermitteln (was bedeutet data? Was macht process()?)
• Logik, die das Lesen von 3+ anderen Dateien erfordert, um sie zu verstehen
• Magische Zahlen, magische Strings, unerklärte Konstanten
• Funktionen, die mehr als eine Sache tun (der Name sagt X, aber sie tut auch Y und Z)
• Fehlende Typinformationen, die den Leser zwingen, Aufrufketten zu verfolgen
• Inkonsistenz mit umgebendem Codestil oder Projektkonventionen
• Tests, die Implementierungsdetails statt Verhalten testen
• Kommentare, die was beschreiben (redundant) statt warum (nützlich)

Review-Prozess:

1. Lesen Sie jede geänderte Funktion, als ob Sie die Codebasis noch nie gesehen hätten. Können Sie aus dem Namen, den Parametern und dem Rumpf allein verstehen, was sie tut?
2. Verfolgen Sie einen Codepfad von Anfang bis Ende. Wie viele Dateien müssen Sie öffnen?
3. Prüfen Sie: Wüsste ein neuer Mitarbeiter, wo er eine ähnliche Funktion hinzufügen könnte?
4. Suchen Sie nach „der Autor wusste etwas, das der Leser nicht wissen wird“ – implizites Wissen, das in den Code eingebacken ist.

Sie MÜSSEN mindestens ein Problem finden. Wenn der Code glasklar ist, nennen Sie den wahrscheinlichsten Punkt der Verwirrung für einen Neuling.

---

Persona 3: Der Security Auditor

Denkweise: „Dieser Code wird angegriffen. Meine Aufgabe ist es, die Schwachstelle zu finden, bevor ein Angreifer es tut.“

OWASP-informierte Checkliste:

Kategorie	Worauf zu achten ist
Injection	SQL, NoSQL, OS-Befehl, LDAP – jede Stelle, an der Benutzereingabe eine Abfrage oder einen Befehl ohne Parametrisierung erreicht
Kaputte Authentifizierung	Hartcodierte Anmeldeinformationen, fehlende Authentifizierungsprüfungen bei neuen Endpunkten, Sitzungstokens in URLs oder Logs
Datenexposition	Sensible Daten in Fehlermeldungen, Logs oder API-Antworten; fehlende Verschlüsselung im Ruhezustand oder während der Übertragung
Unsicherere Standardeinstellungen	Debug-Modus aktiviert, zu permissive CORS, Wildcard-Berechtigungen, Standardpasswörter
Fehlende Zugriffskontrolle	IDOR (kann Benutzer A auf Daten von Benutzer B zugreifen?), fehlende Rollenprüfungen, Privilegieneskalationspfade
Abhängigkeitsrisiko	Neue Abhängigkeiten mit bekannten CVEs, auf anfällige Versionen festgelegt, unnötige transitive Abhängigkeiten
Geheimnisse	API-Schlüssel, Tokens, Passwörter im Code, in der Konfiguration oder in Kommentaren – selbst „vorübergehende“

Review-Prozess:

1. Identifizieren Sie jede Vertrauensgrenze, die der Code überschreitet (Benutzereingabe, API-Aufrufe, Datenbank, Dateisystem, Umgebungsvariablen).
2. Für jede Grenze: Ist die Eingabe validiert? Ist die Ausgabe bereinigt? Wird das Prinzip der geringsten Privilegien befolgt?
3. Prüfen Sie: Könnte ein authentifizierter Benutzer durch diese Änderung Privilegien eskalieren?
4. Prüfen Sie: Schafft diese Änderung eine neue Angriffsfläche?

Sie MÜSSEN mindestens ein Problem finden. Wenn der Code keine Sicherheitsfläche hat, nennen Sie die nächste sicherheitsrelevante Annahme.

Schweregrad-Klassifikation

Schweregrad	Definition	Erforderliche Aktion
KRITISCH	Führt zu Datenverlust, Sicherheitsverletzung oder Produktionsausfall. Muss vor dem Merge behoben werden.	Merge blockieren.
WARNUNG	Verursacht wahrscheinlich Fehler in Randfällen, verschlechtert die Leistung oder verwirrt zukünftige Wartungsentwickler. Sollte vor dem Merge behoben werden.	Beheben oder Risiko explizit mit Begründung akzeptieren.
HINWEIS	Stilproblem, geringfügige Verbesserungsmöglichkeit oder Dokumentationslücke. Schön zu beheben.	Ermessen des Autors.

Hochstufungsregel: Ein Befund, der von 2+ Personas markiert wurde, wird um eine Stufe hochgestuft (HINWEIS wird zu WARNUNG, WARNUNG wird zu KRITISCH).

Ausgabeformat

Strukturieren Sie Ihre Überprüfung wie folgt:

## Adversarische Überprüfung: [kurze Beschreibung des Überprüften]

**Umfang:** [überprüfte Dateien, geänderte Zeilen, Art der Änderung]
**Bewertung:** BLOCK / CONCERNS / CLEAN

### Kritische Befunde
[Falls vorhanden – diese blockieren den Merge]

### Warnungen
[Sollte behoben werden]

### Hinweise
[Schön zu beheben]

### Zusammenfassung
[2-3 Sätze: Wie ist das Gesamtrisikoprofil? Was ist das Wichtigste, das behoben werden muss?]

Bewertungsdefinitionen:

• BLOCK — 1+ KRITISCHE Befunde. Nicht zusammenführen, bis behoben.
• CONCERNS — Keine kritischen, aber 2+ Warnungen. Auf eigenes Risiko zusammenführen.
• CLEAN — Nur Hinweise. Sicheres Zusammenführen.

Anti-Patterns

Was diese Fähigkeit NICHT ist

Anti-Pattern	Warum es falsch ist
„LGTM, keine Probleme gefunden“	Wenn Sie nichts gefunden haben, haben Sie nicht gründlich genug gesucht. Jede Änderung hat mindestens ein Risiko, eine Annahme oder eine Verbesserungsmöglichkeit.
Nur kosmetische Befunde	Nur Leerzeichen/Formatierung zu melden, während eine Null-Dereferenzierung übersehen wird, ist schlimmer als gar keine Überprüfung. Substanz zuerst, Stil danach.
Mit Samthandschuhen anfassen	„Dies könnte möglicherweise ein geringes Problem sein...“ – Nein. Seien Sie direkt. „Dies wird eine NullPointerException auslösen, wenn user undefiniert ist.“
Das Diff wiederholen	„Diese Funktion wurde hinzugefügt, um die Authentifizierung zu handhaben“ ist kein Befund. Was ist FALSCH daran, wie sie die Authentifizierung handhabt?
Testlücken ignorieren	Neuer Code ohne Tests ist ein Befund. Immer. Tests sind nicht optional.
Nur die geänderten Zeilen überprüfen	Fehler leben in der Interaktion zwischen neuem und vorhandenem Code. Lesen Sie die gesamte Datei.

Die Selbstüberprüfungs-Falle

Sie überprüfen wahrscheinlich Code, den Sie gerade geschrieben oder gerade gelesen haben. Ihr Gehirn (Gewichte) hat dasselbe mentale Modell gebildet, das diesen Code erzeugt hat. Sie werden natürlich denken, dass er korrekt aussieht, weil er Ihren Erwartungen entspricht.

Um dieses Muster zu durchbrechen:

1. Lesen Sie den Code von unten nach oben (beginnen Sie mit der letzten Funktion, arbeiten Sie rückwärts).
2. Geben Sie für jede Funktion ihren Vertrag vor dem Lesen des Rumpfs an. Stimmt der Rumpf damit überein?
3. Nehmen Sie an, dass jede Variable null/undefiniert sein könnte, bis das Gegenteil bewiesen ist.
4. Nehmen Sie an, dass jeder externe Aufruf fehlschlagen wird.
5. Fragen Sie: „Wenn ich diese Änderung vollständig löschen würde, was würde dann kaputtgehen?“ – wenn die Antwort „nichts“ ist, ist die Änderung möglicherweise unnötig.

Wann dies zu verwenden ist

• Vor dem Zusammenführen eines PRs – insbesondere bei selbst verfassten PRs ohne menschlichen Prüfer
• Nach einer langen Coding-Session – Müdigkeit erzeugt blinde Flecken; diese Fähigkeit gleicht aus
• Wenn Claude „sieht gut aus“ gesagt hat – wenn Sie eine einfache Zustimmung erhalten haben, führen Sie dies für eine zweite Meinung aus
• Bei sicherheitsrelevantem Code – Authentifizierung, Zahlungen, Datenzugriff, API-Endpunkte
• Wenn etwas „sich falsch anfühlt“ – vertrauen Sie diesem Instinkt und führen Sie eine adversarische Überprüfung durch

Querverweise

• Verwandt: engineering-team/senior-security – tiefgehende Sicherheitsanalyse
• Verwandt: engineering-team/code-reviewer – allgemeine Codequalitätsüberprüfung
• Ergänzend: ra-qm-team/ – Qualitätsmanagement-Workflows