Votre configuration claude.md rend en réalité le codage par IA 99 % plus lent

AAI LABS
컴퓨터/소프트웨어경영/리더십AI/미래기술

Transcript

00:00:00Un seul fichier détermine si le produit que vous obtenez
00:00:04est bien la mise en œuvre dont vous aviez besoin.
00:00:05Pour les utilisateurs de Claude Code, il s'agit de claud.md, d'autres ont leurs propres fichiers, mais le plus souvent
00:00:10ils utilisent agents.md.
00:00:11Mais peu importe celui que vous utilisez, si vous ne le configurez pas correctement, vous continuerez à vous battre avec votre
00:00:15agent sur chaque tâche.
00:00:17Et si vous pensez que lancer une simple commande d'initialisation suffit,
00:00:20vous avez tort.
00:00:21Vous devez suivre une structure adaptée au projet, ce qui permettra à votre agent
00:00:26de mieux fonctionner.
00:00:27C'est pourquoi nous avons compilé les meilleures pratiques à suivre, issues d'autres sources crédibles
00:00:31ainsi que de nos propres heures passées sur Claude Code, afin que vous puissiez les intégrer directement
00:00:35dans votre flux de travail.
00:00:36Et le dernier point est important car il détermine la manière dont votre agent suit réellement vos instructions
00:00:41et, sans cela, le reste des instructions de votre fichier n'aura pas beaucoup d'impact.
00:00:45La première chose à ajouter dans votre fichier claud.md provient directement
00:00:49du répertoire de compétences d'Andrej Karpathy, qui contient les meilleurs modèles de claud.md dont il parle.
00:00:54Vous devez ajouter une instruction explicite demandant à Claude de réfléchir avant de coder.
00:00:58Cela oblige Claude à énoncer ses hypothèses clairement.
00:01:01S'il existe plusieurs interprétations, il doit toutes les présenter afin que nous puissions choisir parmi
00:01:05l'ensemble des implémentations.
00:01:07Cela pousse Claude à réfléchir sous un angle différent avant de se lancer
00:01:11dans la solution.
00:01:12Cela garantit que la solution implémentée correspond à ce que vous vouliez.
00:01:15Cette ligne permet d'éviter un grand nombre de corrections dans notre flux de travail, c'est pourquoi nous l'avons trouvée
00:01:20si utile.
00:01:21Avec cette instruction ajoutée, chaque fois que vous demanderez à Claude d'implémenter une fonctionnalité, il
00:01:25posera un ensemble de questions liées à la tâche que vous lui avez confiée, afin que vos réponses le guident sur
00:01:29la manière de réaliser concrètement la tâche.
00:01:31Cette partie en particulier est utile car Claude ne devinera plus les implémentations
00:01:35en se basant uniquement sur des modèles mémorisés dans ses données d'entraînement.
00:01:39Il réfléchira minutieusement à la bonne implémentation et confirmera avec vous s'il s'agit bien
00:01:43de l'implémentation prévue, avant de travailler sur la fonctionnalité, plutôt que de simplement deviner
00:01:48et vous obliger à l'interrompre parce qu'il n'a pas suivi l'approche
00:01:52que vous aviez en tête, ce qui arrive beaucoup trop souvent et nécessite de nombreuses
00:01:56corrections.
00:01:57La règle suivante est de choisir la simplicité d'abord.
00:01:59C'est quelque chose de très simple, mais qui doit être spécifiquement précisé dans claud.md pour que
00:02:04l'agent soit correctement rappelé de ce principe.
00:02:07Claude ou n'importe quel autre agent a tendance à écrire des solutions complexes pour des problèmes qui peuvent être résolus avec
00:02:11des solutions simples.
00:02:12Ce n'est pas seulement problématique parce que cela cause des retards.
00:02:15Cela rend également le code difficile à refactoriser plus tard, et encore plus difficile d'ajouter des fonctionnalités car
00:02:19l'implémentation est si verbeuse qu'elle consomme beaucoup de jetons pour réaliser des choses simples.
00:02:24Donc, cette ligne pousse littéralement Claude à viser la simplicité.
00:02:27Nous l'ajoutons à chaque projet, surtout lors du travail sur des applications à grande échelle, car
00:02:32à cette échelle, cela devient encore plus important.
00:02:35Cela indique spécifiquement à Claude de ne pas ajouter de fonctionnalités au-delà de ce qui est demandé et d'assurer
00:02:39une gestion d'erreurs appropriée pour l'implémentation.
00:02:41Le cadre disciplinaire autour de cela est essentiellement un seuil strict.
00:02:44Si la solution à tout problème que vous posez peut être gérée en 200 lignes et pourrait être refactorisée
00:02:49en 50, alors Claude doit réécrire la solution parce que son approche est mauvaise.
00:02:54Cela empêchera Claude d'écrire beaucoup de code inutile ou des choses
00:02:58qui ne sont même pas implémentables et qui reflètent une mauvaise direction choisie par Claude.
00:03:03La troisième partie de claud.md consiste à implémenter des changements chirurgicaux ou, en termes simples, à ne toucher
00:03:08qu'aux parties que l'agent doit absolument toucher.
00:03:11Cela résout un problème que nous rencontrons souvent lorsque Claude écrit une grande quantité de code
00:03:15et que la correction doit être explicitement définie dans le fichier claud.md.
00:03:19Claude, ou les agents en général, lorsqu'on leur demande d'effectuer une tâche, ont tendance à essayer d'améliorer les éléments
00:03:24autour de cette tâche également.
00:03:25Ces améliorations peuvent ressembler à des modifications de code adjacent ou au formatage de la base de code,
00:03:29sur lesquels nous ne voulons pas qu'il se concentre pour le moment.
00:03:32C'est ennuyeux parce que l'attention de Claude est divisée entre les multiples choses qu'il
00:03:36essaie d'implémenter en même temps.
00:03:37Faire ce genre de changements n'est pas bon car Claude inclut essentiellement des choses
00:03:41que nous ne voulions pas qu'il fasse pour l'instant.
00:03:43Nous devons donc déclarer explicitement dans claud.md les instructions pour ne pas faire cela.
00:03:47Si l'agent remarque du code mort sans rapport, il doit le mentionner au lieu de le corriger lui-même.
00:03:52Parfois, ces éléments sont présents pour des raisons spécifiques qui devront être traitées plus tard,
00:03:56pas au stade où se trouve l'application actuellement.
00:03:58Le cadre mental qui permet à Claude de décider comment agir correctement consiste à vérifier chaque changement
00:04:03et à voir s'il découle réellement de ce que l'utilisateur a demandé.
00:04:06Si c'est le cas, il doit faire ce changement.
00:04:08Si ce n'est pas le cas, il ne doit pas toucher à cette fonctionnalité.
00:04:10Si cette ligne est ajoutée, alors chaque fois que Claude aura un problème d'implémentation, il ne changera
00:04:14que la chose que l'utilisateur lui a demandé de corriger.
00:04:17Il vous indiquera donc tous les autres problèmes qu'il a trouvés dans le même fichier, et vous pourrez décider
00:04:21à partir de là si vous voulez vraiment qu'il les corrige ou non.
00:04:24Le dernier modèle extrait d'Andrej Karpathy est l'exécution axée sur les objectifs.
00:04:29Les agents ne savent pas à quoi ressemble le résultat correct, ce qui est le problème central.
00:04:33Ils fonctionneraient beaucoup plus efficacement s'ils le savaient, et c'est ce que cette règle corrige.
00:04:36Dans le fichier claud.md, nous devons explicitement demander à Claude de définir les critères de réussite
00:04:41pour chaque tâche que nous lui confions.
00:04:43Ainsi, pour toute tâche que nous lui transmettons, Claude doit la convertir en un objectif vérifiable.
00:04:47Par exemple, si vous lui demandez d'ajouter une validation, il écrira des tests pour les entrées invalides
00:04:52et s'assurera que ces cas de test passent réellement avec les bonnes valeurs de retour pour les bonnes entrées.
00:04:57L'idée globale est donc que l'agent implémente des cas de test, puis itère jusqu'à ce que tous les cas
00:05:01de test passent et, à la fin, que le projet ait le même comportement que celui que nous attendions.
00:05:06Si vous lui donnez n'importe quelle consigne sur une tâche, il définira l'objectif vérifiable et planifiera l'implémentation.
00:05:11Ensuite, il vérifiera le travail pour vous en ajoutant tous les cas de test et en montrant comment il
00:05:15gérera l'ensemble de l'application.
00:05:17Cela peut fonctionner pour le raisonnement logique, mais si vous voulez que l'agent vérifie à quoi ressemble votre
00:05:21UI, l'agent ne peut pas écrire de cas de test pour cela.
00:05:23Pour cela, vous pouvez ajouter l'extension Chrome de Claude ou le protocole MCP Puppeteer afin qu'il puisse vérifier
00:05:28à quoi ressemble l'interface utilisateur en utilisant ces outils.
00:05:30Cela aide parce que les changements d'interface sont difficiles à juger rien qu'en regardant le code, et donner à
00:05:35l'agent un moyen vérifiable de voir les visuels actuels de l'application lui permet de corriger
00:05:40les problèmes.
00:05:41Vous pouvez donc ajouter explicitement une ligne pour qu'il sache qu'après l'implémentation de l'interface,
00:05:45il doit également vérifier le résultat via le MCP.
00:05:48Si vous avez créé un fichier claud.md en utilisant la commande d'initialisation de Claude Code, vous verrez qu'il
00:05:53ajoute des commandes pour exécuter le serveur de développement et le serveur de build.
00:05:57Mais elles sont déjà dans ses données d'entraînement, Claude connaît déjà ces commandes, et
00:06:01nous n'avons pas besoin de gaspiller inutilement des lignes dans claud.md pour lui dire ce qu'il sait déjà.
00:06:05Donc, dans votre fichier, vous ne devez mentionner que les outils que vous voulez que Claude utilise, plutôt que ceux
00:06:09qu'il utilise par défaut.
00:06:11Il existe certains outils CLI qui accélèrent le flux de travail mais qui ne sont pas dans les données d'entraînement par défaut de Claude
00:06:16ou dans les modèles sur lesquels il s'appuie déjà.
00:06:18Par conséquent, vous devez les ajouter explicitement pour que Claude sache que ces outils sont installés
00:06:22et qu'il ne retombe pas sur ce qu'il utilise habituellement de lui-même.
00:06:26Par exemple, si vous avez installé le CLI GitHub au lieu d'utiliser Git pour travailler, vous pouvez
00:06:30ajouter une instruction dans claud.md pour utiliser son CLI plutôt que les commandes Git par défaut pour toutes
00:06:36les opérations.
00:06:37De même, vous pouvez ajouter d'autres commandes qui ne sont pas les commandes par défaut.
00:06:41Vous devez également ajouter les instructions d'exécution du projet dans ce fichier si elles sont différentes
00:06:45des instructions habituelles.
00:06:46Par exemple, la plupart des projets dans la configuration par défaut sont exécutés par npm, et si votre projet s'exécute avec
00:06:51pnpm, vous devez ajouter cette information afin que l'agent sache quelles commandes doivent réellement
00:06:56être exécutées.
00:06:57Rien d'autre au-delà des commandes que Claude connaît déjà ne devrait être inclus dans le fichier claud.md.
00:07:01fichier.
00:07:02La mention suivante dans claud.md est inspirée par le créateur de Claude Code et le flux de travail
00:07:07qu'il a révélé.
00:07:08Il a expliqué que claud.md n'est pas un fichier à écrire une fois et à utiliser pour toujours.
00:07:12C'est quelque chose qui doit être constamment modifié, mis à jour et amélioré au cours
00:07:16de la construction, comme un processus continu sur lequel il faut itérer encore et encore.
00:07:20Vous devez donc ajouter une instruction stipulant que si Claude a dû être informé par l'utilisateur que son implémentation
00:07:25n'était pas correcte, il doit d'abord appliquer les corrections indiquées par l'utilisateur.
00:07:29Une fois que Claude a appliqué ces corrections, il doit également ajouter ces apprentissages à un fichier dédié,
00:07:33afin que Claude puisse progressivement construire une base de connaissances sur ce qu'il ne doit pas faire et sur la
00:07:38bonne façon de faire les choses, qu'il pourra référencer plus tard si nécessaire.
00:07:42Mais avant d'avancer, écoutons un mot de notre sponsor.
00:07:45Klaus, vous avez probablement entendu parler des agents IA.
00:07:47Peut-être avez-vous essayé d'en configurer un vous-même, et 15 minutes plus tard, vous fixez votre terminal
00:07:51à copier des clés API dans des fichiers de configuration, en vous demandant si vous venez de divulguer quelque chose d'important.
00:07:56Klaus évite tout cela.
00:07:57Klaus exécute OpenClaw, l'agent IA open source sur le cloud.
00:08:00Vous vous inscrivez, vous obtenez 15 $ de crédits open router et vous commencez à prompter.
00:08:04Pas de terminal, pas de docker, pas de chasse aux clés API.
00:08:07Je l'ai testé en demandant à Klaus de scraper un répertoire de startups, d'organiser les résultats dans un tableau
00:08:12et de me l'envoyer par e-mail.
00:08:13Une seule instruction dans la fenêtre de chat, terminé.
00:08:15Pas de code, pas d'extensions de navigateur.
00:08:17Il est livré avec des outils intégrés comme Exa et Apollo, et se connecte à Slack, WhatsApp, même
00:08:21iMessage.
00:08:22Tout s'exécute sur une machine protégée par un pare-feu, complètement isolée de vos comptes personnels.
00:08:27Si quelque chose casse, son agent de réparation automatique, Clawbert, le corrige sans que vous ayez à toucher à quoi que ce soit.
00:08:31Cliquez sur le lien dans le commentaire épinglé et essayez Klaus gratuitement.
00:08:35Comme la plupart des projets de codage sont gérés par Git, vous devez explicitement ajouter une instruction
00:08:39dans claud.md pour que Claude ne lance pas de commandes irréversibles sans confirmation.
00:08:44Et s'il est nécessaire de lancer une telle commande, l'agent doit d'abord demander la permission.
00:08:48Ces commandes sont dangereuses car, une fois exécutées, les conséquences sont irréversibles
00:08:53et elles peuvent causer des dommages à la production.
00:08:55Des choses comme forcer un push, réinitialiser le head, fusionner des branches ou lancer des suppressions forcées.
00:09:00commandes.
00:09:01Vous devez également ajouter une instruction stipulant que si Claude n'est pas sûr qu'une commande soit destructrice
00:09:04ou non, il doit demander plutôt que de supposer.
00:09:07Cela vous évitera bien des ennuis.
00:09:08Par exemple, si Claude essaie accidentellement de fusionner une branche que vous ne voulez pas fusionner,
00:09:12il demandera la permission avant de le faire, et vous pourrez alors refuser pour que votre travail
00:09:16reste en sécurité.
00:09:17Il n'est pas nécessaire de mettre toutes les informations dans un seul fichier claud.md, car cela ne ferait
00:09:22que le surcharger inutilement et distraire l'agent de ce qu'il doit réellement faire.
00:09:27Vous devez donc créer des fichiers de règles limités à un chemin, qui déclarent leur portée sur la première ligne
00:09:31et contiennent des instructions adaptées à ces fichiers exacts.
00:09:34Vous devez également mentionner l'emplacement de ces fichiers dans claud.md pour que Claude sache qu'ils existent.
00:09:40Par exemple, si vous voulez que Claude suive certaines instructions spécifiques lors de l'écriture d'API, vous
00:09:44pouvez les ajouter dans un fichier de règles dédié afin que lorsque Claude travaille dessus, il puisse charger
00:09:48ces instructions et les utiliser directement.
00:09:50Mais tout aussi important, cela garantit également que les instructions liées à l'API n'interfèrent pas
00:09:55lorsque Claude ne travaille pas dessus.
00:09:56Vous pouvez avoir plusieurs fichiers de règles pour différentes parties du projet, chacun contenant des instructions
00:10:00adaptées à cette zone spécifique.
00:10:02De cette façon, Claude ne charge que les instructions pertinentes lorsqu'il travaille sur cette partie.
00:10:06Par conséquent, cela évite l'encombrement du contexte et garde l'agent concentré sur sa tâche actuelle plutôt
00:10:11que d'être distrait par des règles sans rapport.
00:10:13La plupart des applications à grande échelle se trouvent dans un monorepo, qui est un seul grand dépôt où
00:10:18tous les différents composants sont conservés ensemble, chaque dossier agissant comme une partie séparée
00:10:22et chaque partie étant gérée indépendamment tout en contribuant à un aspect différent de
00:10:27l'application principale.
00:10:28Donc, si vous exécutez un projet à partir d'un monorepo, vous devez vous assurer que chaque sous-dépôt
00:10:32contient son propre fichier claud.md afin qu'il contienne des instructions spécifiques
00:10:37à celui-ci et n'ait pas à se fier uniquement aux instructions du claud.md global.
00:10:42Le fichier global ne devrait consister qu'en des instructions qui sont largement applicables à toutes les parties de
00:10:47le système.
00:10:48Mais les fichiers claud.md locaux fonctionnent mieux car ils peuvent contenir des instructions spécifiques
00:10:52à cette application ou à ce module particulier.
00:10:54Cela permet à l'agent de mieux fonctionner car il aura des conseils plus ciblés.
00:10:58Par conséquent, placer toutes les instructions d'un grand projet dans le fichier principal est une mauvaise décision.
00:11:02Cela surchargera le fichier avec des informations et, lorsque Claude passera par des zones avec des instructions
00:11:07qui ne concernent pas la tâche actuelle, cela pourra détourner son attention de ce qu'il
00:11:11doit réellement faire.
00:11:12Aussi, si vous appréciez notre contenu, pensez à appuyer sur le bouton "hype" car cela nous aide à
00:11:16créer plus de contenu comme celui-ci et à toucher plus de personnes.
00:11:19Vous devez également ajouter la description du projet dans votre fichier claud.md et vous assurer que cette
00:11:24instruction est placée au tout début, et non enterrée à l'intérieur du reste des
00:11:29instructions.
00:11:30Parce que l'agent saisit l'essence de ce que l'application fait en le lisant en premier.
00:11:33Il comprend donc le contexte de la structure de l'application, ce qu'elle fait en général, quels
00:11:38sont les différents services et dépendances, et comment l'application s'exécute.
00:11:41De cette façon, il le sait dès le début, plutôt que de regarder le code pour déduire ce que l'application
00:11:45fait.
00:11:46Une autre section que nous devons ajouter dans votre fichier claud.md est que Claude doit vérifier
00:11:50non seulement que la fonctionnalité existe, mais aussi qu'elle fonctionne correctement comme prévu, avant de rapporter
00:11:55une tâche comme étant terminée.
00:11:57Il doit utiliser tous les mécanismes de vérification disponibles pour confirmer que le build et les tests passent correctement,
00:12:02mais le but de cette section est de s'assurer que la tâche est réellement terminée en utilisant des étapes
00:12:07de vérification réelles, pas simplement en vérifiant que le code de la fonctionnalité existe.
00:12:11Par conséquent, cette instruction pousse Claude à faire des rapports plus fidèles et à utiliser plusieurs
00:12:15types de vérifications comme des tests unitaires, du linting et des vérifications de type pour s'assurer que l'application est implémentée
00:12:20correctement et fonctionne comme prévu.
00:12:23Enfin et surtout, l'ordre dans lequel vous mettez vos instructions dans le fichier claud.md est également
00:12:27très important pour assurer une haute performance de l'agent.
00:12:29Vous devez les classer par priorité.
00:12:31Les premières instructions doivent être des règles strictes, signifiant toujours non négociables, sans aucune exception
00:12:36quoi qu'il arrive.
00:12:37Ces règles strictes doivent toujours venir en premier, avant toute autre règle.
00:12:40Ensuite viennent les règles de priorité moyenne, qui ne sont pas aussi strictes que les précédentes.
00:12:44Elles sont quelque peu négociables mais restent importantes et ne doivent pas être violées.
00:12:48Après cela viennent les instructions de faible priorité, qui comprennent principalement des références et des commodités,
00:12:52afin que l'agent n'ait pas besoin de revenir en arrière pour utiliser cette section comme source de décision principale.
00:12:57Une autre chose importante est que vous devez vous assurer que le fichier claud.md reste court.
00:13:01Une bonne pratique est de le garder sous une limite stricte de 300 lignes, ce qui est considéré comme optimal
00:13:06pour la performance de l'agent.
00:13:07Mais une fois qu'il devient plus long que cela, la performance commence à se dégrader.
00:13:10Le fichier claud.md dont nous avons parlé ici et toutes les autres ressources mentionnées sont disponibles
00:13:15dans AI Labs Pro pour cette vidéo et pour toutes nos vidéos précédentes, d'où vous pouvez les télécharger
00:13:20et les utiliser pour vos propres projets.
00:13:21Si vous avez trouvé de la valeur dans ce que nous faisons et que vous voulez soutenir la chaîne, c'est la meilleure façon
00:13:25de le faire.
00:13:26Le lien est dans la description.
00:13:27Cela nous amène à la fin de cette vidéo.
00:13:29Si vous souhaitez soutenir la chaîne et nous aider à continuer à faire des vidéos comme celle-ci, vous pouvez le faire
00:13:33en utilisant le bouton "super merci" ci-dessous.
00:13:35Comme toujours, merci d'avoir regardé et je vous verrai dans la prochaine.

