Personnaliser Code Review

Ajustez ce que Code Review signale sur vos pull requests avec REVIEW.md et CLAUDE.md : recalibrez la sévérité, ignorez des chemins, ajoutez des vérifications et identifiez quelle copie s'applique.

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.

[!NOTE]

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. Sur une branche protégée, vous pouvez également ajouter un REVIEW.md dans la plupart des sous-répertoires pour ajouter des vérifications sur les modifications sous ce sous-répertoire, 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 :

your-repo/
├── REVIEW.md            # Root file
├── services/
│   └── billing/
│       └── REVIEW.md    # Adds checks for changes under services/billing/
└── src/

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.

[!NOTE]

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.

Quand un REVIEW.md de sous-répertoire ne s'applique pas

Code Review n'applique pas un REVIEW.md situé dans ou sous un sous-répertoire portant l'un de ces noms, quel que soit le contenu du sous-répertoire. Un nom de sous-répertoire ne correspond que s'il est identique dans son intégralité, quelle que soit la casse et à n'importe quelle profondeur ; ainsi, Tests correspond, mais pas integration-tests :

• Tests : test, tests, __tests__, testdata, fixtures, __fixtures__, golden, corpus, snapshots, __snapshots__
• Exemples : example, examples, sample, samples, demo, demos
• Code généré : generated
• Code tiers : vendor, third_party, third-party, thirdparty, node_modules, bower_components, external, extern, deps, godeps, pods, carthage, site-packages, contrib

Placez les vérifications pour ces sous-répertoires dans le REVIEW.md racine, ou dans le REVIEW.md d'un sous-répertoire parent lorsque ni ce parent ni aucun répertoire au-dessus ne figure dans la liste.

Les autres fichiers REVIEW.md de sous-répertoire situés sur les chemins modifiés par une pull request partagent une limite de 150 000 octets, sans compter le fichier racine. Si le check run signale que certains d'entre eux ne tenaient pas dans cette limite, raccourcissez les fichiers pour qu'ils la respectent.

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.

# Review instructions

## What Important means here

Reserve Important for findings that would break behavior, leak data,
or block a rollback: incorrect logic, unscoped database queries, PII
in logs or error messages, and migrations that aren't backward
compatible. Style, naming, and refactoring suggestions are Nit at
most.

## Cap the nits

Report at most five Nits per review.

## Do not report

- Anything CI already enforces: lint, formatting, type errors
- Generated files under `src/gen/` and any `*.lock` file
- Test-only code that intentionally violates production rules

## Always check

- New API routes have an integration test
- Log lines don't include email addresses, user IDs, or request bodies
- Database queries are scoped to the caller's tenant

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.

Inclure d'autres fichiers dans REVIEW.md

Vous pouvez répartir les instructions de revue sur plusieurs fichiers et les intégrer dans votre REVIEW.md racine. Procédez ainsi lorsque REVIEW.md devient long ou lorsque vous conservez déjà des règles de revue dans un autre fichier.

Pour inclure un fichier, ajoutez au REVIEW.md racine une ligne contenant uniquement @ suivi du nom du fichier. Code Review remplace cette ligne par le contenu du fichier, qui s'applique alors comme partie intégrante de REVIEW.md. Dans cet exemple, le fichier racine donne une instruction qui lui est propre, puis inclut deux fichiers de règles :

# Review instructions

Report at most five Nits per review.

@review-security.md
@review-api.md

Enregistrez les fichiers inclus à la racine du dépôt, à côté de REVIEW.md :

your-repo/
├── REVIEW.md
├── review-security.md
└── review-api.md

Code Review inclut les fichiers lorsqu'il lit REVIEW.md depuis une branche protégée ; vérifiez donc quelle branche une revue lit pour votre dépôt :

• Branche protégée : Code Review remplace la ligne @ par le fichier inclus
• Branche par défaut non protégée : la ligne @ reste dans REVIEW.md sous forme de texte brut. Si la pull request modifie le fichier nommé par la ligne, la ligne est omise.

Lorsqu'une revue n'applique pas un fichier inclus, vérifiez chacun des points suivants :

• Emplacement : déplacez le fichier à la racine du dépôt. À l'exception d'un fichier de skill, un chemin vers un sous-répertoire tel que @docs/review-rules.md n'est pas inclus.
• Nom : faites correspondre exactement le nom du fichier, casse comprise, et utilisez un nom sans espaces. Une ligne dont le nom ne correspond à aucun fichier situé à côté de REVIEW.md reste dans REVIEW.md sous forme de texte brut, et le check run ne la signale pas comme une inclusion ignorée.
• Un seul niveau : listez chaque fichier dans le REVIEW.md racine. Une ligne @ dans un fichier inclus ou dans un REVIEW.md de sous-répertoire reste sous forme de texte brut (les fichiers de skill font exception), et un lien Markdown vers un autre fichier ne constitue pas une inclusion.
• Limites : incluez au maximum huit fichiers différents, et maintenez REVIEW.md et les fichiers qu'il inclut sous 150 000 octets au total. Un fichier qui atteindrait la limite d'octets est ignoré en entier, et non tronqué. Le check run indique combien de lignes d'inclusion il a ignorées pour l'une ou l'autre limite.
• Liens : limitez les liens Markdown à 64 au maximum dans REVIEW.md et les fichiers qu'il inclut. Les liens vers des adresses http, https ou mailto et vers des ancres # ne sont pas comptés, pas plus que les liens présents dans un fichier de skill. Au-delà de cette limite, la revue ignore l'ensemble de votre REVIEW.md racine, et pas seulement les fichiers inclus. Le check run indique alors que les instructions n'ont pas été appliquées.
• Copie fusionnée : fusionnez le fichier inclus dans la branche depuis laquelle REVIEW.md est lu. La revue lit les deux depuis le même commit, jamais depuis les modifications de la pull request elle-même.

