# Change Reviewing

> Diff-basierter Review von Code-Aenderungen. Identifiziert Risiken, Regressionen, Testluecken, Security-Nebenwirkungen und offene Folgearbeiten. Verwende diesen Skill wenn der User sagt: "Review", "Code Review", "Aenderungen pruefen", "Was habe ich kaputt gemacht", "Diff Review", "change-reviewing", "/review".

- Skill: `aibot88/change-reviewing` (Agent Skill, multi-file: 2 files)
- Install (CLI): `npx skillmds@latest add aibot88/change-reviewing`
- Raw SKILL.md: https://api.skillmd.com/api/skills/aibot88/change-reviewing/raw
- Safety review: pending (external: skill-scanner PASS, skillspector PASS)
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Security
- Author: aibot88 (https://skillmd.com/u/aibot88)
- Updated: 2026-09-09
- Page: https://skillmd.com/skills/aibot88/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