Key Takeaway

La performance des agents de codage dépend directement d'un fichier claud.md structuré par priorité et limité à 300 lignes, exigeant que l'agent réfléchisse avant d'agir et définisse des objectifs vérifiables pour chaque tâche.

Highlights

  • Une structure optimisée du fichier claud.md permet d'éviter les corrections répétitives et améliore l'efficacité des agents de codage.

  • L'ajout d'une instruction explicite forçant l'agent à réfléchir et à poser des questions avant de coder réduit les erreurs d'implémentation.

  • La limitation stricte du fichier claud.md à 300 lignes est nécessaire pour maintenir des performances optimales de l'agent.

  • Les instructions doivent être hiérarchisées par priorité, avec les règles non négociables placées en premier.

  • L'utilisation de fichiers de règles locaux limités à un chemin permet de réduire l'encombrement du contexte et de garder l'agent concentré.

  • Claude doit transformer chaque demande en un objectif vérifiable, incluant des tests unitaires pour confirmer la réussite de la tâche.

Timeline

Optimisation du fichier claud.md

  • Le fichier claud.md définit la qualité et la pertinence de l'implémentation produite par l'agent.
  • Une instruction explicite obligeant l'agent à réfléchir avant de coder empêche les erreurs basées sur des modèles mémorisés.
  • L'agent doit présenter ses hypothèses et ses interprétations pour permettre le choix de la meilleure approche.

