Change Reviewing

/change-reviewing — Diff-basierter Code-Review

Du reviewst konkrete Code-Aenderungen (Diffs, Branches, Commits) und machst Risiken, Regressionen und Folgearbeiten sichtbar.

Abgrenzung

• Nicht codebase-assessing: Dort wird der IST-Zustand breit analysiert. Hier fokussierst du auf einen konkreten Diff.
• Nicht gap-analyzing: Dort wird Soll gegen Ist verglichen. Hier wird ein Diff auf Qualitaet geprueft.
• Nicht testing-code: Dort werden Tests geschrieben. Hier wird identifiziert wo Tests fehlen.

Workflow

Phase 1 — Diff erfassen

1. Bestimme den Scope: Branch, Commit-Range oder unstaged Changes?
2. Lade den Diff:
   • git diff fuer unstaged
   • git diff --staged fuer staged
   • git diff main...HEAD fuer Branch vs. main
   • git log --oneline main..HEAD fuer Commit-Uebersicht
3. Identifiziere alle geaenderten Dateien und kategorisiere sie:
   • Produktionscode
   • Tests
   • Konfiguration / Migrations
   • Dokumentation

Phase 2 — Aenderungen bewerten

Fuer jede signifikante Aenderung pruefe:

Korrektheit:

• Tut der Code was er soll?
• Gibt es logische Fehler, Off-by-One, Race Conditions?
• Sind Edge Cases behandelt?

Sicherheit:

• Neue Inputs die nicht validiert werden?
• SQL Injection, XSS, Command Injection Risiken?
• Secrets oder sensible Daten exponiert?
• RLS Policies betroffen?

Architektur:

• Passt die Aenderung zu bestehenden Patterns?
• Wird Coupling eingefuehrt wo keines sein sollte?
• Sind Abstraktionen sinnvoll oder over-engineered?

Tests:

• Werden geaenderte Pfade von Tests abgedeckt?
• Fehlen Tests fuer neue Logik?
• Sind bestehende Tests noch gueltig?

Folgearbeiten:

• Braucht es Migrationen?
• Muessen Dokus aktualisiert werden?
• Muessen andere Services deployed werden?
• Sind TypeScript-Typen konsistent?

Phase 3 — Report schreiben

Erstelle den Report nach dem Template in templates/review-template.md.

Regeln:

• Positives explizit benennen — nicht nur Probleme.
• Jedes Risiko mit Schweregrad und konkreter Empfehlung.
• Blocker klar von Nice-to-Haves trennen.

Phase 4 — Ablage (optional)

Nur bei groesseren Reviews als Datei ablegen: docs/09_reviews/YYMMDD-<branch-oder-thema>.md (YYMMDD = rueckwaerts geschriebenes Datum, z.B. 260418-feature-x.md fuer 2026-04-18 — sortiert chronologisch)

Fuer kleine Reviews reicht die direkte Antwort im Chat.

Output

Strukturierter Review-Report (im Chat oder als Markdown-Datei).

Qualitaetskriterien

• Alle geaenderten Dateien sind erfasst
• Mindestens 1 positiver Aspekt benannt
• Risiken haben Schweregrad + Empfehlung
• Blocker sind klar von Verbesserungen getrennt
• Fehlende Tests sind identifiziert