Code Review Team Kit

Principes de base de la revue de code

Révisez les modifications que l'utilisateur indique. Si rien n'est précisé, examinez la branche courante par rapport à sa branche de base :

1. Trouvez la base : essayez git merge-base HEAD origin/main, puis origin/master, puis origin/develop. Si aucune n'existe, examinez les modifications non commitées (git diff HEAD).
2. Lisez le diff complet, puis ouvrez le code environnant pour toute modification que vous ne pouvez pas juger uniquement à partir du diff.

Liste de contrôle

Parcourez chaque élément. Ne signalez que les éléments qui révèlent un problème réel.

Correction

• Le code fait-il ce que la modification entend faire ? Recherchez les erreurs de décalage, les conditions erronées, les valeurs None/null non traitées, et les exceptions avalées.
• Les cas limites sont-ils traités : entrée vide, entrée très volumineuse, appels concurrents, tentatives ?

Tests

• Chaque changement de comportement est-il couvert par un test qui échouerait sans lui ?
• Les tests vérifient-ils le comportement, et non les détails d'implémentation ?

Lisibilité

• Les noms sont-ils précis ? Un nouveau venu comprendrait-il cela en une seule lecture ?
• Reste-t-il du code mort, des sorties de débogage ou du code commenté ?

Sécurité (principes de base)

• Pas de secrets, jetons ou identifiants dans le code, la configuration ou les logs.
• Les entrées utilisateur sont validées, et les requêtes sont paramétrées, jamais construites par concaténation de chaînes.

Cohérence

• La modification suit-elle les conventions définies dans CLAUDE.md et le code environnant ?

Résultat

Groupez les constats par sévérité :

• À corriger impérativement : bogues, problèmes de sécurité, tests manquants pour une logique risquée.
• À corriger si possible : problèmes de maintenabilité qui coûteront du temps plus tard.
• Optionnel : améliorations mineures. Gardez-en peu.

Pour chaque constat, donnez fichier:ligne, le problème, et une suggestion de correction concrète. Concluez par un verdict d'une ligne : prêt à fusionner, prêt après corrections impératives, ou nécessite une autre passe. Si vous ne trouvez rien dans une catégorie, omettez cette catégorie. N'inventez pas de problèmes pour remplir l'espace.

L'édition Pro ajoute des listes de contrôle complètes pour la sécurité, les performances, l'accessibilité et la conception d'API, ainsi qu'une commande /review qui sélectionne les bonnes listes en fonction du diff.