Une configuration correcte du fichier claud.md est indispensable pour éviter les conflits fréquents avec l'agent. En intégrant l'instruction de réfléchir avant de coder, l'agent ne se contente plus de deviner, mais analyse le problème et valide son approche avec l'utilisateur, ce qui réduit drastiquement le besoin de corrections ultérieures.

Principes de simplicité et changements ciblés

  • L'imposition de la simplicité empêche l'écriture de code verbeux et difficile à refactoriser.
  • Un seuil strict, comme la réécriture si une solution dépasse le nombre de lignes nécessaire, discipline l'agent.
  • Les modifications doivent être limitées chirurgicalement aux zones concernées pour éviter les altérations non sollicitées.

Les agents ont tendance à générer des solutions complexes inutilement. Déclarer explicitement la priorité à la simplicité force l'agent à viser l'efficacité. De plus, il est crucial d'interdire à l'agent de modifier le code adjacent ou le formatage de la base de code pour éviter de diviser son attention et d'inclure des changements non désirés.

Exécution orientée vers les objectifs

  • Chaque tâche doit être convertie en un objectif vérifiable, idéalement par l'implémentation de tests.
  • L'utilisation de tests unitaires garantit que le comportement final du projet correspond aux attentes.
  • L'intégration d'outils comme le protocole MCP Puppeteer permet à l'agent de vérifier visuellement l'interface utilisateur.

