Choisir le type de revue avant d’installer un skill
Une « revue » peut porter sur un diff local, une pull request GitHub, un invariant du dépôt ou une procédure d’analyse répétée. Ces besoins ne se traitent pas au même endroit. Partez du travail à examiner et choisissez le mécanisme le plus simple qui le couvre.
| Besoin | Point de départ | Pourquoi ce choix |
|---|---|---|
| Modifications non validées, indexées, de branche ou de commit | Codex /review | Examine un ensemble précis de changements locaux sans modifier le répertoire de travail |
| Pull request GitHub | Application Code Review / revue GitHub connectée | Réunit le diff, les commentaires, les contrôles et le contexte de la PR |
| Règle durable propre à ce dépôt | AGENTS.md | Conserve des instructions de projet concises près du code concerné |
| Formatage, types ou invariant reproductible | Tests, linters et CI | Des contrôles déterministes peuvent bloquer une fusion plutôt que simplement suggérer un problème |
| Procédure de revue spécialisée répétée | Skill personnalisé ciblé | Peut regrouper une méthode délimitée, un format de résultat et une interdiction explicite d’écriture |
Ce que la revue intégrée à Codex fait déjà
Dans un dépôt Git local, Codex propose /review avec des périmètres tels que les changements non validés ou la comparaison à une branche de référence. Il fournit des constats hiérarchisés sans modifier le répertoire de travail. C’est une fonction du produit, pas un skill à installer.
Pour les pull requests, l’application Codex Code Review peut afficher la description, les fichiers modifiés, les commentaires et les contrôles. Une revue automatique ou déclenchée par le dépôt dépend du compte source connecté, des permissions du dépôt et des paramètres de revue. Pour un second regard sur un diff, vérifiez d’abord si ces fonctions existantes suffisent avant d’ajouter un paquet.
- La cible est-elle un changement Git local ou une pull request hébergée ?
- La revue peut-elle examiner le diff exact et le comportement attendu ?
- Le processus retourne-t-il des constats sans appliquer de modifications ?
Placer les règles de revue du projet dans AGENTS.md
Utilisez AGENTS.md pour les contraintes durables que les relecteurs doivent régulièrement garder à l’esprit : engagements de compatibilité, limites d’accès aux données ou invariant important entre services. Codex Code Review peut appliquer les règles pertinentes du dépôt et les citer dans un constat. La règle suit alors le code au lieu de rester seulement dans la mémoire d’un relecteur.
Gardez chaque règle précise : risque, condition déclenchant le contrôle et solution sûre. « Préserver ce champ d’API publique ou ajouter un remplacement rétrocompatible » est plus exploitable que « vérifier la compatibilité ». Placez les règles propres à un service près de celui-ci. Confiez le style mécanique et le formatage à la CI plutôt que de mettre des consignes en concurrence avec des outils déterministes.
- Commencez par deux ou trois règles importantes, pas par une politique exhaustive.
- Délimitez chaque règle aux répertoires ou types de changements concernés.
- Incluez une alternative valide et sûre pour distinguer une violation d’une exception volontaire.
Quand un skill séparé de revue Codex mérite sa place
Un skill personnalisé est justifié lorsqu’il ajoute une procédure réutilisable que /review et les règles du dépôt ne décrivent pas déjà : par exemple, une revue en lecture seule centrée sur les défauts, qui examine toujours le diff complet, les tests et les appels pertinents, puis retourne uniquement des constats exploitables et étayés.
Le dépôt Codex d’OpenAI contient un exemple de skill review-agent avec ce type de contrat explicite. C’est un exemple à examiner, pas une garantie que tous les dépôts devraient l’installer. Il interdit les modifications de fichiers, commits, pushes, commentaires publiés et délégations supplémentaires. Sa valeur tient à la discipline et aux limites de la revue, pas à une promesse additionnelle de précision.
- Le skill remplit une tâche de revue distincte, pas un déclencheur en double de la revue intégrée.
- Ses accès en lecture, écriture, commandes, réseau et identifiants correspondent au besoin ; les instructions comme les scripts inclus doivent respecter la lecture seule.
- Les constats citent un chemin modifié précis et des preuves, pas des spéculations ou préférences de style.
Vérifier la qualité de la revue sur un petit cas avant de s’y fier
Un SKILL.md bien rédigé ne prouve pas que la revue est utile. Essayez les mêmes instructions sur trois petits diffs contrôlés : un défaut important que la règle devrait détecter, un contre-exemple valide qui ne devrait pas être signalé et un changement sans rapport qui ne devrait pas susciter de constats inutiles. Comparez les résultats réels aux résultats attendus.
- Le défaut connu produit un constat précis et exploitable lié au code modifié.
- Une exception sûre et un diff sans rapport ne produisent pas de bruit ou de constats inventés.
- La revue couvre tout le diff demandé au lieu de s’arrêter au premier problème.
- Le résultat indique les lacunes de tests et les risques résiduels ; « aucun constat » ne prouve pas que le changement est correct.
Un skill est un relecteur supplémentaire, pas une autorisation de fusion
Une revue Codex peut manquer des défauts ou soulever des points nécessitant davantage de contexte. Vérifiez chaque affirmation avec le diff courant, le comportement attendu et les tests. Les tests obligatoires, protections de branche et validations humaines restent les contrôles qui décident si un changement peut être fusionné.
En résumé : n’installez pas un skill de revue Codex simplement parce que votre recherche contient le mot « skill ». Utilisez d’abord /review pour les diffs locaux, Code Review pour les PR connectées, AGENTS.md pour les règles durables du projet et la CI pour les contrôles déterministes. Ajoutez un skill uniquement si un essai contrôlé démontre la valeur de sa procédure spécifique sans élargir les permissions ni produire de bruit.