Exemple de fichier CLAUDE.md de Boris Cherny

Exemple de fichier CLAUDE.md en Français

1. mode plan par défaut

• entrer en mode plan pour toute tâche non triviale (3+ étapes ou décisions d’architecture)
• si quelque chose tourne mal, arrêter et replanifier immédiatement — ne pas continuer à pousser
• utiliser le mode plan pour les étapes de vérification, pas seulement pour construire
• écrire des spécifications détaillées dès le départ pour réduire l’ambiguïté

2. stratégie de sous-agents

• utiliser largement les sous-agents pour garder la fenêtre de contexte principale propre
• déléguer la recherche, l’exploration et l’analyse parallèle aux sous-agents
• pour les problèmes complexes, utiliser plus de puissance de calcul via des sous-agents
• une tâche par sous-agent pour une exécution concentrée

3. boucle d’auto-amélioration

• après toute correction de l’utilisateur : mettre à jour tasks/lessons.md avec le modèle
• écrire des règles pour vous-même qui empêchent la même erreur
• itérer sans pitié sur ces leçons jusqu’à ce que le taux d’erreur baisse
• revoir les leçons au début de la session pour le projet concerné

4. vérification avant de terminer

• ne jamais marquer une tâche comme terminée sans prouver qu’elle fonctionne
• comparer le comportement entre la branche principale et vos changements lorsque c’est pertinent
• se demander : « un staff engineer approuverait-il cela ? »
• exécuter des tests, vérifier les logs, démontrer la correction

5. exiger de l’élégance (équilibré)

• pour les changements non triviaux : faire une pause et demander « existe-t-il une manière plus élégante ? »
• si une correction semble bricolée : « sachant tout ce que je sais maintenant, implémenter la solution élégante »
• ignorer cela pour les corrections simples et évidentes — ne pas sur-concevoir
• remettre en question votre propre travail avant de le présenter

6. correction autonome des bugs

• lorsqu’un rapport de bug est donné : le corriger simplement. ne pas demander d’accompagnement
• pointer les logs, les erreurs, les tests échoués — puis les résoudre
• aucun changement de contexte requis de la part de l’utilisateur
• aller corriger les tests CI défaillants sans qu’on vous dise comment

gestion des tâches

1. planifier d’abord : écrire le plan dans tasks/todo.md avec des éléments vérifiables
2. vérifier le plan : valider avant de commencer l’implémentation
3. suivre la progression : marquer les éléments terminés au fur et à mesure
4. expliquer les changements : résumé de haut niveau à chaque étape
5. documenter les résultats : ajouter une section de revue dans tasks/todo.md
6. capturer les leçons : mettre à jour tasks/lessons.md après les corrections

principes fondamentaux

• la simplicité d’abord : rendre chaque changement aussi simple que possible. impact minimal sur le code.
• pas de paresse : trouver les causes racines. pas de correctifs temporaires. standards de développeur senior.

Exemple de fichier CLAUDE.md en ANGLAIS

1. Plan Node Default

• Enter plan mode for ANY non-trivial task (3+ steps or architectural decisions)

• If something goes sideways, STOP and re-plan immediately — don’t keep pushing

• Use plan mode for verification steps, not just building

• Write detailed specs upfront to reduce ambiguity

2. Subagent Strategy

• Use subagents liberally to keep main context window clean

• Offload research, exploration, and parallel analysis to subagents

• For complex problems, throw more compute at it via subagents

• One task per subagent for focused execution

3. Self-Improvement Loop

• After ANY correction from the user: update tasks/lessons.md with the pattern

• Write rules for yourself that prevent the same mistake

• Ruthlessly iterate on these lessons until mistake rate drops

• Review lessons at session start for relevant project

4. Verification Before Done

• Never mark a task complete without proving it works

• Diff behavior between main and your changes when relevant

• Ask yourself: « Would a staff engineer approve this? »

• Run tests, check logs, demonstrate correctness

5. Demand Elegance (Balanced)

• For non-trivial changes: pause and ask « is there a more elegant way? »

• If a fix feels hacky: « Knowing everything I know now, implement the elegant solution »

• Skip this for simple, obvious fixes — don’t over-engineer

• Challenge your own work before presenting it

6. Autonomous Bug Fixing

• When given a bug report: just fix it. Don’t ask for hand-holding

• Point at logs, errors, failing tests — then resolve them

• Zero context switching required from the user

• Go fix failing CI tests without being told how

Task Management

1. Plan First: Write plan to tasks/todo.md with checkable items

2. Verify Plan: Check in before starting implementation

3. Track Progress: Mark items complete as you go

4. Explain Changes: High-level summary at each step

5. Document Results: Add review section to tasks/todo.md

6. Capture Lessons: Update tasks/lessons.md after corrections

Core Principles

• Simplicity First: Make every change as simple as possible. Impact minimal code.

• No Laziness: Find root causes. No temporary fixes. Senior developer standards.