Révision de code

Configurez des révisions de PR automatisées qui détectent les erreurs logiques, les vulnérabilités de sécurité et les régressions en utilisant l'analyse multi-agents de votre base de code complète

Code Review analyse vos pull requests GitHub et publie les résultats sous forme de commentaires en ligne sur les lignes de code où il a trouvé des problèmes. Une flotte d'agents spécialisés examine les modifications de code dans le contexte de votre base de code complète, en recherchant les erreurs logiques, les vulnérabilités de sécurité, les cas limites cassés et les régressions subtiles.

Les résultats sont étiquetés par gravité et n'approuvent ni ne bloquent votre PR, de sorte que les flux de travail d'examen existants restent intacts. Vous pouvez affiner ce que Claude signale en ajoutant un fichier CLAUDE.md ou REVIEW.md à votre référentiel.

Pour exécuter Claude dans votre propre infrastructure CI au lieu de ce service géré, consultez GitHub Actions ou GitLab CI/CD. Pour les référentiels sur une instance GitHub auto-hébergée, consultez GitHub Enterprise Server.

Cette page couvre :

• Comment fonctionnent les révisions
• Configuration
• Déclenchement manuel des révisions avec @claude review et @claude review always
• Personnalisation des révisions avec CLAUDE.md et REVIEW.md
• Tarification
• Dépannage des exécutions échouées et des commentaires manquants
• Révision d'une diff localement avec la commande /code-review

Comment fonctionnent les révisions

Une fois qu'un administrateur active Code Review pour votre organisation, les révisions se déclenchent à l'ouverture d'une PR, à chaque push, ou sur demande manuelle, selon le comportement configuré du référentiel. Commenter @claude review démarre une révision sur une PR dans n'importe quel mode.

Lorsqu'une révision s'exécute, plusieurs agents analysent le diff et le code environnant en parallèle sur l'infrastructure Anthropic. Chaque agent recherche une classe de problème différente, puis une étape de vérification vérifie les candidats par rapport au comportement réel du code pour filtrer les faux positifs. Les résultats sont dédupliqués, classés par gravité et publiés sous forme de commentaires en ligne sur les lignes spécifiques où les problèmes ont été trouvés, avec un résumé dans le corps de la révision. Si aucun problème n'est trouvé, Code Review met à jour la vérification GitHub pour montrer qu'aucun problème n'a été détecté. Claude peut également publier un court commentaire de confirmation sur la PR.

Les révisions s'adaptent en coût à la taille et à la complexité de la PR, se complétant en moyenne en 20 minutes. Les administrateurs peuvent surveiller l'activité de révision et les dépenses via le tableau de bord analytique.

Niveaux de gravité

Chaque résultat est étiqueté avec un niveau de gravité :

Les résultats incluent une section de raisonnement étendu réductible que vous pouvez développer pour comprendre pourquoi Claude a signalé le problème et comment il a vérifié le problème.

Évaluer et répondre aux résultats

Chaque commentaire de révision de Claude arrive avec 👍 et 👎 déjà attachés de sorte que les deux boutons apparaissent dans l'interface utilisateur GitHub pour un classement en un clic. Cliquez sur 👍 si le résultat était utile ou 👎 s'il était incorrect ou bruyant. Anthropic collecte les comptages de réactions après la fusion de la PR et les utilise pour affiner le réviseur. Les réactions ne déclenchent pas une re-révision ou ne changent rien sur la PR.

Répondre à un commentaire en ligne ne pousse pas Claude à répondre ou à mettre à jour la PR. Pour agir sur un résultat, corrigez le code et poussez. Si la PR est abonnée aux révisions déclenchées par push, la prochaine exécution résout le thread quand le problème est corrigé. Pour demander une révision fraîche sans pousser, commentez @claude review comme un commentaire PR de haut niveau.

Pour rejeter un résultat sans modification du code, résolvez son thread ; répondre ne le rejette pas.

Sortie de l'exécution de vérification

Au-delà des commentaires de révision en ligne, chaque révision remplit l'exécution de vérification Claude Code Review qui apparaît aux côtés de vos vérifications CI. Développez son lien Details pour voir un résumé de chaque résultat en un seul endroit, trié par gravité :