Le problème central des agents est l'absence de définition claire du résultat attendu. En imposant à l'agent de définir des critères de réussite et des cas de test avant de coder, on s'assure qu'il itère jusqu'à ce que la fonctionnalité fonctionne réellement. Pour les aspects visuels, l'utilisation d'outils externes est nécessaire pour une vérification concrète.

Gestion des outils et itération continue

  • Seuls les outils spécifiques absents des données d'entraînement par défaut doivent être mentionnés.
  • Le fichier claud.md doit être un processus itératif, mis à jour avec les corrections apportées par l'utilisateur.
  • L'agent doit consigner ses erreurs dans un fichier dédié pour construire sa base de connaissances.

Inutile de lister des commandes que l'agent connaît déjà. Il faut se concentrer sur l'ajout d'instructions pour les outils personnalisés ou les flux de travail spécifiques, comme l'utilisation de GitHub CLI ou de pnpm. De plus, le fichier doit évoluer continuellement : chaque correction humaine doit être intégrée dans une base de connaissances pour éviter la répétition des mêmes erreurs.

Architecture du contexte et hiérarchisation

  • Les commandes irréversibles doivent exiger une autorisation explicite avant toute exécution.
  • L'utilisation de fichiers de règles locaux par module évite la surcharge du contexte global.
  • Les instructions doivent être classées par priorité : règles strictes d'abord, puis priorité moyenne, enfin commodités.
  • La limite optimale du fichier claud.md est fixée à 300 lignes pour éviter la dégradation des performances.

Pour les projets complexes ou monorepos, diviser les règles en fichiers locaux spécifiques à chaque dossier est plus efficace que de tout concentrer dans un fichier global. La structuration du fichier par priorité assure que l'agent respecte les règles critiques. Maintenir le fichier sous 300 lignes est la condition technique pour garantir la réactivité et la pertinence de l'agent.

Community Posts

View all posts