PR-Pre-Review-Checkliste aus Diff

Spielt Reviewer für deinen eigenen Diff: sucht Bugs, fehlende Tests, Security-Smells, schlechte Namen, Public-API-Impact — bevor du den PR öffnest.

Zuletzt geprüft 22. April 2026

Prompt

Du bist Senior Reviewer. Ich kippe einen `git diff` rein.
Gib mir VOR dem PR-Open einen ehrlichen Pre-Review.

Strukturiere die Antwort in genau diese Abschnitte. Lasse Abschnitte
KOMPLETT WEG, wenn du nichts Konkretes hast — keine Füll-Sätze.

## Bugs
Konkrete Fehlfunktionen mit Datei:Zeile.

## Fehlende Tests
Was nicht abgedeckt ist und welcher Test-Fall fehlt.

## Security-Smells
Injection, Secrets, Auth-Bypass, unsafe deserialization, etc.
Mit Evidenz aus dem Diff.

## Naming / Lesbarkeit
Namen, die einem späteren Leser Stolpern bereiten, mit Vorschlag.

## Public-API-Impact
Breaking Changes, Signatur-Änderungen, Auswirkungen auf Caller.

## Was schon gut ist
Maximal 2 Punkte. Nur wenn du sie ehrlich nennen kannst.

Diff:
```
<paste here>
```

Wann nutzen

Bevor ein PR an Reviewer geht — eine Runde Selbst-Audit. Spart Reviewer-Runden und fängt offensichtliche Patzer früh. Funktioniert besser, wenn der Diff nicht riesig ist (< ~500 Zeilen).

Use-Cases

Letzter Check vor `git push` auf den PR-Branch.
Solo-Projekt ohne Reviewer — externe Perspektive einholen.
Pair-Programming-Ersatz, wenn niemand sonst gerade Zeit hat.
Onboarding: zeigt Junior-Devs, worauf Senior-Reviewer achten.

Getestet mit

Claude Opus 4.7

Die ausdrückliche Anweisung „Abschnitte komplett weglassen wenn leer” ist der wichtigste Teil — sonst füllen LLMs jedes Heading mit generischer Beratung. Diff einfach unkommentiert reinkippen, das Modell erkennt Sprache und Kontext meist von selbst.