Prompts Claude Code : 25 invitations et instructions prêtes à l'emploi et comment rédiger les vôtres

Les clients utilisant un bon de réduction périmé reçoivent une erreur 500 lors du paiement. Examinez le fichier @src/checkout/coupons.ts et ses tests. Le comportement attendu est l'affichage d'un message indiquant que le bon de réduction n'est pas valide, sans création de commande. Écrivez un test qui échoue et qui reproduit l’erreur, puis corrigez-la sans modifier le comportement des coupons valides. Exécutez la [commande de test de paiement] et présentez les résultats avant et après. Si vous ne parvenez pas à reproduire l’erreur, indiquez ce que vous avez vérifié avant de modifier l’implémentation.

Ajoutez un sélecteur de date à [chemin du formulaire de réservation]. Respectez les conventions relatives aux composants et à la validation définies dans @src/components/TimeSelect.tsx. Les utilisateurs doivent pouvoir sélectionner [dates autorisées], tandis que [dates indisponibles] restent désactivées. N’ajoutez pas de bibliothèques. Exécutez [commande de test du composant] et [commande de vérification de type], puis signalez tout critère non couvert par ces vérifications.

Divisez le fichier @src/reports/export.py en fonctions plus petites tout en conservant ses entrées, son format de sortie et son comportement en cas d'erreur. Exécutez la [commande de test d'exportation] avant que la modification en cours ne soit terminée et signalez toute erreur existante. Après la refactorisation, relancez les tests et présentez les deux séries de résultats. Ne modifiez pas l'interface publique ni les fichiers non concernés.

« Claude teste chaque modification que je déploie sur claude.ai/code à l’aide de l’extension Chrome Claude. Il ouvre un navigateur, teste l’interface utilisateur et répète l’opération jusqu’à ce que le code fonctionne et que l’expérience utilisateur soit satisfaisante. »

Examinez le fichier README, la configuration du projet et la structure des répertoires de niveau supérieur de ce référentiel. Ne suivez les références que dans la mesure où cela est nécessaire pour expliquer : ce que fait l’application ; ses points d’entrée principaux et ses composants majeurs ; où se trouvent les tests et quelles commandes le référentiel définit pour les exécuter. Citez les chemins d’accès aux fichiers qui étayent votre explication. Distinguez le comportement documenté de vos propres déductions, et signalez tout ce que vous ne parvenez pas à déterminer. Ne lisez pas les fichiers contenant des informations confidentielles ou de configuration d’environnement, n’inspectez pas les dépendances installées et ne modifiez aucun fichier. Terminez en indiquant les trois fichiers que je devrais lire en premier et expliquez pourquoi.

Passez en revue l'historique Git d'un [fichier, d'une fonction ou d'une classe], en vous concentrant sur [un comportement ou une question de conception]. Identifiez les commits qui ont introduit ou modifié de manière significative ce comportement. Pour chaque commit pertinent, indiquez son hachage, résumez la modification et expliquez toute justification documentée dans le message de commit ou dans la discussion liée à laquelle vous avez accès. Indiquez clairement les raisons déduites en les qualifiant d'« inférences ». Si l'historique n'explique pas une décision, précisez-le. Ne modifiez pas les fichiers ni l'historique Git.

Suivez le déroulement des évènements lorsqu'une [action de l'utilisateur ou un évènement du système] se produit, en partant d'un [chemin, gestionnaire ou dossier connu]. Suivez les appels pertinents à travers la validation, la logique métier et toute écriture dans la base de données ou requête externe. Répertoriez les fichiers et les fonctions dans l'ordre d'exécution, en indiquant les numéros de ligne lorsque cela est possible. Expliquez les principaux chemins d'échec et identifiez les tests existants couvrant le flux. Signalez toute connexion que vous ne pouvez pas confirmer à partir du code. N’exécutez pas le flux, n’appelez pas de services externes et ne réalisez pas de modifications en cours sur les fichiers.

Planifiez la mise en œuvre de la [fonctionnalité] dans la [zone du référentiel]. Le comportement attendu est le suivant : [exigences], et ces zones doivent rester inchangées : [contraintes]. Examinez le code concerné et les tests existants. Identifiez les fichiers à modifier, l’ordre de mise en œuvre, ainsi que les risques éventuels liés à la compatibilité ou à la migration des données. Associez chaque exigence à un test proposé ou à une autre étape de vérification. Dressez séparément la liste des questions en suspens et des hypothèses. Ne mettez pas encore en œuvre la fonctionnalité. Renvoyez-moi le plan pour que je l’examine.

Je souhaite développer [brève description] pour [utilisateurs et cas d’utilisation]. Lisez d’abord [les fichiers ou exigences pertinents], puis utilisez AskUserQuestion pour clarifier les décisions susceptibles d’avoir un impact significatif sur la mise en œuvre. Concentrez-vous sur les cas limites, le traitement des données, les permissions, le comportement attendu de l’interface utilisateur et les compromis. Ne posez pas de questions auxquelles le contexte fourni apporte déjà une réponse. Une fois les décisions clés prises, rédigez un cahier des charges couvrant les exigences, les critères d’acceptation, les contraintes et ce qui est hors du périmètre. Indiquez clairement toute hypothèse restante. Montrez-moi le cahier des charges avant de l’enregistrer dans [chemin d’accès au cahier des charges], et ne remplacez pas un fichier existant sans autorisation.

Évaluez l’impact du passage de [fonction, composant ou interface] du [comportement actuel] au [comportement proposé]. Recherchez dans [le référentiel ou le répertoire] sa définition, ses appelants directs, ses importations et les tests associés. Dressez la liste des fichiers susceptibles de nécessiter des modifications et expliquez en quoi chacun pourrait être affecté, en indiquant les références de fichier et de ligne lorsque cela est possible. Signalez les appels résolus dynamiquement, les consommateurs externes ou toute autre dépendance que vous ne pouvez pas vérifier. Identifiez les problèmes de compatibilité qui nécessitent une réponse avant la mise en œuvre. Ne modifiez pas les fichiers ; renvoyez l’évaluation d’impact et attendez mon examen.