Chaque résultat apparaît également comme une annotation dans l'onglet Files changed, marqué directement sur les lignes de diff pertinentes. Les résultats importants s'affichent avec un marqueur rouge, les nits avec un avertissement jaune, et les bugs préexistants avec un avis gris. Les annotations et le tableau de gravité sont écrits dans l'exécution de vérification indépendamment des commentaires de révision en ligne, de sorte qu'ils restent disponibles même si GitHub rejette un commentaire en ligne sur une ligne qui a bougé.

L'exécution de vérification se termine toujours avec une conclusion neutre, de sorte qu'elle ne bloque jamais la fusion via les règles de protection de branche. Si vous souhaitez conditionner les fusions aux résultats de Code Review, lisez la répartition de gravité à partir de la sortie de l'exécution de vérification dans votre propre CI. La dernière ligne du texte Details est un commentaire lisible par machine que votre flux de travail peut analyser avec gh et jq. Pour trouver l'ID de l'exécution de vérification, listez les exécutions de vérification du commit avec gh api repos/OWNER/REPO/commits/<commit-sha>/check-runs --jq '.check_runs[] | {id, name}' et prenez l'id de l'exécution Claude Code Review. Remplacez OWNER, REPO et CHECK_RUN_ID par le propriétaire de votre référentiel, le nom du référentiel et cet ID :

gh api repos/OWNER/REPO/check-runs/CHECK_RUN_ID \
  --jq '.output.text | split("bughunter-severity: ")[1] | split(" -->")[0] | fromjson'

Cela retourne un objet JSON avec des comptages par gravité, par exemple {"normal": 2, "nit": 1, "pre_existing": 0}. La clé normal contient le nombre de résultats importants ; une valeur non nulle signifie que Claude a trouvé au least un bug à corriger avant la fusion.

Ce que Code Review vérifie

Par défaut, Code Review se concentre sur la correction : les bugs qui cassent la production, pas les préférences de formatage ou la couverture de test manquante. Vous pouvez élargir ce qu'il vérifie en ajoutant des fichiers de guidance à votre référentiel.

Configurer Code Review

Un propriétaire active Code Review une fois pour l'organisation et sélectionne les référentiels à inclure.

Le tableau des référentiels affiche également le coût moyen par révision pour chaque référentiel en fonction de l'activité récente. Utilisez le menu d'actions de ligne pour activer ou désactiver Code Review par référentiel, ou pour supprimer complètement un référentiel.

Pour vérifier la configuration, ouvrez une PR de test. Si vous avez choisi un déclencheur automatique, une exécution de vérification nommée Claude Code Review apparaît dans quelques minutes. Si vous avez choisi Manual, commentez @claude review sur la PR pour démarrer la première révision. Si aucune exécution de vérification n'apparaît, confirmez que le référentiel est listé dans vos paramètres d'administration et que la GitHub App Claude y a accès.

Déclencher manuellement les révisions

Les commandes de commentaire démarrent une révision à la demande. Elles fonctionnent quel que soit le déclencheur configuré du référentiel, de sorte que vous pouvez les utiliser pour opter pour des PR spécifiques dans la révision en mode Manual ou pour obtenir une re-révision immédiate dans d'autres modes.

Utilisez @claude review always quand vous souhaitez que chaque push ultérieur vers la PR démarre une révision complète, par exemple sur une PR hautement prioritaire dans un référentiel défini en mode Manual. Comme la commande simple n'abonne pas la PR, vous pouvez demander un deuxième avis ponctuel sans modifier si les pushes ultérieurs déclenchent des révisions.

Pour que l'une de ces commandes déclenche une révision :

• Publiez-la comme un commentaire PR de haut niveau, pas un commentaire en ligne sur une ligne de diff
• Mettez la commande au début du commentaire, avec once ou always sur la même ligne que le reste de la commande
• Vous devez avoir un accès en écriture, maintenance ou administrateur au référentiel
• La PR doit être ouverte

