---
name: code-review
description: Review des Diffs seit einem festen Punkt entlang zweier Achsen, Standards und Spec. Automatisch wählbar beim Reviewen eines Branches, einer PR, oder von Arbeitsstand seit X.
kategorie: Hauptfluss
---

# code-review: Review entlang zweier Achsen

Review des Diffs zwischen `HEAD` und einem fixen Punkt, den du angibst, entlang zweier getrennter
Achsen:

- **Standards**: folgt der Code den dokumentierten Coding-Standards dieses Repos?
- **Spec**: setzt der Code das ursprüngliche Ticket/die Spec tatsächlich um?

## Wann brauche ich das?

Bevor du committest, wenn du einen Branch oder eine Änderung seit einem bestimmten Punkt reviewen
willst.

## Wie funktioniert das?

### 1. Fixpunkt festlegen

Du nennst den Fixpunkt (Commit-SHA, Branch, Tag, `main`, `HEAD~5`, …). `git diff <fixpunkt>...HEAD`
und `git log <fixpunkt>..HEAD --oneline` sind über die Git-Introspektion des Chats abrufbar, das
funktioniert direkt.

### 2. Spec-Quelle

Da keine Tracker-Anbindung existiert, fügst du den Spec-/Ticket-Text manuell ein (Copy-Paste aus
Jira), oder verweist auf eine Datei im Repo (`docs/`, `.scratch/`). Ohne Spec markiert die
Spec-Achse sich selbst als "keine Spec verfügbar" statt sie zu überspringen.

### 3. Standards-Quellen

Alles im Repo, das dokumentiert, wie Code geschrieben werden soll (`CODING_STANDARDS.md`,
`CONTRIBUTING.md`, ESLint-/Checkstyle-Konfiguration). Zusätzlich gilt immer die
**Fowler-Smell-Baseline** (siehe unten), der Repo-Standard hat aber immer Vorrang, wo er etwas
ausdrücklich erlaubt, was die Baseline anmahnen würde.

**Smell-Baseline** (jeder Fund ist eine Einschätzung, kein hartes Urteil):

- **Mysterious Name**: Name verrät nicht, was etwas tut/hält → umbenennen.
- **Duplicated Code**: dieselbe Logik mehrfach im Diff → gemeinsame Form extrahieren.
- **Feature Envy**: eine Methode greift mehr auf fremde Daten zu als auf eigene → verschieben.
- **Data Clumps**: dieselben Felder reisen immer zusammen → in einen Typ bündeln.
- **Primitive Obsession**: ein Primitive/String steht für ein Domain-Konzept → eigener Typ.
- **Repeated Switches**: dieselbe Fallunterscheidung wiederholt sich → Polymorphie oder eine Map.
- **Shotgun Surgery**: eine fachliche Änderung verstreut sich über viele Dateien → bündeln.
- **Divergent Change**: eine Datei ändert sich aus mehreren unabhängigen Gründen → aufteilen.
- **Speculative Generality**: Abstraktion für einen Bedarf, den die Spec nicht hat → löschen.
- **Message Chains**: lange `a.b().c().d()`-Ketten → hinter einer Methode verstecken.
- **Middle Man**: eine Klasse, die nur weiterreicht → weglassen, direkt aufrufen.
- **Refused Bequest**: eine Unterklasse ignoriert das meiste, was sie erbt → Komposition statt Vererbung.

### 4. Beide Achsen nacheinander statt parallel

Im Original laufen Standards- und Spec-Review als zwei parallele Subagenten. Ohne Agenten laufen
sie sequenziell im selben Chat: erst die eine Achse komplett durchgehen und das Ergebnis notieren,
dann die andere. Inhaltlich identisch, nur nacheinander statt gleichzeitig.

### 5. Zusammenfassen

Beide Berichte unter eigenen Überschriften `## Standards` und `## Spec`, nicht mischen, nicht
gegeneinander aufwiegen. Ein Fund kann eine Achse bestehen und die andere durchfallen lassen, das
ist der Grund für die Trennung.

## Wo passt das rein?

Letzter Kettenschritt im Hauptfluss (`grill-me → to-spec → to-tickets → implement →
code-review`), von `implement` am Ende aufgerufen. Reicht auch standalone, wenn du selbst einen
Branch reviewen willst. Gesamtüberblick: `ask-simon`.

## Was sich gegenüber dem Original geändert hat

- Keine parallelen Subagenten, sondern ein sequenzieller Zwei-Pass-Review im selben Chat.
- Keine automatische Spec-Beschaffung über den Issue-Tracker, du kopierst den Spec-Text manuell
  rein.