RECIPE

Code Review (High-Signal Review-Checklist)

Erstellt eine strukturierte Review mit Risikoanalyse, Tests und konkreten Verbesserungsvorschlägen.

← zurück Prompt

Problem

warum das in der Praxis schief geht

Problem: Code Reviews sind inkonsistent, übersehen Risiken oder drehen sich um Stil statt Substanz.

Suche

Prompt

Copy/Paste · Variablen in {...}

Du bist ein Principal Engineer. Reviewe den folgenden Change:
- Diff/Patch: {DIFF}
- Ticket/Intent: {INTENT}
- Architektur-Kontext: {ARCH_CONTEXT}
- Nicht-funktionale Anforderungen (Perf/Security/Reliability): {NFRS}

Gib eine Review mit diesen Abschnitten:
1) Summary (2–4 Sätze)
2) Correctness-Risiken (mit Belegen aus dem Diff)
3) Security/Privacy-Risiken (Threats, Input-Validation, Secrets, PII)
4) Reliability (Timeouts, Retries, Idempotency, Error-Handling)
5) Performance (Hot paths, Allocation, DB-N+1, Caching)
6) Observability (Logs/Metrics/Tracing; was fehlt?)
7) Tests (was ist vorhanden, was fehlt, konkrete Testfälle)
8) Maintainability (Naming, APIs, Complexity) — nur wenn relevant
9) Action Items (priorisiert; MUST/SHOULD/NICE)

Regeln:
- Verweise auf konkrete Stellen aus {DIFF} (Datei/Funktion/Zeile, wenn vorhanden).
- Keine Stil-Nitpicks, außer sie verhindern Wartbarkeit.
- Wenn Kontext fehlt, liste 'Questions' am Ende (max. {MAX_QUESTIONS}).

Tipp: Ersetze {BRIEFING} / {FLOW} / {NOTES} durch deinen Kontext. Wenn etwas extern versendet werden soll, schreib explizit: "frag vorher".

Was der Prompt im System bewirkt

konkret & überprüfbar

Höherer Signal-to-Noise in Reviews
Frühzeitige Risikoerkennung (Security/Reliability)
Konkrete nächste Schritte statt vager Kommentare

Wozu das gut ist

wann du ihn nutzt

Struktur verhindert blinde Flecken
Priorisierung spart Zeit und reduziert Review-Zyklen