Si le référentiel appartient à une organisation et votre adhésion à cette organisation est privée, ce qui est la valeur par défaut de GitHub, GitHub ne vous identifie pas à Claude en tant que membre. Claude peut toujours réagir à votre commentaire avec 👀, mais il ne démarre pas une révision à moins que vous ayez été ajouté au référentiel directement en tant que collaborateur, même quand une équipe ou les permissions de base de l'organisation vous donnent un accès en écriture. Pour corriger cela, rendez votre adhésion à l'organisation publique ou demandez à un administrateur du référentiel de vous ajouter au référentiel en tant que collaborateur.

Contrairement aux déclencheurs automatiques, les déclencheurs manuels s'exécutent sur les PR brouillon, car une demande explicite signale que vous souhaitez la révision maintenant quel que soit le statut de brouillon.

Si une révision s'exécute déjà sur cette PR, la demande est mise en file d'attente jusqu'à ce que la révision en cours se termine. Vous pouvez surveiller la progression via l'exécution de vérification sur la PR.

Réviser les demandes de tirage à partir de forks

Claude ne révise pas une demande de tirage à partir d'un fork automatiquement, quel que soit le paramètre Review Behavior du référentiel. Pour en démarrer une, commentez @claude review sur la demande de tirage. Les exigences pour les commandes de commentaire s'appliquent toujours, et l'accès en écriture dont vous avez besoin est au référentiel de base, pas au fork.

Pour obtenir une autre révision d'une demande de tirage fork, publiez un nouveau commentaire @claude review. @claude review always fonctionne aussi, mais n'abonne pas la demande de tirage aux révisions sur les pushes ultérieurs. Rien d'autre qu'une commande de commentaire ne démarre une révision sur une demande de tirage fork :

• Cliquer sur Re-run sur l'exécution de vérification ne démarre pas une révision
• Pousser de nouveaux commits ne démarre pas une révision, même dans un référentiel défini sur After every push

Personnaliser les révisions

Code Review lit deux fichiers de votre référentiel pour guider ce qu'il signale. Ils diffèrent dans la force avec laquelle ils influencent la révision :

• CLAUDE.md : instructions de projet partagées que Claude Code utilise pour toutes les tâches, pas seulement les révisions. Code Review le lit comme contexte de projet et signale les violations nouvellement introduites comme des nits.
• REVIEW.md : instructions de révision uniquement, données aux agents qui trouvent et vérifient les résultats et consultées par les agents qui classent et rapportent les résultats. Utilisez-le pour dire ce que votre équipe veut signaler, à quelle gravité, et comment les résultats sont rapportés.

CLAUDE.md

Code Review lit vos fichiers CLAUDE.md du référentiel et traite les violations nouvellement introduites comme des résultats au niveau nit. Cela fonctionne bidirectionnellement : si votre PR modifie le code d'une manière qui rend une déclaration CLAUDE.md obsolète, Claude signale que les docs doivent être mises à jour aussi.

Claude lit les fichiers CLAUDE.md à chaque niveau de votre hiérarchie de répertoires, donc les règles dans le CLAUDE.md d'un sous-répertoire s'appliquent uniquement aux fichiers sous ce chemin. Consultez la documentation de mémoire pour plus d'informations sur le fonctionnement de CLAUDE.md.

Pour la guidance spécifique à la révision que vous ne souhaitez pas appliquer aux sessions Claude Code générales, utilisez REVIEW.md à la place.

REVIEW\.md

REVIEW.md est un fichier à la racine de votre référentiel qui adapte Code Review à votre référentiel. Les agents du pipeline de révision qui trouvent et vérifient les résultats reçoivent son contenu comme les instructions de révision de votre référentiel, aux côtés de la guidance de révision par défaut de Code Review, et les agents qui classent et rapportent les résultats le consultent avant de fixer la gravité et d'écrire la révision.

Mettez les règles que vous souhaitez appliquer directement dans REVIEW.md.

Ce que vous pouvez affiner

REVIEW.md est du markdown libre, donc tout ce que vous pouvez exprimer comme une instruction de révision est dans le champ d'application. Les modèles ci-dessous ont le plus d'impact en pratique.