Inclure un fichier de skill

Pour que les revues suivent des consignes que vous conservez dans un skill, incluez le SKILL.md du skill dans votre REVIEW.md racine. Code Review n'exécute pas les skills.

Ajoutez @ suivi du chemin vers SKILL.md, sous la forme .claude/skills/<folder>/SKILL.md, sur une ligne à part :

# Review instructions

Report at most five Nits per review.

@.claude/skills/api-review/SKILL.md

Treat any change under `migrations/` as Important.

Protégez la branche depuis laquelle REVIEW.md est lu, car Code Review n'inclut un fichier de skill que lorsqu'il lit REVIEW.md depuis une branche protégée. Le fichier de skill est pris en compte dans les limites de huit fichiers et de 150 000 octets, et possède sa propre limite de 30 000 octets.

Rédiger une ligne de skill que Code Review inclut

Utilisez un nom de dossier sans espaces. Une ligne dont le chemin contient un espace reste dans REVIEW.md sous forme de texte brut, et le check run ne la signale pas comme une inclusion ignorée.

Si la ligne @ d'un skill enfreint l'une des règles ci-dessous, Code Review n'inclut pas le skill depuis cette ligne :

• Chemin : écrivez le chemin sous la forme .claude/skills/<folder>/SKILL.md depuis la racine du dépôt, avec le dossier du skill placé directement sous skills/. Contrairement à un nom de fichier à la racine, un chemin de cette forme qui ne correspond à aucun fichier est ignoré et comptabilisé.
• Source : copiez les consignes provenant de tout autre fichier sous .claude/, ou d'un skill intégré, personnel ou de plugin, dans un fichier situé à côté de REVIEW.md. Vous ne pouvez pas les inclure directement.
• Fichier : faites un commit de SKILL.md en tant que fichier texte ordinaire. Code Review ne suit pas les liens symboliques, que le lien soit le fichier lui-même ou un dossier de son chemin.
• Taille : maintenez SKILL.md à 30 000 octets au maximum, frontmatter compris
• Nombre : écrivez au maximum huit lignes de skill. Une ligne répétée est comptée à nouveau dans ces huit.
• Blocs dans REVIEW.md : placez la ligne @ en dehors des blocs de code. Fermez chaque commentaire HTML et chaque bloc <pre>, <script>, <style> ou <textarea> situé au-dessus.

Lorsque Code Review ignore une ligne de skill parce qu'elle enfreint la règle Fichier, Taille, Nombre ou Blocs, le message du check run concernant les lignes d'inclusion ignorées la comptabilise. Ce message n'apparaît que lorsque la revue applique REVIEW.md depuis une branche protégée.

Vérifier ce qu'une revue obtient d'un skill

Lorsque le skill est inclus, une revue obtient le corps de SKILL.md et rien d'autre du skill ; vérifiez donc le skill à l'aide de la liste ci-dessous.

• Frontmatter : répétez dans le corps tout ce dont une revue a besoin provenant du frontmatter, par exemple les conditions d'utilisation du skill indiquées par description
• Commandes injectées : écrivez explicitement ce qu'une commande ! fournirait. Code Review n'exécute pas la commande et remplace la ligne ou le bloc entier qui la contient par un espace réservé.
• Substitutions : remplacez $ARGUMENTS et les autres substitutions par du texte fixe, car une revue ne transmet aucun argument et les laisse telles qu'elles sont écrites
• Fichiers annexes : copiez dans SKILL.md ce dont une revue a besoin, car Code Review ne charge pas les scripts, les fichiers liés ni les références @file
• Exclusions et plafonds de Nits : écrivez les instructions qui excluent des résultats ou plafonnent les Nits dans REVIEW.md ou dans un fichier situé à côté, et non dans le skill. Code Review n'accepte le texte d'un skill comme motif ni pour l'un ni pour l'autre.
• Liens vers des fichiers du dépôt : indiquez en toutes lettres ce vers quoi pointe un lien ou une référence @file. La revue voit le chemin sous forme de texte brut ou d'espace réservé.

Si vous modifiez les commandes !, $ARGUMENTS ou les liens du skill, vous modifiez également son fonctionnement dans Claude Code. Si votre équipe s'appuie sur ces éléments, copiez les consignes dans un fichier situé à côté de REVIEW.md et incluez ce fichier à la place du skill.

Caractères que Code Review modifie dans le texte d'un skill

Code Review modifie certains caractères dans le texte du skill ; vos exemples de code parviennent donc à une revue sous la forme ci-dessous.

In SKILL.md:       Use `items[0]`, never `List<String>`.
The review reads:  Use ˋitems(0)ˋ, never ˋList< String>ˋ.

In SKILL.md:       Run `ps | grep api` and ask @alice.
The review reads:  Run ˋps ¦ grep apiˋ and ask @ alice.

Lorsqu'une règle dépend de l'un de ces caractères, énoncez-la également en toutes lettres.

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

Écrivez les exclusions et les plafonds de Nits dans REVIEW.md ou dans un fichier situé à côté, et non dans un skill inclus.

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.

Ressources associées

• Code Review : ce qu'est le service et comment se déroule une revue
• Lire et demander des revues sur une pull request : ce que signifie chaque niveau de sévérité et comment les résultats apparaissent
• Configurer Code Review : le niveau de revue et le moment où les revues s'exécutent, définis par un Owner
• Effectuer une revue en local avec /code-review : la commande /code-review, ses arguments et ses niveaux d'effort
• Mémoire : comment les fichiers CLAUDE.md fonctionnent dans Claude Code