Ajoutez la [fonctionnalité] au [fichier ou à la page] avec le comportement suivant : [critères d'acceptation]. Examinez la [mise en œuvre existante] et respectez ses conventions en matière de récupération des données, de gestion des erreurs et d'organisation des composants. N'utilisez que les bibliothèques déjà installées dans le projet. Limitez les modifications au [périmètre] et préservez le [comportement existant ou l’interface publique]. Ajoutez ou mettez à jour les tests correspondant aux critères d’acceptation. Exécutez la [commande de test] et la [commande de vérification de type ou de lint], puis signalez les fichiers modifiés, les résultats et toute vérification que vous n’avez pas pu achever. Si le modèle existant entre en conflit avec une exigence, expliquez ce conflit avant de poursuivre.

Implémentez [nom de la fonction] dans [fichier] pour répondre aux [exigences]. Couvrez le [cas normal], les [cas limites] et le [comportement en cas d’entrée non valide]. Exécutez d’abord la [commande de test pertinente] et signalez tout échec existant. Écrivez des tests pour le comportement demandé, puis exécutez-les avant l’implémentation. Vérifiez que les nouveaux tests échouent pour la raison attendue. Implémentez la fonction et relancez les tests. N’affaiblissez pas les assertions, ne sautez pas de tests et ne modifiez pas le comportement attendu pour les faire réussir. Si les exigences entrent en conflit avec des tests existants, arrêtez-vous et expliquez ce conflit. Montrez les résultats « avant » et « après ».

Implémentez le design pièce jointe dans [composant ou page], en utilisant les composants et les styles existants du projet. Préservez [le comportement requis] et évitez toute modification en dehors de [la portée]. Utilisez [le navigateur configuré ou l’outil de capture d’écran] pour capturer [la route locale] aux [dimensions de la fenêtre d’affichage] avec [les données de test et l’état de l’interface utilisateur]. Si l’outil ou l’application n’est pas disponible, indiquez ce qui est nécessaire plutôt que de vous contenter d’une vérification visuelle. Comparez la capture avec la référence, en vous concentrant sur [la disposition, l’espacement, la typographie ou d’autres critères d’acceptation]. Effectuez jusqu’à [nombre] cycles de correction, puis signalez les différences restantes. Ne modifiez pas l’image de référence. Exécutez [les tests de composants pertinents] et [la commande de vérification de type ou de compilation]. Incluez la capture d’écran et les résultats réels de la vérification dans votre résumé.

Les utilisateurs rencontrent [symptôme] lorsque [il est déclenché ou entré]. Le comportement attendu est [résultat attendu]. Commencez par inspecter [le dossier, la fonction ou le flux] et les tests associés. Créez un test échouant qui reproduise le comportement signalé. Si vous ne parvenez pas à le reproduire, expliquez ce que vous avez vérifié et quelles informations manquent avant de modifier l’implémentation. Une fois le comportement reproduit, corrigez la cause sans modifier [le comportement qui doit rester inchangé]. Exécutez le nouveau test et [la commande de test associée]. Présentez l’échec avant la correction, les résultats après celle-ci, ainsi que tout échec persistant.

La [commande de compilation] échoue dans [l'environnement local ou CI] avec le message suivant : [journal d'erreurs anonymisé]. Inspectez le code et la configuration concernés pour identifier la cause. Vérifiez s'il existe des différences d'environnement ou de dépendances si l'échec ne se reproduit pas localement. Apportez la modification la plus minime possible permettant de remédier à la cause. Ne désactivez pas les vérifications, ne masquez pas les erreurs, ne sautez pas de tests et n’assouplissez pas les paramètres du compilateur dans le seul but d’obtenir une compilation réussie. Relancez la compilation après la modification. Si elle échoue toujours après [nombre] tentatives de correction, arrêtez-vous et signalez ce que vous avez essayé, l’erreur actuelle et l’étape de diagnostic suivante. Résumez la cause et incluez le résultat réel de la compilation.

Aidez-moi à cerner un bug avant de proposer une correction. Comportement observé : [ce qui se passe] Comportement attendu : [ce qui devrait se passer] Quand cela se produit : [conditions ou fréquence] Ce que j’ai essayé : [étapes et résultats] Posez une question à la fois, en choisissant celle qui permettrait le mieux de distinguer les causes probables. Ne répétez pas les questions auxquelles les informations fournies répondent déjà. Une fois que vous disposez de suffisamment d’éléments, résumez l’hypothèse la plus plausible, ce qui reste incertain et le test le plus simple qui permettrait de la confirmer ou de l’écarter. Les modifications en cours sur les fichiers ne doivent pas être effectuées.

Utilisez un sous-agent pour comparer [le diff ou la branche par rapport à la base] avec [le plan approuvé ou le fichier d'exigences]. Si des exigences manquent ou sont ambiguës, signalez-le avant d'évaluer l'exhaustivité. Vérifiez que chaque exigence est implémentée, que les cas limites pertinents font l’objet de tests et qu’aucune modification ne sort du périmètre convenu. Inspectez le code environnant si nécessaire pour comprendre le diff. Signalez les problèmes d’exactitude et les exigences non satisfaites en indiquant les références de fichier et de ligne, leur impact et les preuves étayant chaque constat. Distinguez les problèmes confirmés des questions non résolues. N’inventez pas de constats pour remplir un quota et n’incluez pas de préférences de style sans rapport. Ne modifiez pas les fichiers.

Examinez [les fichiers ou les différences] pour détecter les risques d’injection, les contrôles d’autorisation manquants, les secrets exposés et la gestion non sécurisée des entrées de l’utilisateur. Inspectez les appelants concernés et la logique de validation avant de signaler un problème. Pour chaque problème, identifiez le fichier et les lignes concernés, les conditions nécessaires pour le déclencher, l’impact probable et une solution suggérée. Faites la distinction entre une faille confirmée et un problème nécessitant des tests supplémentaires. Ne reproduisez pas les valeurs confidentielles dans les rapports, ne modifiez pas les fichiers et n’effectuez pas de tests sur des services en production. Précisez les domaines que vous avez examinés et ce qui reste hors du périmètre.

Résumez la manière dont vous avez vérifié la modification achevée par rapport aux [critères d’acceptation]. Pour chaque critère, indiquez la vérification effectuée, la commande exacte le cas échéant, et le résultat observé. Incluez les sorties pertinentes, en masquant les secrets et les données sensibles. Identifiez séparément les échecs préexistants. Distinguez clairement les vérifications réussies, celles qui ont échoué et celles qui n’ont pas été exécutées. Expliquez toute vérification ignorée ou toute limite de couverture. Ne présentez pas la modification dans son ensemble comme ayant été vérifiée si certains critères n’ont pas été vérifiés.

Refactorisez [fichier ou module] pour atteindre [un objectif spécifique, tel que le fractionnement d’une fonction volumineuse ou la suppression de callbacks imbriqués]. Préservez son interface publique, ses valeurs de retour, son comportement en cas d’erreur et ses effets secondaires. Exécutez [la commande de test appropriée] avant toute modification en cours afin d’établir une base de référence. En cas d’échec, signalez les échecs avant de poursuivre. Identifiez tout comportement non couvert par les tests existants et ajoutez des tests ciblés si nécessaire. Effectuez la refactorisation sans apporter de modifications non pertinentes ni créer de nouvelles dépendances. N’affaiblissez pas les assertions existantes pour vous adapter à l’implémentation. Relancez les tests et [commande de vérification de types ou de lint]. Présentez les résultats avant et après, résumez les changements structurels et signalez tout comportement que vous n’avez pas pu vérifier.

Recherchez les utilisations de [l'ancienne API ou bibliothèque] dans [la portée du répertoire], à l'exclusion des fichiers générés et fournis par des fournisseurs tiers. Dressez la liste des fichiers concernés ainsi que de toute configuration partagée ou dépendance susceptible d'être affectée par la migration. Proposez trois fichiers représentatifs pour une migration pilote vers [la nouvelle API ou version], en utilisant [le guide de migration ou un exemple existant]. Expliquez pourquoi vous les avez sélectionnés et signalez tout changement de comportement requis. Attendez mon accord avant de procéder à toute modification en cours. Une fois l’accord obtenu, ne migrez que les fichiers pilotes et les dépendances partagées explicitement approuvées. Exécutez les [tests pertinents] et la [commande de compilation ou de vérification de types]. N’étendez pas la migration à d’autres fichiers. Signalez les différences, les résultats des tests, les problèmes de compatibilité et toute modification nécessaire à l’approche de migration. Interrompez la procédure pour révision avant de poursuivre avec les fichiers restants.

Inspectez la branche actuelle, l'état Git et le diff pour [fonctionnalité ou correction]. Identifiez les fichiers concernés par cette modification et répertoriez séparément les fichiers non liés ou non suivis. Rédigez un message de commit en suivant le format des 10 derniers commits. Préparez une description de la demande de tirage précisant ce qui a changé, pourquoi, les tests effectivement exécutés et les éventuelles limitations restantes. Présentez la liste des fichiers proposés, le message de commit et la description de la demande de tirage avant de mettre quoi que ce soit en attente ou de publier quoi que ce soit. Attendez mon accord. Une fois l’accord obtenu, mettez en attente uniquement les fichiers convenus, effectuez un commit sur la [branche de fonctionnalité], effectuez un push vers [référentiel distant] et ouvrez une demande de tirage vers la [branche de base]. Ne modifiez pas les commits existants, n’effectuez pas de push forcé et ne fusionnez pas. Renvoyez le hachage du commit et le lien vers la demande de tirage.

Rédigez une section README pour [module] destinée à [un lecteur, tel qu’un ingénieur backend rejoignant le projet]. Abordez les prérequis, l’installation, les trois commandes qu’il utilisera le plus souvent, ainsi que les erreurs courantes prises en charge par le code ou la documentation existante. Vérifiez les noms de commandes et les options par rapport aux [scripts du paquet, au Makefile, à l’aide de l’interface CLI ou à la configuration CI]. Signalez tout élément que vous ne pouvez pas confirmer. Testez les commandes locales sans risque dans [l’environnement de test] lorsqu’il est disponible. Avant d’exécuter des commandes qui installent des dépendances, suppriment des fichiers, migrent des données, effectuent un déploiement ou accèdent à des services externes, expliquez leurs effets et demandez une validation. Distinguez clairement les commandes qui ont connu une réussite totale par rapport à la configuration ou à la documentation de celles qui ont uniquement été vérifiées par rapport à la configuration ou à la documentation. Présentez la section README proposée avant la modification en cours du chemin d’accès à la documentation, et conservez le contenu non pertinent.

Comparez [chemin d'accès vers CLAUDE.md] avec la structure, les scripts et les conventions actuels du référentiel. Ne modifiez pas encore le fichier. Identifiez les instructions obsolètes, les doublons, les contradictions et les règles pouvant être déduites de manière fiable à partir du code. Justifiez chaque suppression proposée plutôt que de supprimer des instructions uniquement pour raccourcir le fichier. Ne suggérez des commandes de compilation ou de test manquantes que si vous pouvez les vérifier dans les scripts du projet, un Makefile, la configuration CI ou la documentation existante. Citez la source de chaque ajout. Renvoyez un diff proposé qui préserve les contraintes importantes du projet. Signalez les instructions spécifiques à une tâche qui s’intégreraient mieux dans une règle de compétence ou de portée de chemin, et attendez la validation avant d’appliquer les modifications.

Proposez un hook de commande Claude Code qui exécute [commande de formateur existante] après des modifications de type « Edit » ou « Write » sur [modèles de fichiers]. Vérifiez d’abord les paramètres existants dans claude/settings.json et la configuration du formateur. Utilisez la configuration PostToolUse appropriée pour la version installée de Claude Code. Mettez en forme uniquement le fichier concerné, gérez les chemins d’accès en toute sécurité et excluez [les fichiers générés ou d’autres chemins d’accès exclus]. N’installez pas de dépendances et ne remplacez pas les hooks existants. Présentez le comparatif des paramètres proposés et expliquez comment les échecs du formateur seront signalés. Attendez la validation avant de l’appliquer. Une fois validé, testez-le avec un fichier temporaire dans le projet et communiquez le résultat. Précisez les chemins d’édition qu’il couvre et ceux qu’il ne couvre pas, y compris les modifications effectuées via des commandes shell.

Consultez la commande [outil] –help ainsi que l’aide relative aux sous-commandes pertinentes pour la [tâche]. N’installez pas l’outil s’il est manquant ; signalez plutôt ce prérequis. Proposez les commandes exactes nécessaires à l’achevement de la tâche. Expliquez leurs entrées, leurs sorties, et précisez si elles écrivent des fichiers, modifient des ressources distantes ou utilisent des identifiants. Incluez une option de simulation si l’outil en propose une. Signalez toute configuration ou permission manquante, et demandez des précisions plutôt que de deviner les noms de ressources ou les destinations. Attendez la validation avant d’exécuter les commandes de la tâche. Une fois la validation obtenue, n’exécutez que les commandes convenues et signalez leurs résultats réels, y compris les éventuelles erreurs ou étapes incomplètes.

Comparez [invoices.csv] et [paiements.csv] à l'aide de [l'identifiant de facture ou de la clé de correspondance]. Ne modifiez pas les fichiers sources. Appliquez ces règles : [devise et tolérance d’arrondi], [répartition des paiements partiels] et [traitement des remboursements, des crédits et des trop-perçus]. Si une règle manque ou si une correspondance est ambiguë, signalez-la plutôt que d’affecter automatiquement le paiement. Conservez les identifiants des lignes sources. Pour chaque facture, affichez le montant facturé, les paiements appliqués et le solde restant. Signalez les identifiants en double, les factures non appariées, les paiements non appariés et les soldes hors tolérance. Rapprochez séparément les totaux des factures et des paiements. Prenez en compte chaque ligne source sans double comptage ; si un paiement est réparti sur plusieurs factures, indiquez chaque affectation et vérifiez que les affectations ne dépassent pas le montant du paiement. Enregistrez les résultats dans [de nouveaux chemins de sortie] et résumez les exceptions nécessitant un examen.

Écrivez un script qui résume le fichier [export.csv] pour la période allant de [date de début et heure, incluses] à [date de fin et heure, non incluses], en utilisant le [fuseau horaire] et la [colonne de date]. Regroupez les enregistrements selon les [règles de catégorie] et calculez les [indicateurs requis]. Traitez les identifiants en double et les valeurs manquantes conformément aux [règles]. Ne modifiez pas le fichier d’entrée. Exécutez le script sur [le fichier d’entrée exact]. Indiquez le nombre de lignes incluses et exclues, les totaux par catégorie et les enregistrements qui n’ont pas pu être classés. Comparez les résultats pour [trois catégories] avec les décomptes vérifiés indépendamment dans [le fichier de référence]. Si ces décomptes ne sont pas disponibles, précisez que la validation indépendante reste en attente. Affichez les écarts et enregistrez le rapport dans [un nouveau chemin de sortie].

Lisez [les fichiers ou le dossier spécifiés] et rédigez un [type et longueur du document] destiné à [public cible], abordant [questions ou sujets]. Étayez chaque affirmation factuelle à l’aide d’un nom de fichier et d’une référence de page, de section ou de ligne, le cas échéant. Distinguez les citations directes des paraphrases, et ne considérez pas une proposition ou un document obsolète comme une décision actuelle confirmée. Signalez les sources contradictoires, les informations manquantes et les affirmations que vous ne pouvez pas vérifier. Ne comblez pas les lacunes par des suppositions et ne réalisez pas de modifications en cours sur les fichiers sources. Renvoyez le brouillon accompagné de ses références et d’une brève liste de questions en suspens à l’intention du relecteur.

Pour adapter un modèle, remplacez ses variables par les informations spécifiques à votre projet et déterminez ce que Claude doit faire avant d'effectuer les modifications. Suivez ces étapes pour préparer la requête et examiner le résultat.

Pour une modification mineure et bien définie, vous pouvez demander à Claude de la mettre en œuvre directement. Pour un code que vous ne connaissez pas, des modifications touchant plusieurs fichiers ou des exigences non résolues, commencez par établir un plan.

Appuyez sur Maj+Tab jusqu'à ce que le mode Plan s'affiche, ou lancez Claude Code avec la commande claude --permission-mode plan. Dans ce mode, Claude peut inspecter les fichiers et exécuter des commandes en lecture seule sans effectuer de modifications en cours sur votre code source. Vérifiez les fichiers, les dépendances et les tests proposés avant d'approuver la mise en œuvre. Appuyez sur Ctrl+G pour ouvrir le plan proposé dans votre éditeur.

Fournissez à Claude les éléments nécessaires à la compréhension de la tâche : une référence de fichier, un journal d'erreurs nettoyé, une capture d'écran ou un cahier des charges. Utilisez le symbole @ suivi du chemin d'accès au fichier pour inclure son contenu.

Choisissez l'ensemble de sources le plus petit possible. L'inclusion d'un journal ou d'un répertoire entier peut ajouter des éléments non pertinents et alourdir le contexte. Supprimez les identifiants et les données sensibles avant le partage de journaux, et vérifiez que Claude dispose des outils nécessaires pour récupérer les URL de documentation que vous fournissez.

Par exemple, la commande `cat error.log | claude -p "Explique cette erreur"` envoie un journal via une requête non interactive. Ne l'utilisez qu'après avoir vérifié le contenu du fichier. C'est là toute la valeur pratique de l'IA contextuelle: fournir au modèle des informations pertinentes pour la tâche à accomplir.

Lorsque vous ajoutez une fonctionnalité, identifiez un composant ou une fonction similaire dans le référentiel. Indiquez à Claude les conventions à respecter, telles que le client API, la logique de validation, la gestion des erreurs ou la structure des tests.

« Suivre la manière dont @src/widgets/Weather.tsx récupère et met en cache les données » fournit à Claude une référence concrète. Précisez également les différences requises par la nouvelle fonctionnalité afin qu’elle ne reprenne pas un comportement qui n’est plus adapté. Ces conventions doivent refléter le flux de travail de développement logiciel de votre équipe.

Pour les modifications de code, précisez la commande de test, de compilation ou de linting pertinente, ainsi que le comportement qu’elle doit vérifier. Pour la recherche, demandez des références de fichiers ou des identifiants de validation. Pour les travaux liés à l’interface utilisateur, fournissez une image de référence et une méthode configurée pour capturer la mise en œuvre dans la même fenêtre d’affichage.

Demandez à Claude de vous indiquer ce qu’il a réellement vérifié, y compris les échecs et les vérifications ignorées. Vérifiez si les preuves couvrent l’exigence ; une compilation réussie ne garantit pas que tous les comportements requis fonctionnent.

Pour les tâches plus longues, Claude Code propose également une condition /goal et des hooks « Stop ». L'évaluateur d'objectif analyse les éléments mis en évidence au cours de la discussion plutôt que d'inspecter les fichiers ou d'exécuter des tests de manière indépendante. Un hook « Stop » configuré peut bloquer l'achèvement, mais il existe des limites quant au nombre de blocages répétés. Aucun de ces deux éléments ne remplace des tests appropriés ni une révision humaine.

Si des corrections répétées ne permettent pas de résoudre un problème, faites une pause et identifiez ce qui n'était pas clair dans la demande initiale. Enregistrez les conclusions utiles, le statut actuel de Git et le travail restant avant d'effacer la discussion.

Le guide des bonnes pratiques d’Anthropic recommande de repartir de zéro après deux corrections infructueuses sur le même problème. Utilisez la commande /clear, puis fournissez une invitation révisée qui intègre ce que vous avez appris. Effacer la discussion n’annule pas les modifications apportées aux fichiers.

Appuyez sur Échap pour interrompre une réponse en cours d'exécution. Lorsque le champ de saisie de l'invite est vide, appuyez deux fois sur Échap pour ouvrir le menu de retour en arrière et choisir ce que vous souhaitez restaurer. Le retour en arrière n'annule pas tous les effets externes ; utilisez donc des points de contrôle Git et des procédures de restauration distinctes pour les modifications apportées aux bases de données ou aux services distants.

Enregistrez les consignes applicables à l'ensemble du projet dans CLAUDE.md, les procédures reproductibles dans les compétences et les instructions relatives à des fichiers spécifiques dans des règles liées à un chemin d'accès. Utilisez des hooks pour les actions liées à des évènements spécifiques, comme l'exécution d'un formateur après une modification en cours.

Faites votre choix en fonction du moment où l'instruction doit s'appliquer :

Une exigence relative à une fonctionnalité a généralement sa place dans la consigne de tâche ou le cahier des charges correspondant, plutôt que dans le fichier CLAUDE.md. L'ajout d'instructions temporaires dans un fichier applicable à l'ensemble du projet rend celles-ci plus difficiles à distinguer des conventions qui devraient s'appliquer à l'ensemble du référentiel.

Par exemple, conservez la commande de test du projet dans le fichier CLAUDE.md, placez les conventions spécifiques aux composants dans une règle de portée de chemin d’accès et enregistrez une procédure de révision récurrente sous forme de « skill ». Passez ces fichiers en revue lorsque les commandes ou les conventions changent, comme vous le feriez pour toute autre documentation du projet.

Les invites, le fichier CLAUDE.md et le guide des compétences orientent le comportement de Claude ; ils ne garantissent pas qu’une instruction sera suivie. Les hooks peuvent effectuer des vérifications lors d’évènements configurés, mais leur fiabilité dépend du type de hook et de son implémentation.

Un hook de commande exécute un script. Un hook de prompt ou d’agent repose sur le jugement d’un modèle. Comme l’explique le guide des bonnes pratiques d’Anthropic : « Un hook de prompt ou d’agent demande à un autre modèle de prendre une décision ; il n’est donc pas déterministe non plus. » Pour une règle qui doit être appliquée, utilisez des contrôles de permission appropriés et testez le hook de commande ou HTTP concerné, y compris la manière dont il gère les échecs.

Les sous-agents personnalisés constituent un autre moyen d'organiser les tâches récurrentes. Définissez un spécialiste dans le répertoire in.claude/agents/ lorsqu'un rôle de révision distinct ou un périmètre d'outils spécifique est nécessaire, plutôt que d'ajouter chaque instruction de spécialiste à la session principale. Ces guides sur le meilleur modèle Claude pour le travail et les types d'agents IA fournissent un contexte supplémentaire.

Si votre équipe gère des prompts pour plusieurs produits IA, découvrez ces outils d'ingénierie des prompts permettant de gérer des bibliothèques au-delà de Claude Code.

Lorsqu'une session produit un résultat incomplet ou inadapté, vérifiez si la requête a laissé des décisions importantes en suspens. Ces cinq erreurs peuvent compliquer le diagnostic et la révision du travail.

La commande « Examine le référentiel » ne donne à Claude que très peu d’indications sur les fichiers pertinents ou sur le moment où s’arrêter. Vous risquez d’obtenir un résumé général sans réponse au problème à l’origine de la requête.

Nommez le comportement ou la décision que vous devez comprendre, identifiez un emplacement de départ et définissez le résultat attendu. Par exemple : « Tracez la manière dont ce point de terminaison vérifie les permissions et citez les fonctions pertinentes. » Si vous utilisez des sous-agents, posez à chacun d’eux une question bien délimitée plutôt que de leur déléguer la même recherche sans restriction.

Passer d’une fonctionnalité à un bug sans rapport, puis à une demande de documentation, fait que la discussion conserve un contexte qui peut ne pas s’appliquer à la tâche en cours. Les références telles que « ce fichier » ou « l’approche précédente » deviennent alors ambiguës.

Utilisez des sessions distinctes pour les tâches sans rapport entre elles. Si plusieurs sessions doivent effectuer des modifications sur le référentiel, utilisez des arborescences Git distinctes afin qu’elles ne modifient pas le même répertoire de travail. Petite remarque en passant : la commande /btw de Claude Code permet de garder l’échange en dehors de l’historique principal de la discussion.

Une compilation peut réussir alors qu’une fonctionnalité ne se comporte pas correctement. Une suite de tests peut réussir simplement parce qu’elle n’a jamais testé l’entrée défaillante. Demander à Claude d’« exécuter les tests » ne permet pas de déterminer quelle exigence ces tests vérifient.

Plannez les critères d'acceptation avec des vérifications spécifiques. Pour la correction d'un bug, demandez la preuve que le test de reproduction a échoué avant la modification et qu'il a réussi après celle-ci. Gardez les critères non testés visibles plutôt que de considérer une commande réussie comme la validation de l'ensemble de la modification.

Un fichier CLAUDE.md en constante évolution peut contenir des commandes obsolètes, des règles en double et des instructions qui contredisent les exigences spécifiques à une tâche. Le simple fait de renforcer la formulation ne résout pas ces conflits.

Comparez le fichier avec le référentiel actuel. Supprimez les consignes obsolètes, clarifiez les règles contradictoires et transférez les instructions à portée restreinte vers des règles ou des compétences applicables à un chemin d'accès spécifique. Si une exigence doit être appliquée, configurez et testez les contrôles appropriés au lieu de vous contenter de rappels répétés.

Une révision peut mettre en évidence à la fois des défauts réels, des points d’incertitude et des suggestions de refactorisation facultatives. L’application de toutes les suggestions peut alourdir la modification sans pour autant améliorer le comportement recherché.

Demandez les preuves et l'impact derrière chaque constat. Donnez la priorité aux problèmes d'exactitude et aux exigences non satisfaites, examinez les affirmations incertaines et excluez les améliorations sans rapport du diff actuel. Un réviseur doit être capable de signaler l'absence de constatations donnant lieu à une action lorsque les preuves corroborent cette conclusion.

Pour adapter un modèle, remplacez ses espaces réservés par les informations spécifiques à votre projet et déterminez ce que Claude doit faire avant d'effectuer les modifications. Suivez ces étapes pour préparer la requête et examiner le résultat.

Pour une modification mineure et bien définie, vous pouvez demander à Claude de la mettre en œuvre directement. Pour un code que vous ne connaissez pas bien, des modifications touchant plusieurs fichiers ou des exigences non résolues, commencez par établir un plan.

Appuyez sur Maj+Tab jusqu'à ce que le mode Plan s'affiche, ou lancez Claude Code avec la commande claude --permission-mode plan. Dans ce mode, Claude peut inspecter les fichiers et exécuter des commandes en lecture seule sans effectuer de modifications en cours sur votre code source. Vérifiez les fichiers, les dépendances et les tests proposés avant d'approuver la mise en œuvre. Appuyez sur Ctrl+G pour ouvrir le plan proposé dans votre éditeur.

Fournissez à Claude les éléments nécessaires à la compréhension de la tâche : une référence de fichier, un journal d'erreurs nettoyé, une capture d'écran ou un cahier des charges. Utilisez le symbole @ suivi du chemin d'accès au fichier pour inclure son contenu.

Choisissez l'ensemble de sources le plus petit possible. L'inclusion d'un journal ou d'un répertoire entier peut ajouter des éléments non pertinents et alourdir le contexte. Supprimez les identifiants et les données sensibles avant de partager des journaux, et vérifiez que Claude dispose des outils nécessaires pour récupérer les URL de documentation que vous fournissez.

Par exemple, la commande `cat error.log | claude -p "Explique cette erreur"` envoie un journal via une requête non interactive. Ne l'utilisez qu'après avoir vérifié le contenu du fichier. C'est là toute la valeur pratique de l'IA contextuelle: fournir au modèle des informations pertinentes pour la tâche à accomplir.

Lorsque vous ajoutez une fonctionnalité, identifiez un composant ou une fonction similaire dans le référentiel. Indiquez à Claude les conventions à respecter, telles que le client API, la logique de validation, la gestion des erreurs ou la structure des tests.

« Suivre la manière dont @src/widgets/Weather.tsx récupère et met en cache les données » fournit à Claude une référence concrète. Précisez également les différences requises par la nouvelle fonctionnalité afin qu’elle ne reprenne pas un comportement qui n’est plus adapté. Ces conventions doivent refléter le flux de travail de développement logiciel de votre équipe.

Pour les modifications de code, précisez la commande de test, de compilation ou de linting pertinente, ainsi que le comportement qu’elle doit vérifier. Pour la recherche, demandez des références de fichiers ou des identifiants de validation. Pour le travail lié à l’interface utilisateur, fournissez une image de référence et une méthode configurée pour capturer la mise en œuvre dans la même fenêtre d’affichage.

Demandez à Claude de vous indiquer ce qu’il a réellement vérifié, y compris les échecs et les vérifications ignorées. Vérifiez si les preuves couvrent l’exigence ; une compilation réussie ne garantit pas que tous les comportements requis fonctionnent.

Pour les tâches plus longues, Claude Code propose également une condition /goal et des hooks « Stop ». L'évaluateur d'objectif analyse les éléments mis en évidence au cours de la discussion plutôt que d'inspecter les fichiers ou d'exécuter des tests de manière indépendante. Un hook « Stop » configuré peut bloquer la finalisation, mais il existe des limites quant au nombre de blocages répétés. Aucun de ces deux éléments ne remplace des tests appropriés ni une révision humaine.

Si des corrections répétées ne permettent pas de résoudre un problème, faites une pause et identifiez ce qui n'était pas clair dans la demande initiale. Enregistrez les conclusions utiles, le statut actuel de Git et le travail restant avant d'effacer la discussion.

Le guide des bonnes pratiques d’Anthropic recommande de repartir de zéro après deux corrections infructueuses sur le même problème. Utilisez la commande /clear, puis fournissez une consigne révisée qui intègre ce que vous avez appris. La suppression de l’historique de la discussion n’annule pas les modifications apportées aux fichiers.

Appuyez sur Échap pour interrompre une réponse en cours d'exécution. Lorsque le champ de saisie de l'invite est vide, appuyez deux fois sur Échap pour ouvrir le menu de retour en arrière et choisir ce que vous souhaitez restaurer. Le retour en arrière n'annule pas tous les effets externes ; utilisez donc des points de contrôle Git et des procédures de restauration distinctes pour les modifications apportées aux bases de données ou aux services distants.

Enregistrez les consignes applicables à l'ensemble du projet dans CLAUDE.md, les procédures reproductibles dans les compétences et les instructions relatives à des fichiers spécifiques dans des règles liées à un chemin d'accès. Utilisez des hooks pour les actions liées à des évènements spécifiques, comme l'exécution d'un formateur après une modification en cours.

Faites votre choix en fonction du moment où l'instruction doit s'appliquer :

Une exigence relative à une fonctionnalité a généralement sa place dans la consigne de tâche ou le cahier des charges correspondant, plutôt que dans le fichier CLAUDE.md. L'ajout d'instructions temporaires dans un fichier applicable à l'ensemble du projet rend celles-ci plus difficiles à distinguer des conventions qui devraient s'appliquer à l'ensemble du référentiel.

Par exemple, conservez la commande de test du projet dans le fichier CLAUDE.md, placez les conventions spécifiques aux composants dans une règle de portée de chemin d’accès et enregistrez une procédure de révision récurrente sous forme de « skill ». Consultez ces fichiers lorsque les commandes ou les conventions changent, comme vous le feriez pour toute autre documentation du projet.

Les invites, le fichier CLAUDE.md et le guide des compétences orientent le comportement de Claude ; ils ne garantissent pas qu’une instruction sera suivie. Les hooks peuvent effectuer des vérifications lors d’évènements configurés, mais leur fiabilité dépend du type de hook et de son implémentation.

Un hook de commande exécute un script. Un hook de prompt ou d’agent repose sur le jugement d’un modèle. Comme l’explique le guide des bonnes pratiques d’Anthropic : « Un hook de prompt ou d’agent demande à un autre modèle de prendre une décision ; il n’est donc pas déterministe non plus. » Pour une règle qui doit être appliquée, utilisez des contrôles de permission appropriés et testez le hook de commande ou HTTP concerné, y compris la manière dont il gère les échecs.

Les sous-agents personnalisés constituent un autre moyen d'organiser les tâches récurrentes. Définissez un spécialiste dans le répertoire in.claude/agents/ lorsqu'un rôle de révision distinct ou un périmètre d'outils spécifique est nécessaire, plutôt que d'ajouter chaque instruction de spécialiste à la session principale. Ces guides sur le meilleur modèle Claude pour le travail et les types d'agents IA fournissent un contexte supplémentaire.

Si votre équipe gère des invites pour plusieurs produits IA, découvrez ces outils d'ingénierie des invites permettant de gérer des bibliothèques au-delà de Claude Code.

Lorsqu’une session produit un résultat incomplet ou inadapté, vérifiez si la requête a laissé des décisions importantes en suspens. Ces cinq erreurs peuvent compliquer le diagnostic et la révision du travail.

La commande « Examine le référentiel » ne donne que très peu d’indications à Claude sur les fichiers pertinents ou le moment où s’arrêter. Vous risquez d’obtenir un résumé général sans réponse au problème à l’origine de la requête.

Nommez le comportement ou la décision que vous devez comprendre, identifiez un emplacement de départ et définissez le résultat attendu. Par exemple : « Tracez la manière dont ce point de terminaison vérifie les permissions et citez les fonctions pertinentes. » Si vous utilisez des sous-agents, posez à chacun d’eux une question bien délimitée plutôt que de leur déléguer la même recherche sans restriction.

Passer d’une fonctionnalité à un bug sans rapport, puis à une demande de documentation, fait que la discussion conserve un contexte qui peut ne pas s’appliquer à la tâche en cours. Les références telles que « ce fichier » ou « l’approche précédente » deviennent alors ambiguës.

Utilisez des sessions distinctes pour les tâches sans rapport entre elles. Si plusieurs sessions doivent effectuer des modifications sur le référentiel, utilisez des arborescences Git distinctes afin qu’elles ne modifient pas le même répertoire de travail. Petite remarque en passant : la commande /btw de Claude Code permet de garder l’échange en dehors de l’historique principal de la discussion.

Une compilation peut réussir alors qu’une fonctionnalité ne se comporte pas correctement. Une suite de tests peut réussir simplement parce qu’elle n’a jamais testé l’entrée défaillante. Demander à Claude d’« exécuter les tests » ne permet pas de déterminer quelle exigence ces tests vérifient.

Plannez les critères d'acceptation avec des vérifications spécifiques. Pour la correction d'un bug, demandez la preuve que le test de reproduction a échoué avant la modification et qu'il a réussi après celle-ci. Gardez les critères non testés en vue plutôt que de considérer une commande réussie comme la validation de l'ensemble de la modification.

Un fichier CLAUDE.md en constante évolution peut contenir des commandes obsolètes, des règles en double et des instructions qui contredisent les exigences spécifiques à une tâche. Le simple fait de renforcer la formulation ne résout pas ces conflits.

Comparez le fichier avec le référentiel actuel. Supprimez les consignes obsolètes, clarifiez les règles contradictoires et transférez les instructions à portée restreinte vers des règles ou des compétences applicables à un chemin d'accès spécifique. Si une exigence doit être appliquée, configurez et testez les contrôles appropriés au lieu de vous contenter de rappels répétés.

Une révision peut mettre en évidence à la fois des défauts réels, des points d’incertitude et des suggestions de refactorisation facultatives. L’application de toutes les suggestions peut alourdir la modification sans pour autant améliorer le comportement recherché.

Demandez les preuves et l'impact derrière chaque constat. Donnez la priorité aux problèmes d'exactitude et aux exigences non satisfaites, examinez les affirmations incertaines et excluez les améliorations sans rapport du diff actuel. Un réviseur doit être capable de signaler l'absence de constatations donnant lieu à une action lorsque les preuves appuient cette conclusion.

Pour adapter un modèle, remplacez ses variables par les informations spécifiques à votre projet et déterminez ce que Claude doit faire avant d'effectuer les modifications. Suivez ces étapes pour préparer la requête et examiner le résultat.

Pour une modification mineure et bien définie, vous pouvez demander à Claude de la mettre en œuvre directement. Pour un code que vous ne connaissez pas bien, des modifications touchant plusieurs fichiers ou des exigences non résolues, commencez par établir un plan.

Appuyez sur Maj+Tab jusqu'à ce que le mode Plan s'affiche, ou lancez Claude Code avec la commande claude --permission-mode plan. Dans ce mode, Claude peut inspecter les fichiers et exécuter des commandes en lecture seule sans effectuer de modifications en cours sur votre code source. Vérifiez les fichiers, les dépendances et les tests proposés avant d'approuver la mise en œuvre. Appuyez sur Ctrl+G pour ouvrir le plan proposé dans votre éditeur.

Fournissez à Claude les éléments nécessaires à la compréhension de la tâche : une référence de fichier, un journal d'erreurs nettoyé, une capture d'écran ou un cahier des charges. Utilisez le symbole @ suivi du chemin d'accès au fichier pour inclure son contenu.

Choisissez l'ensemble de sources le plus petit possible. L'inclusion d'un journal ou d'un répertoire entier peut ajouter des éléments non pertinents et alourdir le contexte. Supprimez les identifiants et les données sensibles avant le partage de journaux, et vérifiez que Claude dispose des outils nécessaires pour récupérer les URL de documentation que vous fournissez.

Par exemple, la commande `cat error.log | claude -p "Explique cette erreur"` envoie un journal via une requête non interactive. Ne l'utilisez qu'après avoir vérifié le contenu du fichier. C'est là tout l'intérêt pratique de l'IA contextuelle: fournir au modèle des informations pertinentes pour la tâche à accomplir.

Lorsque vous ajoutez une fonctionnalité, identifiez un composant ou une fonction similaire dans le référentiel. Indiquez à Claude les conventions à respecter, telles que le client API, la logique de validation, la gestion des erreurs ou la structure des tests.

« Suivre la manière dont @src/widgets/Weather.tsx récupère et met en cache les données » fournit à Claude une référence concrète. Précisez également les différences requises par la nouvelle fonctionnalité afin qu’elle ne reproduise pas un comportement qui n’est plus adapté. Ces conventions doivent refléter le flux de travail de développement logiciel de votre équipe.

Pour les modifications de code, précisez la commande de test, de compilation ou de linting pertinente, ainsi que le comportement qu’elle doit vérifier. Pour la recherche, demandez des références de fichiers ou des identifiants de validation. Pour le travail sur l’interface utilisateur, fournissez une image de référence et une méthode configurée pour capturer la mise en œuvre dans la même fenêtre d’affichage.

Demandez à Claude de vous indiquer ce qu’il a réellement vérifié, y compris les échecs et les vérifications ignorées. Vérifiez si les preuves couvrent l’exigence ; une compilation réussie ne garantit pas que tous les comportements requis fonctionnent.

Pour les tâches plus longues, Claude Code propose également une condition /goal et des hooks « Stop ». L'évaluateur d'objectif analyse les éléments mis en évidence au cours de la discussion plutôt que d'inspecter les fichiers ou d'exécuter des tests de manière indépendante. Un hook « Stop » configuré peut bloquer la finalisation, mais il existe des limites quant au nombre de blocages répétés. Aucun de ces deux éléments ne remplace des tests appropriés ni une révision humaine.

Si des corrections répétées ne permettent pas de résoudre un problème, faites une pause et identifiez ce qui n'était pas clair dans la demande initiale. Enregistrez les conclusions utiles, le statut actuel de Git et le travail restant avant d'effacer la discussion.

Le guide des bonnes pratiques d’Anthropic recommande de repartir de zéro après deux corrections infructueuses sur le même problème. Utilisez la commande /clear, puis fournissez une invite révisée qui intègre ce que vous avez appris. La suppression de l’historique de la discussion n’annule pas les modifications apportées aux fichiers.

Appuyez sur Échap pour interrompre une réponse en cours d'exécution. Lorsque le champ de saisie de l'invite est vide, appuyez deux fois sur Échap pour ouvrir le menu de retour en arrière et choisir ce que vous souhaitez restaurer. Le retour en arrière n'annule pas tous les effets externes ; utilisez donc les points de contrôle Git et des procédures de restauration distinctes pour les modifications apportées aux bases de données ou aux services distants.

Enregistrez les consignes applicables à l'ensemble du projet dans CLAUDE.md, les procédures reproductibles dans les compétences et les instructions relatives à des fichiers spécifiques dans des règles liées à un chemin d'accès. Utilisez des hooks pour les actions liées à des évènements spécifiques, comme l'exécution d'un formateur après une modification en cours.

Faites votre choix en fonction du moment où l'instruction doit s'appliquer :

Une exigence relative à une fonctionnalité a généralement sa place dans la consigne de tâche ou le cahier des charges correspondant, plutôt que dans le fichier CLAUDE.md. L'ajout d'instructions temporaires dans un fichier applicable à l'ensemble du projet rend celles-ci plus difficiles à distinguer des conventions qui devraient s'appliquer à l'ensemble du référentiel.

Par exemple, conservez la commande de test du projet dans le fichier CLAUDE.md, placez les conventions spécifiques aux composants dans une règle de portée de chemin d’accès et enregistrez une procédure de révision récurrente sous forme de « skill ». Passez ces fichiers en revue lorsque les commandes ou les conventions changent, comme vous le feriez pour toute autre documentation du projet.

Les invites, le fichier CLAUDE.md et le guide des compétences orientent le comportement de Claude ; ils ne garantissent pas qu’une instruction sera suivie. Les hooks peuvent effectuer des vérifications lors d’évènements configurés, mais leur fiabilité dépend du type de hook et de son implémentation.

Un hook de commande exécute un script. Un hook de prompt ou d’agent repose sur le jugement d’un modèle. Comme l’explique le guide des bonnes pratiques d’Anthropic : « Un hook de prompt ou d’agent demande à un autre modèle de prendre une décision ; il n’est donc pas déterministe non plus. » Pour une règle qui doit être appliquée, utilisez des contrôles de permission appropriés et testez le hook de commande ou HTTP concerné, y compris la manière dont il gère les échecs.

Les sous-agents personnalisés constituent un autre moyen d'organiser les tâches récurrentes. Définissez un spécialiste dans le répertoire in.claude/agents/ lorsqu'un rôle de révision distinct ou un périmètre d'outils spécifique est nécessaire, plutôt que d'ajouter chaque instruction de spécialiste à la session principale. Ces guides sur le meilleur modèle Claude pour le travail et les types d'agents IA fournissent un contexte supplémentaire.

Si votre équipe gère des prompts pour plusieurs produits d'IA, découvrez ces outils d'ingénierie des prompts permettant de gérer des bibliothèques au-delà de Claude Code.

Lorsqu’une session produit un résultat incomplet ou inadapté, vérifiez si la requête a laissé des décisions importantes en suspens. Ces cinq erreurs peuvent compliquer le diagnostic et la révision du travail.

La commande « Examine le référentiel » ne donne à Claude que très peu d’indications sur les fichiers pertinents ou sur le moment où s’arrêter. Vous risquez d’obtenir un résumé général sans réponse au problème à l’origine de la requête.

Nommez le comportement ou la décision que vous devez comprendre, identifiez un emplacement de départ et définissez le résultat attendu. Par exemple : « Tracez la manière dont ce point de terminaison vérifie les permissions et citez les fonctions pertinentes. » Si vous utilisez des sous-agents, posez à chacun d’eux une question bien délimitée plutôt que de leur déléguer la même recherche sans restriction.

Passer d’une fonctionnalité à un bug sans rapport, puis à une demande de documentation, fait que la discussion conserve un contexte qui peut ne pas s’appliquer à la tâche en cours. Les références telles que « ce fichier » ou « l’approche précédente » deviennent alors ambiguës.

Utilisez des sessions distinctes pour les tâches sans rapport entre elles. Si plusieurs sessions doivent effectuer des modifications sur le référentiel, utilisez des arborescences Git distinctes afin qu’elles ne modifient pas le même répertoire de travail. Petite remarque en passant : la commande /btw de Claude Code permet de garder l’échange en dehors de l’historique principal de la discussion.

Une compilation peut réussir alors qu’une fonctionnalité ne se comporte pas correctement. Une suite de tests peut réussir simplement parce qu’elle n’a jamais testé l’entrée défaillante. Demander à Claude d’« exécuter les tests » ne permet pas de déterminer quelle exigence ces tests vérifient.

Mappez les critères d'acceptation avec des vérifications spécifiques. Pour la correction d'un bug, demandez la preuve que le test de reproduction a échoué avant la modification et qu'il a réussi après celle-ci. Gardez les critères non testés visibles plutôt que de considérer une commande réussie comme la vérification de l'ensemble de la modification.

Un fichier CLAUDE.md en constante évolution peut contenir des commandes obsolètes, des règles en double et des instructions qui contredisent les exigences spécifiques à une tâche. Le simple fait de renforcer la formulation ne résout pas ces conflits.

Comparez le fichier avec le référentiel actuel. Supprimez les consignes obsolètes, clarifiez les règles contradictoires et transférez les instructions à portée restreinte vers des règles ou des compétences applicables à un chemin d'accès spécifique. Si une exigence doit être appliquée, configurez et testez les contrôles appropriés au lieu de vous contenter de rappels répétés.

Une révision peut mettre en évidence à la fois des défauts réels, des points d'incertitude et des suggestions de refactorisation facultatives. L'application de toutes les suggestions peut alourdir la modification sans pour autant améliorer le comportement recherché.

Demandez les preuves et l'impact derrière chaque constat. Donnez la priorité aux problèmes d'exactitude et aux exigences non satisfaites, examinez les affirmations incertaines et excluez les améliorations sans rapport du diff actuel. Un réviseur doit être capable de signaler l'absence de constatations donnant lieu à une action lorsque les preuves corroborent cette conclusion.

Pour adapter un modèle, remplacez ses variables par les informations spécifiques à votre projet et déterminez ce que Claude doit faire avant d'effectuer les modifications. Suivez ces étapes pour préparer la requête et examiner le résultat.

Pour une modification mineure et bien définie, vous pouvez demander à Claude de la mettre en œuvre directement. Pour un code que vous ne connaissez pas bien, des modifications touchant plusieurs fichiers ou des exigences non résolues, commencez par établir un plan.

Appuyez sur Maj+Tab jusqu'à ce que le mode Plan s'affiche, ou lancez Claude Code avec la commande claude --permission-mode plan. Dans ce mode, Claude peut inspecter les fichiers et exécuter des commandes en lecture seule sans effectuer de modification en cours sur votre code source. Vérifiez les fichiers, les dépendances et les tests proposés avant d'approuver la mise en œuvre. Appuyez sur Ctrl+G pour ouvrir le plan proposé dans votre éditeur.

Fournissez à Claude les éléments nécessaires à la compréhension de la tâche : une référence de fichier, un journal d'erreurs nettoyé, une capture d'écran ou un cahier des charges. Utilisez le symbole @ suivi du chemin d'accès au fichier pour inclure son contenu.

Choisissez l'ensemble de sources le plus petit possible. L'inclusion d'un journal ou d'un répertoire entier peut ajouter des éléments non pertinents et alourdir le contexte. Supprimez les identifiants et les données sensibles avant le partage de journaux, et vérifiez que Claude dispose des outils nécessaires pour récupérer les URL de documentation que vous fournissez.

Par exemple, la commande `cat error.log | claude -p "Explique cette erreur"` envoie un journal via une requête non interactive. Ne l'utilisez qu'après avoir vérifié le contenu du fichier. C'est là toute la valeur pratique de l'IA contextuelle: fournir au modèle des informations pertinentes pour la tâche à accomplir.

Lorsque vous ajoutez une fonctionnalité, identifiez un composant ou une fonction similaire dans le référentiel. Indiquez à Claude les conventions à respecter, telles que le client API, la logique de validation, la gestion des erreurs ou la structure des tests.

« Suivre la manière dont @src/widgets/Weather.tsx récupère et met en cache les données » fournit à Claude une référence concrète. Précisez également les différences requises par la nouvelle fonctionnalité afin qu’elle ne reprenne pas un comportement qui n’est plus adapté. Ces conventions doivent refléter le flux de travail de développement logiciel de votre équipe.

Pour les modifications de code, précisez la commande de test, de compilation ou de linting pertinente, ainsi que le comportement qu’elle doit vérifier. Pour la recherche, demandez des références de fichiers ou des identifiants de validation. Pour le travail lié à l’interface utilisateur, fournissez une image de référence et une méthode configurée pour capturer la mise en œuvre dans la même fenêtre d’affichage.

Demandez à Claude de vous indiquer ce qu’il a réellement vérifié, y compris les échecs et les vérifications ignorées. Vérifiez si les preuves couvrent l’exigence ; une compilation réussie ne garantit pas que tous les comportements requis fonctionnent.

Pour les tâches plus longues, Claude Code propose également une condition /goal et des hooks « Stop ». L'évaluateur d'objectif analyse les éléments mis en évidence au cours de la discussion plutôt que d'inspecter les fichiers ou d'exécuter des tests de manière indépendante. Un hook « Stop » configuré peut bloquer l'achèvement, mais il existe des limites quant au nombre de blocages répétés. Aucun de ces deux éléments ne remplace des tests appropriés ni une révision humaine.

Si des corrections répétées ne permettent pas de résoudre un problème, faites une pause et identifiez ce qui n'était pas clair dans la demande initiale. Enregistrez les conclusions utiles, le statut actuel de Git et le travail restant avant d'effacer la discussion.

Le guide des bonnes pratiques d’Anthropic recommande de repartir de zéro après deux corrections infructueuses sur le même problème. Utilisez la commande /clear, puis fournissez une invite révisée qui intègre ce que vous avez appris. La suppression de l’historique de la discussion n’annule pas les modifications apportées aux fichiers.

Appuyez sur Échap pour interrompre une réponse en cours d'exécution. Lorsque le champ de saisie de l'invite est vide, appuyez deux fois sur Échap pour ouvrir le menu de retour en arrière et choisir ce que vous souhaitez restaurer. Le retour en arrière n'annule pas tous les effets externes ; utilisez donc des points de contrôle Git et des procédures de restauration distinctes pour les modifications apportées aux bases de données ou aux services distants.

Enregistrez les consignes applicables à l'ensemble du projet dans CLAUDE.md, les procédures reproductibles dans les compétences et les instructions relatives à des fichiers spécifiques dans des règles liées à un chemin d'accès. Utilisez des hooks pour les actions liées à des évènements spécifiques, comme l'exécution d'un formateur après une modification en cours.

Faites votre choix en fonction du moment où l'instruction doit s'appliquer :

Une exigence relative à une fonctionnalité a généralement sa place dans la consigne de tâche ou le cahier des charges correspondant, plutôt que dans le fichier CLAUDE.md. L'ajout d'instructions temporaires dans un fichier applicable à l'ensemble du projet rend celles-ci plus difficiles à distinguer des conventions qui devraient s'appliquer à l'ensemble du référentiel.

Par exemple, conservez la commande de test du projet dans le fichier CLAUDE.md, placez les conventions spécifiques aux composants dans une règle de portée de chemin d’accès et enregistrez une procédure de révision récurrente sous forme de « skill ». Passez ces fichiers en revue lorsque les commandes ou les conventions changent, comme vous le feriez pour toute autre documentation du projet.

Les invites, le fichier CLAUDE.md et le guide des compétences orientent le comportement de Claude ; ils ne garantissent pas qu’une instruction sera suivie. Les hooks peuvent effectuer des vérifications lors d’évènements configurés, mais leur fiabilité dépend du type de hook et de son implémentation.

Un hook de commande exécute un script. Un hook de prompt ou d’agent repose sur le jugement d’un modèle. Comme l’explique le guide des bonnes pratiques d’Anthropic : « Un hook de prompt ou d’agent demande à un autre modèle de prendre une décision ; il n’est donc pas déterministe non plus. » Pour une règle qui doit être appliquée, utilisez des contrôles de permission appropriés et testez le hook de commande ou HTTP concerné, y compris la manière dont il gère les échecs.

Les sous-agents personnalisés constituent un autre moyen d'organiser les tâches récurrentes. Définissez un spécialiste dans le répertoire in.claude/agents/ lorsqu'un rôle de révision distinct ou un périmètre d'outils spécifique est nécessaire, plutôt que d'ajouter chaque instruction de spécialiste à la session principale. Ces guides sur le meilleur modèle Claude pour le travail et les types d'agents IA fournissent un contexte supplémentaire.

Si votre équipe gère des prompts pour plusieurs produits d'IA, découvrez ces outils d'ingénierie des prompts permettant de gérer des bibliothèques au-delà de Claude Code.

Lorsqu’une session produit un résultat incomplet ou inadapté, vérifiez si la requête a laissé des décisions importantes en suspens. Ces cinq erreurs peuvent compliquer le diagnostic et la révision du travail.

La commande « Examine le référentiel » ne donne à Claude que très peu d’indications sur les fichiers pertinents ou sur le moment où s’arrêter. Vous risquez d’obtenir un résumé général sans réponse au problème à l’origine de la requête.

Nommez le comportement ou la décision que vous devez comprendre, identifiez un emplacement et définissez le résultat attendu. Par exemple : « Tracez la manière dont ce point de terminaison vérifie les permissions et citez les fonctions pertinentes. » Si vous utilisez des sous-agents, posez à chacun d’eux une question bien délimitée plutôt que de leur déléguer la même recherche sans restriction.

Passer d’une fonctionnalité à un bug sans rapport, puis à une demande de documentation, fait que la discussion conserve un contexte qui peut ne pas s’appliquer à la tâche en cours. Les références telles que « ce fichier » ou « l’approche précédente » deviennent alors ambiguës.

Utilisez des sessions distinctes pour les tâches sans rapport entre elles. Si plusieurs sessions doivent effectuer des modifications sur le référentiel, utilisez des arborescences Git distinctes afin qu’elles ne modifient pas le même répertoire de travail. Petite remarque en passant : la commande /btw de Claude Code permet de garder l’échange en dehors de l’historique principal de la discussion.

Une compilation peut réussir alors qu’une fonctionnalité ne se comporte pas correctement. Une suite de tests peut réussir parce qu’elle n’a jamais testé l’entrée défaillante. Demander à Claude d’« exécuter les tests » ne permet pas de déterminer quelle exigence ces tests vérifient.

Plannez les critères d'acceptation avec des vérifications spécifiques. Pour la correction d'un bug, demandez la preuve que le test de reproduction a échoué avant la modification et qu'il a réussi après celle-ci. Gardez les critères non testés visibles plutôt que de considérer une commande réussie comme la vérification de l'ensemble de la modification.

Un fichier CLAUDE.md en constante évolution peut contenir des commandes obsolètes, des règles en double et des instructions qui contredisent les exigences spécifiques à une tâche. Le simple fait de renforcer la formulation ne résout pas ces conflits.

Comparez le fichier avec le référentiel actuel. Supprimez les consignes obsolètes, clarifiez les règles contradictoires et transférez les instructions à portée restreinte vers des règles ou des compétences applicables à un chemin d'accès spécifique. Si une exigence doit être appliquée, configurez et testez les contrôles appropriés au lieu de vous contenter de rappels répétés.

Une révision peut mettre en évidence à la fois des défauts réels, des points d'incertitude et des suggestions de refactorisation facultatives. L'application de toutes les suggestions peut alourdir la modification sans pour autant améliorer le comportement recherché.

Demandez les preuves et l'impact derrière chaque constat. Donnez la priorité aux problèmes d'exactitude et aux exigences non satisfaites, examinez les affirmations incertaines et excluez les améliorations sans rapport du diff actuel. Un réviseur doit être capable de signaler l'absence de constatations donnant lieu à une action lorsque les preuves corroborent cette conclusion.

Pour adapter un modèle, remplacez ses espaces réservés par les informations spécifiques à votre projet et déterminez ce que Claude doit faire avant d'effectuer les modifications. Suivez ces étapes pour préparer la requête et examiner le résultat.

Pour une modification mineure et bien définie, vous pouvez demander à Claude de la mettre en œuvre directement. Pour un code que vous ne connaissez pas bien, des modifications touchant plusieurs fichiers ou des exigences non résolues, commencez par établir un plan.

Appuyez sur Maj+Tab jusqu'à ce que le mode Plan s'affiche, ou lancez Claude Code avec la commande claude --permission-mode plan. Dans ce mode, Claude peut inspecter les fichiers et exécuter des commandes en lecture seule sans effectuer de modifications sur votre code source. Vérifiez les fichiers, les dépendances et les tests proposés avant d'approuver la mise en œuvre. Appuyez sur Ctrl+G pour ouvrir le plan proposé dans votre éditeur.

Fournissez à Claude les éléments nécessaires à la compréhension de la tâche : une référence de fichier, un journal d'erreurs nettoyé, une capture d'écran ou un cahier des charges. Utilisez le symbole @ suivi du chemin d'accès au fichier pour inclure son contenu.

Choisissez l'ensemble de sources le plus petit possible. L'inclusion d'un journal ou d'un répertoire entier peut ajouter des éléments non pertinents et alourdir le contexte. Supprimez les identifiants et les données sensibles avant le partage de journaux, et vérifiez que Claude dispose des outils nécessaires pour récupérer les URL de documentation que vous fournissez.

Par exemple, la commande `cat error.log | claude -p "Explique cette erreur"` envoie un journal via une requête non interactive. Ne l'utilisez qu'après avoir vérifié le contenu du fichier. C'est là toute la valeur pratique de l'IA contextuelle: fournir au modèle des informations pertinentes pour la tâche à accomplir.

Lorsque vous ajoutez une fonctionnalité, identifiez un composant ou une fonction similaire dans le référentiel. Indiquez à Claude les conventions à respecter, telles que le client API, la logique de validation, la gestion des erreurs ou la structure des tests.

« Suivre la manière dont @src/widgets/Weather.tsx récupère et met en cache les données » fournit à Claude une référence concrète. Indiquez également les différences requises par la nouvelle fonctionnalité afin qu’elle ne reproduise pas un comportement qui n’est plus adapté. Ces conventions doivent refléter le flux de travail de développement logiciel de votre équipe.

Pour les modifications de code, précisez la commande de test, de compilation ou de linting pertinente, ainsi que le comportement qu’elle doit vérifier. Pour la recherche, demandez des références de fichiers ou des identifiants de validation. Pour les travaux liés à l’interface utilisateur, fournissez une image de référence et une méthode configurée pour capturer la mise en œuvre dans la même fenêtre d’affichage.

Demandez à Claude de vous indiquer ce qu’il a réellement vérifié, y compris les échecs et les vérifications ignorées. Vérifiez si les preuves couvrent l’exigence ; une compilation réussie ne garantit pas que tous les comportements requis fonctionnent.

Pour les tâches plus longues, Claude Code propose également une condition /goal et des hooks « Stop ». L'évaluateur d'objectif analyse les éléments mis en évidence au cours de la discussion plutôt que d'inspecter les fichiers ou d'exécuter des tests de manière indépendante. Un hook « Stop » configuré peut bloquer l'achevement, mais il existe des limites quant au nombre de blocages répétés. Aucun de ces deux éléments ne remplace des tests appropriés ni une révision humaine.

Si des corrections répétées ne permettent pas de résoudre un problème, faites une pause et identifiez ce qui n'était pas clair dans la demande initiale. Enregistrez les conclusions utiles, le statut actuel de Git et le travail restant avant d'effacer la discussion.

Le guide des bonnes pratiques d’Anthropic recommande de repartir de zéro après deux corrections infructueuses sur le même problème. Utilisez la commande /clear, puis fournissez une invitation révisée qui intègre ce que vous avez appris. Effacer la discussion n’annule pas les modifications apportées aux fichiers.

Appuyez sur Échap pour interrompre une réponse en cours d'exécution. Lorsque le champ de saisie de l'invite est vide, appuyez deux fois sur Échap pour ouvrir le menu de retour en arrière et choisir ce que vous souhaitez restaurer. Le retour en arrière n'annule pas tous les effets externes ; utilisez donc des points de contrôle Git et des procédures de restauration distinctes pour les modifications apportées aux bases de données ou aux services distants.

Enregistrez les consignes applicables à l'ensemble du projet dans CLAUDE.md, les procédures reproductibles dans les compétences et les instructions relatives à des fichiers spécifiques dans des règles liées à un chemin d'accès. Utilisez des hooks pour les actions liées à des évènements spécifiques, comme l'exécution d'un formateur après une modification en cours.

Faites votre choix en fonction du moment où l'instruction doit s'appliquer :

Une exigence relative à une fonctionnalité a généralement sa place dans la consigne de tâche ou le cahier des charges correspondant, plutôt que dans le fichier CLAUDE.md. L'ajout d'instructions temporaires dans un fichier applicable à l'ensemble du projet rend celles-ci plus difficiles à distinguer des conventions qui devraient s'appliquer à l'ensemble du référentiel.

Par exemple, conservez la commande de test du projet dans le fichier CLAUDE.md, placez les conventions spécifiques aux composants dans une règle de portée de chemin d’accès et enregistrez une procédure de révision récurrente sous forme de « skill ». Passez ces fichiers en revue lorsque les commandes ou les conventions changent, comme vous le feriez pour toute autre documentation du projet.

Les invites, le fichier CLAUDE.md et le guide des compétences orientent le comportement de Claude ; ils ne garantissent pas qu’une instruction sera suivie. Les hooks peuvent effectuer des vérifications lors d’évènements configurés, mais leur fiabilité dépend du type de hook et de son implémentation.

Un hook de commande exécute un script. Un hook de prompt ou d’agent repose sur le jugement d’un modèle. Comme l’explique le guide des bonnes pratiques d’Anthropic : « Un hook de prompt ou d’agent demande à un autre modèle de prendre une décision ; il n’est donc pas déterministe non plus. » Pour une règle qui doit être appliquée, utilisez des contrôles de permission appropriés et testez le hook de commande ou HTTP concerné, y compris la manière dont il gère les échecs.

Les sous-agents personnalisés constituent un autre moyen d'organiser les tâches récurrentes. Définissez un spécialiste dans le répertoire in.claude/agents/ lorsqu'un rôle de révision distinct ou un périmètre d'outils spécifique est nécessaire, plutôt que d'ajouter chaque instruction de spécialiste à la session principale. Ces guides sur le meilleur modèle Claude pour le travail et les types d'agents IA fournissent un contexte supplémentaire.

Si votre équipe gère des invites pour plusieurs produits IA, découvrez ces outils d'ingénierie des invites permettant de gérer des bibliothèques au-delà de Claude Code.

Lorsqu’une session produit un résultat incomplet ou inadapté, vérifiez si la requête a laissé des décisions importantes en suspens. Ces cinq erreurs peuvent compliquer le diagnostic et la révision du travail.

La commande « Examine le référentiel » ne donne à Claude que très peu d’indications sur les fichiers pertinents ou sur le moment où s’arrêter. Vous risquez d’obtenir un résumé général sans réponse au problème à l’origine de la requête.

Nommez le comportement ou la décision que vous devez comprendre, identifiez un emplacement et définissez le résultat attendu. Par exemple : « Tracez la manière dont ce point de terminaison vérifie les permissions et citez les fonctions pertinentes. » Si vous utilisez des sous-agents, posez à chacun d’eux une question ciblée plutôt que de leur déléguer la même recherche illimitée.

Passer d’une fonctionnalité à un bug sans rapport, puis à une demande de documentation, fait que la discussion conserve un contexte qui peut ne pas s’appliquer à la tâche en cours. Les références telles que « ce fichier » ou « l’approche précédente » deviennent alors ambiguës.

Utilisez des sessions distinctes pour les tâches sans rapport entre elles. Si plusieurs sessions doivent effectuer des modifications sur le référentiel, utilisez des arborescences Git distinctes afin qu’elles ne modifient pas le même répertoire de travail. Petite parenthèse : la commande /btw de Claude Code permet de garder l’échange en dehors de l’historique principal de la discussion.

Une compilation peut réussir alors qu’une fonctionnalité ne se comporte pas correctement. Une suite de tests peut réussir simplement parce qu’elle n’a jamais testé l’entrée défaillante. Demander à Claude d’« exécuter les tests » ne permet pas de déterminer quelle exigence ces tests vérifient.

Plannez les critères d'acceptation avec des vérifications spécifiques. Pour la correction d'un bug, demandez la preuve que le test de reproduction a échoué avant la modification et qu'il a réussi après celle-ci. Gardez les critères non testés visibles plutôt que de considérer une commande réussie comme la vérification de l'ensemble de la modification.

Un fichier CLAUDE.md en constante évolution peut contenir des commandes obsolètes, des règles en double et des instructions qui contredisent les exigences spécifiques à une tâche. Renforcer la formulation ne résout pas ces conflits.

Comparez le fichier avec le référentiel actuel. Supprimez les consignes obsolètes, clarifiez les règles contradictoires et transférez les instructions à portée très restreinte vers des règles ou des compétences s'appliquant à un chemin d'accès spécifique. Si une exigence doit être appliquée, configurez et testez les contrôles appropriés au lieu de vous contenter de rappels répétés.

Une révision peut mettre en évidence à la fois des défauts réels, des points d'incertitude et des suggestions de refactorisation facultatives. L'application de toutes les suggestions peut alourdir la modification sans pour autant améliorer le comportement recherché.

Demandez les preuves et l'impact derrière chaque constat. Donnez la priorité aux problèmes d'exactitude et aux exigences non satisfaites, examinez les affirmations incertaines et excluez les améliorations sans rapport du diff actuel. Un réviseur doit être capable de signaler l'absence de constats nécessitant une action lorsque les preuves appuient cette conclusion.

Pour adapter un modèle, remplacez ses variables par les informations spécifiques à votre projet et déterminez ce que Claude doit faire avant d'effectuer les modifications. Suivez ces étapes pour préparer la requête et examiner le résultat.

Pour une modification mineure et bien définie, vous pouvez demander à Claude de la mettre en œuvre directement. Pour un code que vous ne connaissez pas bien, des modifications touchant plusieurs fichiers ou des exigences non résolues, commencez par établir un plan.

Appuyez sur Maj+Tab jusqu'à ce que le mode Plan s'affiche, ou lancez Claude Code avec la commande claude --permission-mode plan. Dans ce mode, Claude peut inspecter les fichiers et exécuter des commandes en lecture seule sans modifier votre code source. Vérifiez les fichiers, les dépendances et les tests proposés avant d'approuver la mise en œuvre. Appuyez sur Ctrl+G pour ouvrir le plan proposé dans votre éditeur.

Fournissez à Claude les éléments nécessaires à la compréhension de la tâche : une référence de fichier, un journal d'erreurs nettoyé, une capture d'écran ou un cahier des charges. Utilisez le symbole @ suivi d'un chemin d'accès pour inclure le contenu de ce fichier.

Choisissez l'ensemble de sources le plus petit possible. L'inclusion d'un journal ou d'un répertoire entier peut ajouter des éléments non pertinents et alourdir le contexte. Supprimez les identifiants et les données sensibles avant le partage de journaux, et vérifiez que Claude dispose des outils nécessaires pour récupérer les URL de documentation que vous fournissez.

Par exemple, la commande `cat error.log | claude -p "Explique cette erreur"` envoie un journal via une requête non interactive. Ne l'utilisez qu'après avoir vérifié le contenu du fichier. C'est là toute la valeur pratique de l'IA contextuelle: fournir au modèle des informations pertinentes pour la tâche à accomplir.

Lorsque vous ajoutez une fonctionnalité, identifiez un composant ou une fonction similaire dans le référentiel. Indiquez à Claude les conventions à respecter, telles que le client API, la logique de validation, la gestion des erreurs ou la structure des tests.

« Suivre la manière dont @src/widgets/Weather.tsx récupère et met en cache les données » fournit à Claude une référence concrète. Précisez également les différences requises par la nouvelle fonctionnalité afin qu’elle ne reprenne pas un comportement qui n’est plus adapté. Ces conventions doivent refléter le flux de travail de développement logiciel de votre équipe.

Pour les modifications de code, précisez la commande de test, de compilation ou de linting pertinente, ainsi que le comportement qu’elle doit vérifier. Pour la recherche, demandez des références de fichiers ou des identifiants de validation. Pour le travail lié à l’interface utilisateur, fournissez une image de référence et une méthode configurée pour capturer la mise en œuvre dans la même fenêtre d’affichage.

Demandez à Claude de vous indiquer ce qu’il a réellement vérifié, y compris les échecs et les vérifications ignorées. Vérifiez si les preuves couvrent l’exigence ; une compilation réussie ne garantit pas que tous les comportements requis fonctionnent.

Pour les tâches plus longues, Claude Code propose également une condition /goal et des hooks « Stop ». L'évaluateur d'objectif analyse les éléments mis en évidence au cours de la discussion plutôt que d'inspecter les fichiers ou d'exécuter des tests de manière indépendante. Un hook « Stop » configuré peut bloquer la finalisation, mais il existe des limites quant au nombre de blocages répétés. Aucun de ces deux éléments ne remplace des tests appropriés ni une révision humaine.

Si des corrections répétées ne permettent pas de résoudre un problème, faites une pause et identifiez ce qui n'était pas clair dans la demande initiale. Enregistrez les conclusions utiles, le statut actuel de Git et le travail restant avant d'effacer la discussion.

Le guide des bonnes pratiques d’Anthropic recommande de repartir de zéro après deux corrections infructueuses sur le même problème. Utilisez la commande /clear, puis fournissez une invitation révisée qui intègre ce que vous avez appris. Effacer la discussion n’annule pas les modifications apportées aux fichiers.

Appuyez sur Échap pour interrompre une réponse en cours d'exécution. Lorsque le champ de saisie de l'invite est vide, appuyez deux fois sur Échap pour ouvrir le menu de retour en arrière et choisir ce que vous souhaitez restaurer. Le retour en arrière n'annule pas tous les effets externes ; utilisez donc des points de contrôle Git et des procédures de restauration distinctes pour les modifications apportées aux bases de données ou aux services distants.

Enregistrez les consignes applicables à l'ensemble du projet dans CLAUDE.md, les procédures reproductibles dans les compétences et les instructions relatives à des fichiers spécifiques dans des règles liées à un chemin d'accès. Utilisez des hooks pour les actions liées à des évènements spécifiques, comme l'exécution d'un formateur après une modification en cours.

Faites votre choix en fonction du moment où l'instruction doit s'appliquer :

Une exigence relative à une fonctionnalité a généralement sa place dans la consigne de tâche ou le cahier des charges correspondant, plutôt que dans le fichier CLAUDE.md. L'ajout d'instructions temporaires dans un fichier applicable à l'ensemble du projet rend celles-ci plus difficiles à distinguer des conventions qui devraient s'appliquer à l'ensemble du référentiel.

Par exemple, conservez la commande de test du projet dans le fichier CLAUDE.md, placez les conventions spécifiques aux composants dans une règle de portée de chemin d'accès et enregistrez une procédure de révision récurrente en tant que « skill ». Consultez ces fichiers lorsque les commandes ou les conventions changent, comme vous le feriez pour toute autre documentation du projet.

Les invites, le fichier CLAUDE.md et le guide des compétences orientent le comportement de Claude ; ils ne garantissent pas qu’une instruction sera suivie. Les hooks peuvent effectuer des vérifications lors d’évènements configurés, mais leur fiabilité dépend du type de hook et de son implémentation.

Un hook de commande exécute un script. Un hook de prompt ou d’agent repose sur le jugement d’un modèle. Comme l’explique le guide des bonnes pratiques d’Anthropic : « Un hook de prompt ou d’agent demande à un autre modèle de prendre une décision ; il n’est donc pas déterministe non plus. » Pour une règle qui doit être appliquée, utilisez des contrôles de permission appropriés et testez le hook de commande ou HTTP concerné, y compris la manière dont il gère les échecs.

Les sous-agents personnalisés constituent un autre moyen d’organiser les tâches récurrentes. Définissez un spécialiste dans le répertoire in.claude/agents/ lorsqu’un rôle de révision distinct ou un périmètre d’outils spécifique est nécessaire, plutôt que d’ajouter chaque instruction de spécialiste à la session principale. Ces guides sur le meilleur modèle Claude pour le travail et les types d’agents IA fournissent un contexte supplémentaire.

Si votre équipe gère des prompts pour plusieurs produits IA, découvrez ces outils d'ingénierie des prompts permettant de gérer des bibliothèques au-delà de Claude Code.

Lorsqu'une session produit un résultat incomplet ou inadapté, vérifiez si la requête a laissé des décisions importantes en suspens. Ces cinq erreurs peuvent compliquer le diagnostic et la révision du travail.

La commande « Examine le référentiel » ne donne à Claude que très peu d’indications sur les fichiers pertinents ou sur le moment où s’arrêter. Vous risquez d’obtenir un résumé général sans réponse au problème à l’origine de la requête.

Nommez le comportement ou la décision que vous devez comprendre, identifiez un emplacement de départ et définissez le résultat attendu. Par exemple : « Tracez la manière dont ce point de terminaison vérifie les permissions et citez les fonctions pertinentes. » Si vous utilisez des sous-agents, posez à chacun d’eux une question bien délimitée plutôt que de leur déléguer la même recherche sans restriction.

Passer d’une fonctionnalité à un bug sans rapport, puis à une demande de documentation, fait que la discussion conserve un contexte qui peut ne pas s’appliquer à la tâche en cours. Les références telles que « ce fichier » ou « l’approche précédente » deviennent alors ambiguës.

Utilisez des sessions distinctes pour les tâches sans rapport entre elles. Si plusieurs sessions doivent effectuer des modifications sur le référentiel, utilisez des arborescences Git distinctes afin qu’elles ne modifient pas le même répertoire de travail. Petite parenthèse : la commande /btw de Claude Code permet de garder l’échange en dehors de l’historique principal de la discussion.

Une compilation peut réussir alors qu’une fonctionnalité ne se comporte pas correctement. Une suite de tests peut réussir simplement parce qu’elle n’a jamais testé l’entrée défaillante. Demander à Claude d’« exécuter les tests » ne permet pas de déterminer quelle exigence ces tests vérifient.

Plannez les critères d'acceptation avec des vérifications spécifiques. Pour la correction d'un bug, demandez la preuve que le test de reproduction a échoué avant la modification et qu'il a réussi après celle-ci. Gardez les critères non testés visibles plutôt que de considérer une réussite de commande comme la validation de l'ensemble de la modification.

Un fichier CLAUDE.md en constante évolution peut contenir des commandes obsolètes, des règles en double et des instructions qui contredisent les exigences spécifiques à une tâche. Le simple fait de renforcer la formulation ne résout pas ces conflits.

Comparez le fichier avec le référentiel actuel. Supprimez les consignes obsolètes, clarifiez les règles contradictoires et transférez les instructions à portée restreinte vers des règles ou des compétences applicables à un chemin d'accès spécifique. Si une exigence doit être appliquée, configurez et testez les contrôles appropriés au lieu de vous contenter de rappels répétés.

Une révision peut mettre en évidence à la fois des défauts réels, des points d’incertitude et des suggestions de refactorisation facultatives. L’application de toutes les suggestions peut alourdir la modification sans pour autant améliorer le comportement recherché.

Demandez les preuves et l'impact derrière chaque constat. Donnez la priorité aux problèmes d'exactitude et aux exigences non satisfaites, examinez les affirmations incertaines et excluez les améliorations sans rapport du diff actuel. Un réviseur doit être capable de signaler l'absence de constatations donnant lieu à une action lorsque les preuves corroborent cette conclusion.