Gravité : redéfinissez ce que 🔴 Important signifie pour votre référentiel. L'étalonnage par défaut cible le code de production ; un référentiel de docs, un référentiel de config, ou un prototype pourrait vouloir une définition beaucoup plus étroite. Énoncez explicitement quelles classes de résultats sont Important et lesquelles sont Nit au maximum. Vous pouvez également escalader dans l'autre direction, par exemple en traitant toute violation CLAUDE.md comme Important plutôt que le nit par défaut.

Volume de nit : limitez le nombre de commentaires 🟡 Nit qu'une seule révision publie. La prose et les fichiers de config peuvent être polis à jamais. Un plafond comme « signaler au maximum cinq nits, mentionner le reste comme un comptage dans le résumé » garde les révisions actionnables.

Règles de saut : listez les chemins, les modèles de branche et les catégories de résultats où Claude ne devrait publier aucun résultat. Les candidats courants sont le code généré, les lockfiles, les dépendances vendues, et les branches créées par machine, 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 révision mais pas un examen complet, définissez une barre plus élevée au lieu de sauter entièrement : « dans scripts/, signaler uniquement si proche de certain et grave. »

Vérifications spécifiques au référentiel : ajoutez des règles que vous souhaitez signaler sur chaque PR, comme « les nouveaux itinéraires API doivent avoir un test d'intégration. » Parce que REVIEW.md atteint chaque agent de résultat et de vérification directement, ceux-ci atterrissent plus fiablement que les mêmes règles dans un long CLAUDE.md.

Barre de vérification : exigez des preuves avant qu'une classe de résultat soit publiée. Par exemple, « les affirmations de comportement ont besoin d'une citation file:line dans la source, pas une inférence à partir de la dénomination » réduit les faux positifs qui coûteraient autrement à l'auteur un aller-retour.

Convergence de re-révision : dites à Claude comment se comporter quand une PR a déjà été révisée. Une règle comme « après la première révision, supprimez les nouveaux nits et publiez les résultats Important uniquement » empêche un correctif d'une ligne d'atteindre la septième manche sur le style seul.

Forme du résumé : demandez au corps de la révision de s'ouvrir avec un comptage d'une ligne comme 2 factual, 4 style, et de commencer par « aucun problème factuel » quand c'est le cas. L'auteur veut connaître la forme du travail avant les détails.

Exemple

Ce REVIEW.md recalibre la gravité pour un service backend, limite les nits, saute les fichiers générés, et ajoute des vérifications spécifiques au référentiel.

# Instructions de révision

## Ce que Important signifie ici

Réservez Important aux résultats qui cassent le comportement, fuient les données,
ou bloquent un rollback : logique incorrecte, requêtes de base de données non scoped, PII
dans les logs ou les messages d'erreur, et les migrations qui ne sont pas backward
compatible. Le style, la dénomination, et les suggestions de refactorisation sont Nit au
maximum.

## Limiter les nits

Signaler au maximum cinq Nits par révision. Si vous en avez trouvé plus, dites « plus N
éléments similaires » dans le résumé au lieu de les publier en ligne. Si
tout ce que vous avez trouvé est un Nit, commencez le résumé par « Aucun problème bloquant. »

## Ne pas signaler

- Tout ce que CI applique déjà : lint, formatage, erreurs de type
- Fichiers générés sous `src/gen/` et tout fichier `*.lock`
- Code de test uniquement qui viole intentionnellement les règles de production

## Toujours vérifier

- Les nouveaux itinéraires API ont un test d'intégration
- Les lignes de log n'incluent pas les adresses e-mail, les ID utilisateur, ou les corps de requête
- Les requêtes de base de données sont scoped au tenant de l'appelant

Gardez-le concentré

La longueur a un coût : un long REVIEW.md dilue les règles qui importent le plus. Gardez-le aux instructions qui changent le comportement de révision, et laissez le contexte de projet général dans CLAUDE.md.

Afficher l'utilisation

Allez à claude.ai/analytics/code-review pour voir l'activité Code Review dans votre organisation. Le tableau de bord affiche :

