Audit des prompts Claude Code : tutoriel de /doctor prompt-audit
Comment auditer votre configuration Claude Code à la recherche de prompts écrits pour d'anciens modèles : passer en 2.1.283, lancer /doctor prompt-audit sur un vrai projet, lire le rapport des neuf vérifications et n'approuver que les correctifs voulus.
L'audit des prompts en quatre lignes
- L'audit des prompts est une sous-commande du bilan de configuration /doctor : lancez /doctor prompt-audit (ou /checkup prompt-audit) dans une session Claude Code.
- Il analyse vos fichiers CLAUDE.md, vos skills, vos agents et vos commandes à la recherche de schémas de prompting écrits pour d'anciens modèles, et place en tête les chemins obsolètes, les commandes obsolètes et les fichiers d'instructions contradictoires.
- Il est arrivé avec Claude Code 2.1.283 : mettez donc à jour d'abord. Une build antérieure répond à /doctor par une erreur de sous-commande inconnue au lieu d'un rapport.
- Le bilan rend son rapport d'abord et demande confirmation avant de modifier quoi que ce soit ; pour une simple passe en lecture seule, lancez plutôt claude doctor dans un terminal.
Anthropic just dropped the new Checkup command (/doctor)
Chaîne:Software Engineer Meets AI2:18
Claude Code 2.1.283 — Prompt Audits & Windows Fix
Chaîne:Claude Code Updates1:02
Claude Code v2.1.283 — Advanced Model Control and Auditing
Chaîne:Claude Code Changelog2:10
Claude Code changelog — 2.1.283 adds /doctor prompt-audit
Docs:github.com/anthropics/claude-codeChangelog
Claude Code commands reference — /doctor, /checkup and /claude-api
Docs:code.claude.comDocs
Les captures proviennent de trois enregistrements. Software Engineer Meets AI a filmé un bilan /doctor complet sur la v2.1.205 ; la sous-commande prompt-audit et son périmètre ont été annoncés en v2.1.283 et partagent cette même interface de bilan. Claude Code Updates et Claude Code Changelog ont fourni les images de la version 2.1.283. Chaque image a été vérifiée à la main ; les deux diapositives ont été recadrées pour retirer les logos incrustés des chaînes.
Les captures d'écran restent la propriété des chaînes ci-dessus et servent à illustrer nos propres instructions écrites ; chaque étape renvoie à son horodatage.
Lancer l'audit des prompts Claude Code, étape par étape
Avant de lancer
- 1
Mettre Claude Code à jour vers 2.1.283 ou plus récent
Ne lancez /doctor prompt-audit que sur une build qui l'embarque. Vérifiez la version dans votre terminal avec claude --version, puis mettez à jour avec claude update si elle est antérieure à 2.1.283 — la version qui a ajouté l'audit. Dans une session, le contrôle de version de /doctor (vérification 6) compare la version installée à votre canal de publication.
« Prompt Audit » figure en tête de la version 2.1.283 : une build sans lui ne peut donc pas répondre à la commande.Voir à 0:08 - 2
Comprendre pourquoi les anciens prompts méritent un audit
Les instructions écrites pour un modèle plus ancien s'accumulent dans les fichiers de mémoire, les skills, les agents et les commandes, et continuent de peser sur chaque session bien après la disparition du modèle pour lequel elles avaient été réglées. L'audit sert justement à faire remonter ces schémas obsolètes pour savoir exactement quoi réécrire au lieu de deviner.
La carte explique comment ces instructions s'accumulent : fichiers de mémoire, skills, agents et commandes.Voir à 0:12 - 3
Retenir la commande exacte et son périmètre d'analyse
La commande est /doctor prompt-audit, et /checkup prompt-audit fait exactement la même chose puisque /checkup est un alias de /doctor. Son périmètre est votre configuration Claude Code : fichiers CLAUDE.md, skills, agents et commandes. C'est une sous-commande du bilan de configuration, pas un plugin séparé ni une installation depuis un marketplace.
La diapositive de version montre un simple argument sur une commande existante : il n'y a rien à installer.Voir à 1:02
Lancer l'audit dans une session active
- 4
Ouvrir Claude Code dans le projet à auditer
Démarrez la session à la racine du projet. L'audit lit la configuration que ce projet charge réellement : une session ouverte dans un dossier parent auditera les mauvais fichiers CLAUDE.md. La ligne d'en-tête confirme le dossier et le modèle avant que vous ne tapiez quoi que ce soit.
Le dossier de travail affiché dans l'en-tête de session délimite le périmètre de l'audit.Voir à 1:00 - 5
Taper la commande et la laisser travailler en lecture seule
Tapez /doctor prompt-audit dans le prompt. Le bilan annonce sa méthode avant de commencer : il exécute d'abord le contrôle de santé en lecture seule et présente un rapport avant de modifier quoi que ce soit. Attendez-vous à plusieurs allers-retours de lecture de fichiers et de commandes shell pendant qu'il rassemble les preuves — c'est normal, ce n'est pas un blocage.
La promesse de lecture seule précède toute proposition : rien n'est écrit pendant l'investigation.Voir à 0:30 - 6
Le regarder rassembler les faits pour chaque vérification
La transcription montre à quelle vérification chaque commande se rattache : la dernière version pour la vérification 6, les dossiers de skills et la configuration des hooks pour les vérifications d'extensions, les petits fichiers CLAUDE.md pour les vérifications 2 et 3, et les transcriptions de sessions récentes pour les vérifications 1, 4 et 8. Si un hook bloque une commande, le bilan reformule les faits dont il a besoin et réessaie au lieu d'échouer.
Chaque commande exécutée est rattachée à une vérification numérotée.Voir à 0:36
Lire le rapport
- 7
Connaître les neuf vérifications que le rapport peut couvrir
La vérification 0 porte sur la santé de l'installation, la 1 sur les extensions inutilisées, la 2 sur le dédoublonnage de la mémoire LOCAL, la 3 sur la migration du contenu toujours chargé, la 4 sur les hooks lents, la 5 sur les extensions gourmandes en contexte, la 6 sur la version, la 7 sur le mode auto comme mode de permission par défaut et la 8 sur les commandes en lecture seule souvent refusées. Pour un audit de prompts, ce sont les vérifications des fichiers d'instructions qui comptent le plus : la 2 repère les notes personnelles qui dupliquent ou contredisent les consignes d'équipe versionnées, et la 3 sort du contexte toujours actif les consignes rarement utiles.
Les vérifications 2, 3 et 5 sont celles qui touchent CLAUDE.md et les autres fichiers d'instructions.Voir à 1:16 - 8
Lire d'abord la section « Proposed actions »
« Proposed actions » est la partie du rapport qui modifierait des fichiers, et chaque entrée nomme le fichier concerné et précise si la modification est réversible. Une vérification saine est marquée et close par « No action » : vous voyez d'un coup d'œil lesquelles des neuf ont trouvé quelque chose et lesquelles n'ont rien trouvé.
Lisez le chemin de fichier dans chaque proposition avant de décider — c'est là que la modification atterrit.Voir à 0:40 - 9
Lire les avertissements et les deux questions de confirmation
Sous les propositions se trouve un bloc « Warnings (no action) » pour ce que l'audit a mesuré sans vouloir le changer — hooks lents et extensions gourmandes en contexte, chiffres à l'appui pour que vous jugiez vous-même. Le rapport se termine en vous posant ses questions de confirmation plutôt qu'en supposant la réponse.
Les avertissements sont des mesures, pas des modifications : ils portent des chiffres, pas des propositions.Voir à 0:56
Approuver et recommencer
- 10
Approuver, choisir ou refuser avant toute écriture
Le bilan se termine sur un menu : « Clean up everything » (recommandé), « Let me pick », « No, keep everything », « Type something » et « Chat about this ». L'option recommandée applique toutes les propositions, « Let me pick » parcourt la liste point par point, et « No, keep everything » laisse chaque fichier intact. Rien n'est appliqué à partir du seul rapport.
La valeur par défaut est une question, pas une modification : tout le modèle de sécurité tient là.Voir à 0:52 - 11
Mettre l'audit dans un rappel mensuel
L'audit est assez léger pour être répété, mais rien dans Claude Code ne le lancera à votre place selon un calendrier : /schedule crée une tâche cloud et /loop ne tourne que tant que la session est active. La solution pratique est un événement récurrent dans votre agenda qui vous rappelle de le relancer — tous les mois, ou après une montée de version qui rend vos anciens schémas obsolètes.
Un rappel mensuel est le seul planificateur qui survit aux redémarrages.Voir à 2:08
Les cinq pannes que vous rencontrerez vraiment
La plupart des signalements d'audit de prompts en panne correspondent à l'un de ces cas. Vérifiez-les dans l'ordre avant de conclure que la commande manque.
- 1Commande inconnue ou aucune entrée prompt-audit — votre build est antérieure à 2.1.283. Lancez claude --version, mettez à jour avec claude update, puis démarrez une session neuve pour charger la nouvelle build.
- 2/checkup prompt-audit ou /doctor prompt-audit — c'est la même commande. /checkup est documenté comme l'alias de /doctor : les deux préfixes mènent au même skill de bilan.
- 3/claude-api prompt-audit est une autre sous-commande, avec une autre cible. Elle audite les prompts, les skills et les descriptions d'outils de votre propre code d'application Claude API et propose des correctifs sous forme de diff ; elle exige Claude Code 2.1.221 ou plus récent, pas 2.1.283, et ne regardera pas vos fichiers CLAUDE.md.
- 4L'audit ne dit rien de vos fichiers d'instructions — soit ils sont vraiment sobres, soit ils n'ont jamais été chargés. Lancez /context pour voir quels fichiers de mémoire et quels skills sont réellement dans le contexte, et confirmez que vous avez démarré la session à la racine du projet.
- 5Vous voulez une passe en lecture seule sans aucune session — lancez claude doctor dans votre terminal. Il affiche les diagnostics d'installation et de réglages sans démarrer de session, alors que le /doctor en session est la version qui peut proposer et appliquer des correctifs.