JulienLerosty/claude-code-team-kit

Pull-Request überprüfen

1. Den Diff abrufen. Bei einer PR-Nummer gh pr diff <nummer>; sonst git diff origin/main...HEAD. Falls vorhanden, auch die PR-Beschreibung lesen (gh pr view <nummer>).
2. Geänderte Dateien vollständig lesen, wenn der Diff allein unklar ist. Code, den Sie nicht gelesen haben, nicht überprüfen.
3. In dieser Reihenfolge prüfen:
   • Korrektheit: falsche Bedingungen, Off-by-one, nicht behandelte Fehler, Race Conditions, null/leere Eingaben.
   • Tests: Ist jede Verhaltensänderung abgedeckt? Würden die Tests ohne die Änderung fehlschlagen?
   • Sicherheit: nicht vertrauenswürdige Eingaben, die Shell, SQL, Dateipfade oder HTML erreichen; Secrets im Diff.
   • Kompatibilität: geänderte öffentliche Schnittstellen, Migrationen, Konfiguration oder Umgebungsvariablen.
   • Lesbarkeit: nur Probleme, die den nächsten Maintainer ausbremsen würden. Reine Stilpräferenzen, die der Linter bereits abdeckt, überspringen.
4. npm test ausführen, falls Tests vorhanden sind, und das Ergebnis ehrlich berichten.

Ausgabeformat

## Zusammenfassung
Ein oder zwei Sätze darüber, was die PR tut, und Ihr Gesamturteil (approve / request changes / comment).

## Muss behoben werden
- `path/file.js:42` Was falsch ist, warum es wichtig ist, vorgeschlagene Korrektur.

## Sollte in Betracht gezogen werden
- `path/file.js:90` ...

## Schön zu haben
- ...

Lassen Sie einen Abschnitt weg, wenn er leer ist. Für jeden Fund file:line angeben. Erfinden Sie keine Probleme: Wenn die Änderung in Ordnung ist, sagen Sie das in der Zusammenfassung. Keine Kommentare auf GitHub posten, es sei denn, der Benutzer fragt danach.