Les chiffres de coût du tableau de bord sont des estimations pour surveiller l'activité. Pour les dépenses exactes de facture, consultez votre facture Anthropic.

Tarification

Code Review est facturé en fonction de l'utilisation des tokens. Chaque révision coûte en moyenne 15 à 25 dollars, s'adaptant à la taille de la PR, à la complexité de la base de code, et au nombre de problèmes nécessitant une vérification. L'utilisation de Code Review est facturée séparément via crédits d'utilisation et ne compte pas par rapport à l'utilisation incluse de votre plan.

Le déclencheur de révision que vous choisissez affecte le coût total :

• Une fois après la création de la PR : s'exécute une fois par PR
• Après chaque push : s'exécute à chaque push, multipliant le coût par le nombre de pushes
• Manuel : aucune révision sur les PR ouvertes ou les pushes, donc le coût s'accumule uniquement à partir des révisions que quelqu'un demande

En mode Une fois après la création de la PR ou Manuel, commenter @claude review always opte la PR dans les révisions déclenchées par push, de sorte que des coûts supplémentaires s'accumulent par push après ce commentaire. En mode Après chaque push, les pushes déclenchent déjà des révisions, donc l'abonnement ne change pas le coût par push. Commenter @claude review exécute une seule révision sans vous abonner à des pushes futurs. Claude révise une pull request à partir d'une fork uniquement lorsque quelqu'un commente @claude review, donc une pull request à partir d'une fork n'accumule jamais de coût par push dans aucun mode.

Les coûts apparaissent sur votre facture Anthropic quel que soit le fait que votre organisation utilise Amazon Bedrock ou Google Cloud's Agent Platform pour d'autres fonctionnalités Claude Code. Pour définir un plafond de dépenses mensuelles pour Code Review, allez à claude.ai/admin-settings/usage et configurez la limite pour le service Claude Code Review.

Surveillez les dépenses via le graphique de coût hebdomadaire dans analytics ou la colonne de coût moyen par référentiel dans les paramètres d'administration.

Dépannage

Les exécutions de révision sont au mieux. Une exécution échouée ne bloque jamais votre PR, mais elle ne se réessaye pas non plus d'elle-même. Cette section couvre comment récupérer d'une exécution échouée et où chercher quand l'exécution de vérification signale des problèmes que vous ne pouvez pas trouver.

Redéclencher une révision échouée ou expirée

Quand l'infrastructure de révision rencontre une erreur interne ou dépasse sa limite de temps, l'exécution de vérification se termine avec un titre de Code review encountered an error ou Code review timed out. La conclusion est toujours neutre, de sorte que rien ne bloque votre fusion, mais aucun résultat n'est publié.

Pour exécuter la révision à nouveau, commentez @claude review sur la PR. Cela démarre une révision fraîche sans abonner la PR aux pushes futurs. Si la PR n'est pas issue d'une fork, vous pouvez plutôt cliquer sur Re-run sur la vérification Claude Code Review dans l'onglet Checks de GitHub. Une réexécution démarre également une révision fraîche sans abonner la PR.

Révision n'a pas s'exécuté et la PR affiche un message de plafond de dépenses

Quand le plafond de dépenses mensuelles de votre organisation est atteint, Code Review publie un seul commentaire sur la PR expliquant que la révision a été ignorée. Les révisions reprennent automatiquement au début de la prochaine période de facturation, ou immédiatement quand un administrateur augmente le plafond à claude.ai/admin-settings/usage.

Trouver les problèmes qui ne s'affichent pas comme des commentaires en ligne

Si le titre de l'exécution de vérification dit que des problèmes ont été trouvés mais que vous ne voyez pas de commentaires de révision en ligne sur le diff, cherchez dans ces autres emplacements où les résultats sont surfacés :

