J'ai déjà écrit sur la meilleure façon de solliciter la dernière génération de modèles Claude 5 et de travailler avec eux de manière itérative pour découvrir ce que vous voulez construire.
Mais lorsque vous envoyez un message à Claude, le prompt ne représente qu'une petite partie du contexte qu'il reçoit. Une grande partie de votre contexte est assemblée à partir de votre system prompt, de vos Skills, de vos fichiers CLAUDE.md, de la mémoire et d'autres sources. Nous appelons cela l'ingénierie de contexte, et cela a un impact important sur les résultats que vous générez lorsque vous utilisez Claude Code ou que vous construisez vos propres agents.
Contrairement à un prompt, le contexte est utilisé de manière générale dans de nombreuses requêtes, il ne peut donc pas être aussi spécifique. Comment construire ces prompts et instructions généraux pour Claude, surtout quand on ne sait pas quel pourrait être le prompt d'un utilisateur ?
Cela peut être étonnamment difficile à mesure que les capacités de Claude évoluent. Récemment, nous avons constaté un bond important dans la manière dont nous sollicitons la dernière génération de modèles Claude. Nous avons supprimé plus de 80 % du system prompt de Claude Code pour des modèles comme Claude Opus 5 et Claude Fable 5 sans perte mesurable dans nos évaluations de codage.
Voici ce que nous avons appris sur la façon de solliciter cette nouvelle classe de modèles, et comment vous pouvez l'utiliser pour mettre à jour votre ingénierie de contexte. Nous avons intégré ces bonnes pratiques dans claude doctor ; utilisez la commande /doctor dans Claude Code pour ajuster vos Skills et vos fichiers CLAUDE.md.
Libérer Claude
Dans l'ensemble, nous avons constaté que nous sur-contraignions Claude Code, à la fois via notre system prompt et dans nos fichiers CLAUDE.md et Skills.
Par exemple, en lisant les transcriptions de notre propre utilisation interne de Claude Code, nous voyons plusieurs messages contradictoires dans une seule requête, comme « laissez la documentation selon le cas » ou « N'AJOUTEZ PAS de commentaires », car notre system prompt, nos Skills et les demandes des utilisateurs s'opposent.
Généralement, Claude peut interpréter l'intention de l'utilisateur pour parvenir à la bonne réponse, mais Claude doit réfléchir plus attentivement à ces messages qui se chevauchent et se contredisent avant de décider quoi faire.
Et bien que ces contraintes étaient autrefois nécessaires pour éviter les pires scénarios, nous avons depuis constaté que nous pouvons en supprimer beaucoup et laisser le modèle utiliser le contexte environnant et son jugement à la place.
De plus, Claude Code dispose désormais de nombreux outils supplémentaires. Claude se reposait auparavant sur CLAUDE.md comme source de mémoire, d'informations et d'instructions. Maintenant, nous avons la mémoire, les artefacts et les Skills, que Claude peut utiliser pour créer de nouvelles façons de charger et de partager le contexte entre les sessions.
Avant et maintenant
Il y avait un certain nombre d'anciennes bonnes pratiques d'ingénierie de contexte qui étaient devenues des mythes. Notamment :
**
Avant : Donner des règles à Claude
Maintenant : Laisser Claude utiliser son jugement
**Lorsque nous avons déployé Claude Code pour la première fois, nous devions nous assurer que Claude évitait les pires scénarios, comme la suppression de fichiers. Cela signifiait que nous donnions des instructions particulièrement strictes qui n'étaient pas toujours vraies. Par exemple, dans le system prompt, nous disions :
Dans le code : par défaut, n'écrivez pas de commentaires. N'écrivez jamais de docstrings multi-paragraphes ou de blocs de commentaires multi-lignes — une ligne courte maximum. Ne créez pas de documents de planification, de décision ou d'analyse sauf si l'utilisateur le demande — travaillez à partir du contexte de la conversation, pas de fichiers intermédiaires.
Mais pour un certain sous-ensemble de prompts, cette instruction serait erronée. Dans le cas de la documentation, l'utilisateur peut avoir ses propres préférences, ou des parties spécifiques d'un code très complexe peuvent nécessiter des blocs de commentaires multi-lignes.
Néanmoins, sans ces garde-fous pour les modèles plus anciens, les commentaires écrits par Claude seraient incorrects dans de nombreux cas et nous devions accepter ce compromis. Mais les modèles plus récents ont un meilleur jugement et peuvent gérer ces décisions sans règles explicites.
Dans le nouveau system prompt, nous disons : Écrivez un code qui ressemble au code environnant : adaptez la densité des commentaires, le nommage et l'idiome.
**
Avant : Donner des exemples à Claude
Maintenant : Concevoir des interfaces
**La règle numéro un pour l'utilisation des outils était de donner des exemples à Claude sur la façon de les utiliser. Avec nos modèles les plus récents, nous avons constaté que donner des exemples les contraint en fait à un certain espace d'exploration.
Au lieu d'utiliser des exemples, réfléchissez davantage à la conception de vos outils, scripts et fichiers — quels paramètres Claude a-t-il et comment peuvent-ils être plus expressifs ?
Par exemple, dans l'exemple de l'outil Todo, le simple fait de lister le statut comme une énumération entre pending, in_progress et completed, donne des indices à Claude sur la façon de l'utiliser. L'instruction de garder un seul élément in_progress aide à définir le comportement demandé.
**
Avant : Tout mettre en avant
Maintenant : Utiliser la divulgation progressive
**Comme Claude Code était axé sur le codage, notre system prompt incluait des informations détaillées sur la façon de faire la revue de code et la vérification. Ce n'était pas toujours nécessaire, mais quand ça l'était, c'était une information cruciale.
Depuis, Claude Code est devenu très compétent dans l'utilisation de la divulgation progressive — charger le bon contexte au bon moment. Par exemple, nous avons déplacé la vérification et la revue de code dans leurs propres Skills que Claude Code peut appeler sélectivement.
Mais la divulgation progressive n'est pas réservée aux Skills, nous l'utilisons aussi pour les outils. Certains de nos outils sont en « chargement différé », ce qui signifie que l'agent doit chercher leurs définitions complètes à l'aide de ToolSearch avant de les utiliser. Cela nous permet d'avoir plus d'outils (comme nos outils Task) qui ne prennent pas de place dans le contexte jusqu'à ce qu'ils soient nécessaires.
La même chose peut être appliquée à vos propres fichiers CLAUDE.md et Skill.md. Un mythe courant est que vous voulez en faire un référentiel central pour toutes les pratiques que vous pourriez rencontrer, car Claude ne les trouverait pas autrement. Au lieu de cela, envisagez d'avoir une arborescence de fichiers qui peuvent être chargés au bon moment.
**
Avant : Se répéter
Maintenant : Des descriptions d'outils simples
**Les modèles Claude plus anciens pouvaient parfois avoir besoin d'instructions répétées ou être plus susceptibles d'écouter les instructions à la fin de leur fenêtre de contexte qu'au début. Cela signifiait que notre system prompt avait parfois des références aux outils dans le system prompt principal ainsi que des instructions dans la description de l'outil.
Nous avons constaté que nous pouvions supprimer ces exemples répétés et mettre les instructions sur la façon d'utiliser les outils dans les descriptions d'outils plutôt que dans le system prompt.
**
Avant : La mémoire dans les fichiers CLAUDE.md
Maintenant : La mémoire automatique
**Nous encouragions auparavant les utilisateurs à enregistrer des éléments dans la mémoire de Claude en utilisant le raccourci # pour écrire automatiquement dans leur CLAUDE.md. Désormais, Claude enregistre automatiquement les souvenirs pertinents pour le travail et pour vous.
**
Avant : Des spécifications simples
Maintenant : Des références riches
**En mode planification, Claude Code s'est fortement appuyé sur des fichiers markdown contenant des plans. Stocker ces fichiers en tant que plans aidait Claude à s'y référer lorsque nécessaire. Une autre bonne pratique similaire était de stocker des spécifications dans la base de code pour que Claude s'y réfère lorsqu'il travaille sur des projets plus longs.
Mais nous avons constaté que Claude peut gérer des références de plus en plus complexes. Au lieu de simples fichiers markdown, Claude peut référencer des artefacts HTML créés par notre nouvelle fonctionnalité d'artefacts.
Vous pouvez également donner à Claude des références sous forme de code. Une spécification peut aussi être une suite de tests détaillée, ou une fonction dans une autre base de code que Claude pourrait porter.
Les rubriques sont une autre forme de références. Les rubriques permettent à Claude d'essayer de vérifier votre goût dans un domaine particulier (par exemple, à quoi ressemble une bonne conception d'API) en utilisant des workflows dynamiques et en lançant des agents de vérification avec ces rubriques.
Appliquer cela à votre contexte
En résumé, à quoi cela ressemble-t-il lorsque vous assemblez votre contexte ?
System Prompt
Un system prompt est fortement lié au contexte du produit. Il indique à Claude dans quel produit il opère et ce qu'il fait. Pour Claude Code, vous ne le modifierez probablement jamais, mais si vous construisez votre propre harnais d'agent, c'est là que vous devriez passer beaucoup de temps.
CLAUDE.md
Gardez votre CLAUDE.md léger et décrivez brièvement à quoi sert votre dépôt, mais consacrez la plupart des tokens aux pièges dans la base de code. Par exemple, vous pouvez organiser votre code pour garder les types dans un seul fichier monolithique et nulle part ailleurs. Évitez d'énoncer les « évidences » que Claude devrait connaître en regardant votre système de fichiers ou votre dépôt.
Utilisez la divulgation progressive pour plus de détails, par exemple si vous avez plusieurs instructions uniques sur la façon de vérifier votre travail, créez un Skill de vérification et référencez-le depuis votre CLAUDE.md.
Skills
Considérez les Skills comme des guides légers pour permettre à Claude de trouver des informations quand il en a besoin. Évitez de les sur-contraindre, sauf dans des domaines très importants.
Pour les Skills longs, essayez d'utiliser la divulgation progressive autant que possible — divisez-les en plusieurs fichiers et séparez-les.
C'est mieux quand les Skills encodent des opinions, des connaissances ou des bonnes pratiques particulières à vous, votre équipe ou votre produit.
Références
Vous pouvez utiliser @ pour mentionner des fichiers et les inclure comme références. Les références permettent à Claude de se référer à des informations détaillées sur le plan en cours.
Cela peut être dans des fichiers de spécifications, des maquettes, ou même des bases de code entières. En général, vous devriez préférer les fichiers qui sont sous forme de code car ils fournissent des instructions claires et haute fidélité à Claude dans un langage qu'il connaît très bien. Par exemple, une maquette HTML d'un design produira généralement de meilleurs résultats qu'une description du design ou une capture d'écran.
Essayez de simplifier
Dans l'ensemble de votre system prompt, de vos Skills et de vos fichiers CLAUDE.md, vous aurez peut-être besoin de simplifier comme nous l'avons fait. Nous avons déployé une nouvelle commande appelée claude doctor, qui vous aidera à le faire automatiquement également. Pour plus de détails sur la façon de solliciter spécifiquement les modèles plus avancés, consultez notre guide de terrain Fable.
