Skip to main content
Vous pouvez modifier ce que Code Review signale sur votre dépôt en y committant des instructions. C’est ainsi que vous réduisez le volume de nits, mettez fin aux commentaires sur les fichiers générés ou ajoutez une règle qui compte pour votre équipe. Placez-les dans l’un de ces deux fichiers :
  • CLAUDE.md : des instructions de projet que Claude Code lit pour chaque tâche, revues comprises. Code Review les lit comme contexte de projet et signale les modifications qui les enfreignent.
  • REVIEW.md : des instructions réservées aux revues. Utilisez-le pour indiquer ce que votre équipe souhaite voir signalé, à quel niveau de sévérité, et ce qu’il faut ignorer.
Ajoutez REVIEW.md à la racine de votre dépôt et fusionnez-le. Ensuite, protégez votre branche par défaut.
Pour modifier le niveau de détail des revues ou le moment où elles s’exécutent, demandez à un Owner de modifier le niveau de revue ou le paramètre Review runs.

​
Utiliser CLAUDE.md pour les règles à l’échelle du projet

Code Review lit les fichiers CLAUDE.md de votre dépôt comme contexte de projet. Une modification qui enfreint l’une de leurs règles devient un résultat au niveau de sévérité adapté au problème. Une revue lit le fichier CLAUDE.md à la racine de votre dépôt ainsi que les fichiers CLAUDE.md des répertoires parents de chaque fichier modifié. Le fichier CLAUDE.md d’un sous-répertoire est lu lorsque la pull request modifie un fichier sous ce chemin.

​
Utiliser REVIEW.md pour les règles propres aux revues

REVIEW.md est un fichier situé à la racine de votre dépôt qui adapte Code Review à votre dépôt. Vous pouvez également ajouter un REVIEW.md dans un sous-répertoire pour ajouter des vérifications sur les modifications sous ce chemin, en plus du fichier racine. Les agents qui détectent les problèmes et les agents qui les vérifient reçoivent son contenu en tant qu’instructions de revue de votre dépôt, en complément des consignes de revue par défaut de Code Review. L’étape qui rédige la revue finale le consulte avant de fixer la sévérité et de rédiger le résumé. Cet exemple d’arborescence comporte un fichier racine et un fichier de sous-répertoire :
Avant de vous appuyer sur un fichier de sous-répertoire, protégez votre branche par défaut et vérifiez ce qu’une revue lit selon la configuration de vos branches.
Le service Code Review et la commande /code-review locale sont deux outils distincts, et ils lisent des fichiers différents. Le service lit à la fois CLAUDE.md et REVIEW.md. La commande /code-review, que vous exécutez dans une session Claude Code sur votre propre machine, lit vos fichiers CLAUDE.md mais pas REVIEW.md. Placez dans CLAUDE.md les consignes que vous souhaitez appliquer aux deux endroits, et réservez REVIEW.md aux règles propres à la revue des pull requests.

​
Exemple de REVIEW.md

Ce REVIEW.md recalibre la sévérité pour un service backend, plafonne les nits, ignore les fichiers générés et ajoute des vérifications propres au dépôt.

​
Choisir ce qu’il faut écrire dans REVIEW.md

REVIEW.md est un fichier Markdown de forme libre qui modifie ce qu’une revue détecte et signale. Il ne modifie pas le format de la revue. Identifiez le problème que vous rencontrez, puis ajoutez une instruction semblable à celle indiquée. L’exemple utilise les quatre premières.
  • Les mauvais éléments sont marqués Important : redéfinissez ce que signifie 🔴 Important pour votre dépôt. Le calibrage par défaut cible le code de production, et un dépôt de documentation, un dépôt de configuration ou un prototype peuvent nécessiter une définition beaucoup plus restreinte. Indiquez quelles catégories de résultats sont Important et lesquelles sont tout au plus Nit. Vous pouvez également faire l’inverse, par exemple en traitant toute violation de CLAUDE.md comme Important.
  • Trop de nits : plafonnez le nombre de commentaires 🟡 Nit publiés par une même revue. Un plafond comme « signaler au maximum cinq nits » permet de garder des revues exploitables.
  • Commentaires sur des fichiers générés ou sur ce que la CI vérifie déjà : listez les chemins et les catégories de résultats pour lesquels Claude doit s’abstenir de signaler quoi que ce soit. Les candidats courants sont le code généré, les fichiers de verrouillage et les dépendances vendorisées, ainsi que tout ce que votre CI applique déjà, comme le linting ou la vérification orthographique. Pour les chemins qui méritent une certaine revue sans examen complet, fixez plutôt un seuil plus élevé : « dans scripts/, ne signaler que si c’est quasi certain et grave. »
  • Une règle d’équipe n’est pas vérifiée : ajoutez les règles que vous souhaitez voir signalées sur chaque pull request, comme « les nouvelles routes d’API doivent avoir un test d’intégration. »
  • Des résultats s’avèrent erronés : exigez des preuves avant qu’une catégorie de résultats soit publiée. Par exemple, « les affirmations sur le comportement nécessitent une citation file:line dans le source, et non une déduction à partir du nommage » réduit les faux positifs qui coûteraient sinon un aller-retour à l’auteur.
Certaines de ces instructions nécessitent que le fichier racine se trouve sur une branche par défaut protégée. Limitez REVIEW.md aux instructions qui modifient le comportement de la revue, et laissez le contexte général du projet dans CLAUDE.md.

​
Depuis quelle branche REVIEW.md est lu

Code Review lit REVIEW.md depuis la branche de base de la pull request ou depuis la branche par défaut, jamais depuis les modifications de la pull request elle-même. Pour modifier le comportement de la revue, fusionnez d’abord la modification de REVIEW.md. Conservez REVIEW.md sur votre branche par défaut et protégez cette branche. Lorsqu’une revue lit la copie présente sur une branche par défaut protégée, soit la première ligne du tableau ci-dessous, elle respecte ces instructions du fichier racine :
  • Abaisser la sévérité d’un résultat
  • Exclure des chemins, des fichiers ou des catégories de problèmes
  • Plafonner les commentaires de type nit

​
Ce qui compte comme protection de branche

Code Review considère ces paramètres comme une protection :
  • Branche par défaut : une règle de protection de branche classique ou un ruleset
  • Toute autre branche : un ruleset uniquement
Un ruleset compte lorsqu’il restreint les mises à jour ou exige des pull requests avec au moins une approbation. S’il exige des pull requests, il doit également révoquer cette approbation lors d’un nouveau push ou exiger que l’approbation intervienne après le dernier push.

​
Ce qu’une revue lit selon la configuration des branches

Trouvez la situation de votre dépôt dans la première colonne du tableau ci-dessous. Si le check run mentionne REVIEW.md, consultez Le check run mentionne REVIEW.md.