• Check run Details : cliquez sur Details à côté de la vérification Claude Code Review dans l'onglet Checks. Le tableau de gravité liste chaque résultat avec son fichier, sa ligne, et son résumé quel que soit le fait que le commentaire en ligne ait été accepté.
• Files changed annotations : ouvrez l'onglet Files changed sur la PR. Les résultats s'affichent comme des annotations attachées directement aux lignes de diff, séparées des commentaires de révision.
• Review body : si vous avez poussé vers la PR pendant qu'une révision s'exécutait, certains résultats peuvent référencer des lignes qui n'existent plus dans le diff actuel. Ceux-ci apparaissent sous un titre Additional findings dans le texte du corps de révision plutôt que comme des commentaires en ligne.

Révision d'une diff localement

La commande /code-review examine une diff dans votre terminal sans installer l'application GitHub. Elle signale les bugs de correction et la réutilisation, la simplification, et les nettoyages d'efficacité.

/review est un alias de /code-review ; avant v2.1.223, c'était une commande séparée qui exécutait une révision en une seule passe, en lecture seule, d'une demande de tirage GitHub.

/code-review

Claude signale les résultats sous forme de texte dans la réponse dans ces deux exécutions, même quand une application hôte demande une liste des résultats :

• Dans une session de terminal, où /code-review exécute la révision en tant que sous-agent forké
• Dans une exécution -p avec sortie texte ou JSON

Dans une application hôte qui demande la liste des résultats, comme l'application de bureau, Claude signale les résultats de la révision via l'outil ReportFindings. Claude Code affiche le rapport sous forme de liste des résultats, et chaque entrée affiche l'emplacement du fichier, un résumé d'une phrase, et une balise de catégorie telle que correctness quand le résultat en porte une. Une demande hôte s'applique à chaque niveau d'effort et nécessite Claude Code v2.1.218 ou ultérieur.

Quand Claude corrige les résultats signalés plus tard dans la session, il les signale à nouveau, et Claude Code marque chaque résultat dans la liste des résultats mise à jour comme corrigé, ignoré, ou aucun changement nécessaire.

Ce que la révision lit et édite

La révision suit votre CLAUDE.md comme n'importe quelle session Claude Code, mais elle ne lit pas REVIEW.md. Une révision en arrière-plan applique ses édits --fix en dehors des points de contrôle de votre session, donc /rewind ne les annule pas ; utilisez git pour les annuler. Quand la révision s'exécute au premier plan, elle édite votre arborescence de travail pendant votre propre tour, donc /rewind restaure ses édits comme d'habitude.

Ajuster l'effort et les arguments

Passez un niveau d'effort pour échanger la couverture contre la confiance. À low et medium, la révision signale uniquement les résultats dont elle est la plus confiante, vous voyez donc moins de faux positifs ; high à max élargissent la couverture et peuvent inclure des résultats dont la révision est moins sûre.

Quand vous ne tapez pas de niveau, la révision réutilise le dernier niveau de low à max que vous avez tapé, même dans une session antérieure, et Claude Code affiche un avis tel que Reusing high effort, the level you typed last time. Tapez un niveau, comme /code-review high, pour changer ce que les exécutions ultérieures réutilisent ; un niveau que vous passez dans une exécution -p non interactive ne le met pas à jour. ultra ne met à jour ni n'utilise le niveau mémorisé. Si vous n'avez jamais tapé de niveau, la révision utilise l'effort actuel de la session. Avant v2.1.223, un /code-review sans niveau utilisait toujours l'effort actuel de la session.

Après le niveau d'effort et les drapeaux, Claude Code lit le reste de la ligne de l'une de deux façons :

• Sans ultra : tout ce qui reste est la cible de révision, même quand cela commence par un autre nom de commande. /code-review /fix-issue 123 examine avec /fix-issue 123 comme texte cible au lieu de charger /fix-issue comme une deuxième compétence empilée. Avant v2.1.218, une commande empilée après /code-review s'étendait comme sa propre compétence.
• Avec ultra : Claude Code lit un seul mot comme une branche de base ou un numéro de PR, et transforme le texte plus long qui ne nomme pas une branche ou une PR en une note attachée à la révision. /code-review ultra check my auth changes examine votre branche actuelle, et Claude relie les résultats à votre note.

Exécuter au premier plan

