JulienLerosty/claude-code-team-kit

Examiner une pull request

1. Obtenez le diff. Pour un numéro de PR, utilisez gh pr diff <numéro> ; sinon git diff origin/main...HEAD. Lisez également la description de la PR si elle existe (gh pr view <numéro>).
2. Lisez les fichiers modifiés en entier lorsque le diff seul n'est pas clair. Ne passez pas en revue du code que vous n'avez pas lu.
3. Vérifiez, dans cet ordre :
   • Correction : conditions erronées, off-by-one, erreurs non gérées, conditions de concurrence, entrées nulles/vides.
   • Tests : chaque changement de comportement est-il couvert ? Les tests échoueraient-ils sans le changement ?
   • Sécurité : entrée non fiable atteignant un shell, SQL, chemins de fichier ou HTML ; secrets dans le diff.
   • Compatibilité : interfaces publiques modifiées, migrations, configuration ou variables d'environnement.
   • Lisibilité : uniquement les problèmes qui ralentiraient le prochain responsable. Ignorez les préférences de style pur déjà couvertes par le linter.
4. Exécutez npm test si des tests existent et rapportez le résultat honnêtement.

Format de sortie

## Résumé
Une ou deux phrases décrivant ce que fait la PR et votre verdict global (approuver / demander des modifications / commenter).

## Corrections obligatoires
- `chemin/fichier.js:42` Ce qui ne va pas, pourquoi c'est important, correctif suggéré.

## À considérer
- `chemin/fichier.js:90` ...

## Suggestions
- ...

Ignorez une section si elle est vide. Citez fichier:ligne pour chaque constatation. N'inventez pas de problèmes : si le changement est correct, dites-le dans le résumé. Ne publiez pas de commentaires sur GitHub sauf si l'utilisateur le demande.