4 incidents, 4 règles : comment mon CLAUDE.md s'est écrit tout seul

try { if(localStorage) { let currentUser = localStorage.getItem('current_user'); if (currentUser) { currentUser = JSON.parse(currentUser); if (currentUser.id === 3897818) { document.getElementById('article-show-container').classList.add('current-user-is-article-author'); } } } } catch (e) { console.error(e); } Michel Faure Posted on Apr 28 • Originally published at dev.to 4 incidents, 4 règles : comment mon CLAUDE.md s'est écrit tout seul #claudecode #ai #productivity #softwareengineering Mon ERP avec Claude Code (3 Part Series) 1 Combien vaut 91 000 lignes produites avec Claude Code ? 2 RLS Supabase en prod : quatre pièges qui silencent tes requêtes 3 4 incidents, 4 règles : comment mon CLAUDE.md s'est écrit tout seul Si tu as 30 secondes. Un CLAUDE.md efficace ne documente pas, il contraint — chaque règle répond à une fois où l'agent s'est trompé. Cet article donne la structure à quatre couches que j'utilise pour un ERP de 91 000 lignes (CLAUDE.md racine, AGENTS.md, .claude/rules/ par module, skill auto-invoqué), quatre règles opérantes tirées d'incidents datés, et une discipline tenable : écrire l'interdit avant la bonne pratique. Utile si tu pilotes du code avec Claude Code au quotidien et que tu vois ton agent dériver. Pourquoi pas juste un README On me demande pourquoi je ne mets pas simplement dans le README ce qui est dans CLAUDE.md. Les deux fichiers n'ont pas le même destinataire. Le README s'adresse à un humain qui le lira une fois, au démarrage, et s'en souviendra selon ses moyens. Le CLAUDE.md s'adresse à un agent qui le relit à chaque session, qui n'a pas de mémoire entre deux sessions, et qui prendra chaque phrase au pied de la lettre. Le README documente, le CLAUDE.md contraint. Pas de paragraphes introductifs, pas de storytelling. Des règles denses formulées pour être lues hors contexte, avec une séparation stricte entre ce qui est autorisé, ce qui est interdit, et ce qui demande une validation humaine. Version initiale, quarante lignes de naïveté Le premier CLAUDE.md de Rembrandt, posé le 21 mars 2026, tenait dans une page d'écran. Stack, commandes, arborescence, quelques conventions évidentes du type « Server Components par défaut ». Ce qui me frappe en le relisant, ce n'est pas ce qu'il contient, mais ce qu'il ne contient pas. Rien sur ce que l'agent allait se tromper à faire les jours suivants. Nous écrivons ce que nous savons déjà, alors que la valeur du fichier vient précisément de ce que nous ne savons pas encore. Les règles utiles ne pouvaient pas être formulées au jour 1, parce qu'elles ont été produites par des incidents qui n'avaient pas encore eu lieu. Quatre incidents, quatre règles 1. Server Component + onClick, le crash silencieux Jour 4. Catherine passe la tête dans le bureau. « Michel, j'ai cliqué sur le bouton d'émargement et rien. Pas d'erreur, pas de rouge, rien. » Elle ne me dit pas « ça plante », elle me dit « rien ne se passe », ce qui pour un bouton est précisément pire. Je rouvre la page. Le build TypeScript est vert, Turbopack ne remonte rien, le crash n'apparaît qu'au rendu serveur en prod, avec un message sibyllin, Event handlers cannot be passed to Client Component props, ERROR 3637204658. Nous avons tous tendance à chercher la cause dans le composant qui crashe, et c'est là que le piège se referme. L'erreur vient d'un <select onChange={() => {}}> dans le Server Component parent, pas dans le composant client qu'on suspecte. La phrase de Catherine a produit la règle, ajoutée au CLAUDE.md dès…

This excerpt is published under fair use for community discussion. Read the full article at DEV Community.