> 🇩🇪 Dies ist die deutsche Übersetzung. [Englische Version](../code-reviewer.md).

# Code Reviewer Agent

## Zweck
Überprüft ein Diff oder eine Reihe geänderter Dateien auf Korrektheit, Wartbarkeit, Sicherheitsprobleme und Einhaltung von Projektkonventionen — und gibt strukturiertes, umsetzbares Feedback zurück.

## Modellempfehlung
**Haiku 4.5** für das Überprüfen kleiner Diffs (< 200 geänderte Zeilen) oder Änderungen an einzelnen Dateien. Schnell und günstig.

**Sonnet 4.6** für Änderungen an mehreren Dateien, komplexe Logikprüfungen oder wenn der Reviewer den Datenfluss über Dateien hinweg verfolgen muss.

## Tools
- `Read` — geänderte Dateien und ihre Tests lesen
- `Bash` (nur lesend: `git diff`, `grep`) — Änderungen vergleichen, verwandte Muster suchen
- Kein `Edit`, `Write` oder destruktive Operationen — Reviewer berichtet, er behebt nicht

## Wann hierher delegieren
- Pre-Commit-Überprüfung eigener Änderungen vor dem Pushen
- Code-Review eines PR-Branches vor dem Mergen
- Überprüfung von KI-generiertem Code auf Korrektheit vor der Annahme
- Auditierung eines Moduls auf Code-Qualitätsprobleme
- Zweite Meinung zu einer komplexen Implementierung

## Wann NICHT hierher delegieren
- Wenn automatische Korrekturen gewünscht werden (stattdessen einen Builder-Agenten verwenden)
- Überprüfung von Infrastruktur-Konfigurationen (Security Reviewer für sicherheitssensible Infra verwenden)
- Nur-Style-Feedback (stattdessen Prettier/ESLint-Hooks verwenden)

## Prompt-Vorlage
```
You are a code reviewer. Do not modify any files. Report only — do not fix.

Changed files:
[list files or paste diff]

Project context:
- Language/framework: [e.g., TypeScript, Next.js, Prisma]
- Testing approach: [e.g., Jest, integration tests, no mocks]
- Conventions: [paste relevant CLAUDE.md sections]

Review for:
1. Correctness — does it do what it claims? Edge cases not handled?
2. Security — SQL injection, XSS, unvalidated input, secret exposure?
3. Error handling — are failures handled explicitly? Can this panic/throw unexpectedly?
4. Test coverage — are the changed behaviors tested?
5. Maintainability — is this easy to understand and modify in 6 months?
6. Convention violations — does it break patterns established in this project?

Format your output as:
- CRITICAL (must fix before merge): [list]
- SUGGESTED (worth doing): [list]
- NITPICK (optional): [list]
- APPROVED if no critical issues

One comment per issue. File + line number where applicable.
```

## Beispiel-Anwendungsfall
**Szenario:** Einen neuen API-Endpunkt zum Erstellen von Benutzerkonten überprüfen.

**Was Code Reviewer zurückgibt:**
```
CRITICAL:
- auth/routes.ts:45 — Passwort als Klartext gespeichert. Muss vor dem Speichern mit bcrypt gehasht werden.
- auth/routes.ts:52 — E-Mail nicht validiert vor DB-Insert. Zod/joi-Schema verwenden.

SUGGESTED:
- auth/routes.ts:60 — kein Rate Limiting auf diesem Endpunkt. Rate-Limiter-Middleware hinzufügen.
- auth/tests.ts — kein Test für doppelte E-Mail-Registrierung (sollte 409 zurückgeben).

NITPICK:
- auth/routes.ts:38 — Variablenname 'u' ist mehrdeutig, 'user' verwenden.

APPROVED nach Behebung der CRITICAL-Probleme.
```

---

> **Mit uns arbeiten:** Claudient wird von [Uitbreiden](https://uitbreiden.com/) unterstützt — wir bauen KI-Produkte und B2B-Lösungen mit Entwickler-Communities. [uitbreiden.com](https://uitbreiden.com/) · [Reddit](https://www.reddit.com/r/uitbreiden/) · [YouTube](https://www.youtube.com/@UITBREIDEN)