La révision s'exécute en arrière-plan par défaut ; avant v2.1.218, elle s'exécutait dans votre conversation. Elle s'exécute au premier plan à la place dans des cas comme ceux-ci :

• Vous exécutez /code-review à nouveau alors qu'une révision antérieure est toujours en cours
• Vous l'exécutez en mode non interactif, avec le drapeau -p ou le SDK Agent ; Claude Code attend la révision et inclut les résultats dans la réponse, sauf pour ultra, qui lance la révision en cloud sans attendre
• Vous définissez CLAUDE_CODE_DISABLE_BACKGROUND_TASKS à 1, ce qui désactive également toute autre fonctionnalité de tâche en arrière-plan

Laisser Claude démarrer la révision

Claude peut démarrer /code-review de lui-même. Demandez-lui d'examiner vos modifications en langage naturel et il peut exécuter la compétence sans que vous tapiez la commande, et une tâche programmée avec /code-review comme invite exécute la révision.

Une tâche programmée ne lance jamais la révision en cloud, donc programmez /code-review sans l'argument ultra.

Pour empêcher Claude et les tâches programmées de démarrer la révision tout en gardant /code-review disponible pour que vous la tapiez, ajoutez une entrée skillOverrides à un fichier de paramètres tel que ~/.claude/settings.json :

{
  "skillOverrides": {
    "code-review": "user-invocable-only"
  }
}

Avant v2.1.246, Claude démarrait /code-review de lui-même uniquement où un drapeau de fonctionnalité récupéré d'Anthropic l'activait. Dans les sessions qui ne récupèrent pas les drapeaux de fonctionnalité, /code-review s'exécutait uniquement quand vous le tapiez, et une /code-review programmée arrivait à Claude sous forme de texte brut.

Escalader vers ultrareview

/code-review ultra --fix exécute la ultrareview plus profonde dans le cloud, puis applique ses résultats à votre arborescence de travail quand ils reviennent dans votre session.

Ultrareview utilise sa propre portée : votre branche actuelle par rapport à la branche par défaut du référentiel, plus les modifications non validées et mises en scène dans l'arborescence de travail. Pour les modifications non validées des fichiers nommés comme des identifiants ou des clés, tels que les fichiers .env et *.tfvars, Claude Code suit les règles pour télécharger un référentiel local vers une session en cloud. Passez un nom de branche, tel que /code-review ultra develop, pour comparer par rapport à une base différente.

Quand la cible est une demande de tirage github.com, vous pouvez faire en sorte que Claude publie les résultats terminés à la PR en tant que commentaire depuis votre compte GitHub. Nécessite Claude Code v2.1.227 ou ultérieur.

Pour démarrer une révision en cloud à partir d'un script ou d'une CI, exécutez claude -p '/code-review ultra'. Claude Code lance la révision et imprime un lien pour la suivre. Nécessite Claude Code v2.1.218 ou ultérieur.

Quand la révision facturerait les crédits d'utilisation, Claude Code s'arrête avant de lancer, car la confirmation de facturation a besoin d'une session interactive. Exécutez la sous-commande claude ultrareview à la place ; en l'exécutant, vous consentez aux frais.

La commande s'appelait /simplify avant v2.1.147, quand elle appliquait les correctifs par défaut. /simplify exécute une révision de nettoyage séparé qui applique les correctifs sans rechercher les bugs. Si vous avez écrit un script /simplify pour la recherche de bugs, passez à /code-review --fix.

Ressources connexes

• Commandes : exécutez /code-review dans une session Claude Code locale pour vérifier une diff avant de pousser
• GitHub Actions : exécutez Claude dans vos propres flux de travail GitHub Actions pour une automatisation personnalisée au-delà de la révision de code
• GitLab CI/CD : intégration Claude auto-hébergée pour les pipelines GitLab
• Memory : comment les fichiers CLAUDE.md fonctionnent dans Claude Code
• Analytics : suivez l'utilisation de Claude Code au-delà de la révision de code
• How Anthropic secures its AI-native software development lifecycle : comment la révision automatisée s'inscrit comme une couche du processus de développement sécurisé d'Anthropic