AIDiveCinq habitudes, cinq commandes
Toutes les listes d'habitudes Claude Code vous disent quoi faire. Celle-ci transforme chaque habitude en une commande que Claude Code exécute lui-même, de sorte que l'habitude tienne que le modèle la lise ou non. Nous avons lancé les cinq sur un vrai repo, ledgerly, une petite API de facturation en Node 20 et TypeScript, avec Claude Code 2.1.294.
La raison se trouve dans les bonnes pratiques d'Anthropic : une ligne comme "Always typecheck before you finish" dans votre CLAUDE.md "works most of the time, not every time" (fonctionne la plupart du temps, pas à chaque fois). Les cinq commandes ci-dessous sont /goal, un hook PreToolUse, /context avec /clear, /skill-doctor, et un subagent relecteur en lecture seule.
Pourquoi une habitude écrite finit par céder
CLAUDE.md est le fichier d'instructions que Claude lit au début de chaque session, un readme écrit pour un nouveau coéquipier : commandes, conventions et règles. C'est là que la plupart des habitudes atterrissent, souvent avec les plus importantes en majuscules, comme "NEVER edit src/store/migrations.ts".
La documentation d'Anthropic sur la mémoire est explicite sur la nature de ce fichier : Claude le lit comme du contexte, pas comme une configuration appliquée de force. Chaque ligne est un conseil pesé face à la tâche en cours. La différence est celle qui sépare une checklist de code review sur une page de wiki d'un contrôle dans votre pipeline CI : la première dépend de quelqu'un qui la lit, le second s'exécute de toute façon.
Le geste : ouvrez votre CLAUDE.md et marquez chaque ligne qui doit tenir à chaque fois, sans exception. Laissez le reste où il est, car le fichier reste le bon endroit pour ce que Claude ne peut pas déduire de votre code, et la doc vise moins de 200 lignes par fichier.
Habitude un : dire à quoi ressemble "terminé"
Claude s'arrête quand le travail a l'air fini. Si rien ne lui dit si le travail l'est vraiment, notent les bonnes pratiques d'Anthropic, c'est vous qui devenez la suite de tests.
/goal fixe une ligne d'arrivée une fois pour toutes. Après chaque tour, un petit modèle rapide lit la conversation et répond : atteint, pas encore atteint, ou impossible. Il ne peut ni exécuter de commandes ni lire de fichiers, donc écrivez la condition comme quelque chose que la sortie de Claude peut démontrer, par exemple la sortie complète des tests.
| Essai sur ledgerly | Ce que nous avons vu |
|---|---|
| Session classique, même demande de fonctionnalité | Les tests ont tourné dans un appel d'outil replié ; la réponse disait "pnpm test passes (37/37)" |
Avec /goal et la condition "full pnpm test output printed" |
La réponse a affiché toute l'exécution, "Tests 44 passed (44)", puis "Goal achieved (45s · 1 turn · 5.1k tokens)" |
Tapez /goal seul pour voir son statut et /goal clear pour le retirer. Pour une correction d'une ligne, vous n'en avez pas besoin ; la doc dit qu'il compte surtout sur les longues exécutions, où Claude termine parfois un tour alors qu'il reste des points ouverts.
Habitude deux : une règle qui ne peut pas casser
Une règle en majuscules est respectée la plupart du temps, ce qui est justement le problème. Un hook est un petit script que Claude Code lance de lui-même à un moment précis ; un hook PreToolUse s'exécute avant chaque appel d'outil. Le nôtre lit le chemin du fichier et, quand c'est src/store/migrations.ts, affiche "migrations.ts is append-only: add a new migration file instead" et se termine avec le code 2. Le guide des hooks précise que le code de sortie 2 bloque l'appel et renvoie le message à Claude, et que le blocage tient même quand les demandes de permission sont désactivées.
Lors de nos essais : avec la règle dans CLAUDE.md, Claude a refusé la modification de lui-même. Sans la règle, Claude s'est dirigé deux fois vers le fichier de migrations et le hook a bloqué les deux modifications ; Claude a modifié le reste et rapporté "A project hook blocked both of my edits to that file." Lors de deux essais ultérieurs, il a lu le script du hook d'abord et n'a jamais touché au fichier.
Un hook ne bloque que ce qu'il sait reconnaître, un chemin ou une commande. Les règles de jugement, comme "écris du code propre", restent dans CLAUDE.md, et une correspondance étroite évite que le hook ne bloque votre propre travail.
Habitude trois : une tâche, un contexte
Le contexte, c'est tout ce que le modèle voit à chaque tour : vos instructions, les fichiers qu'il a lus et toute la conversation. /context l'affiche sous forme de grille ; /clear vide la conversation, tandis que les fichiers et les réglages restent.
/context sur ledgerly |
Total | Messages |
|---|---|---|
| Après la tâche terminée | 57.5k sur 1m de tokens | 26.4k tokens |
Après /clear |
31.1k sur 1m de tokens | 130 tokens |
D'après la doc : /clear entre deux tâches sans rapport ne coûte rien, et après deux corrections qui échouent, on vide le contexte et on écrit un meilleur prompt. Au milieu d'une tâche, utilisez plutôt /compact avec un point de focus.
Habitude quatre : ne charger que ce que vous utilisez
Un skill est une instruction empaquetée que Claude charge quand une tâche y correspond. Le skill complet ne se charge que lorsqu'il s'exécute, mais sa ligne de description reste dans le prompt à chaque tour, et le budget de ces listes est d'environ 1 % de la fenêtre de contexte, si bien que les skills les moins utilisés perdent leur description en premier.
/skill-doctor liste chaque skill avec son coût en contexte et la fréquence à laquelle vous l'avez utilisé. Sur notre machine, il a signalé :
| Type | Chargés mais jamais invoqués |
|---|---|
| Skills personnels | 13 |
| Synchronisés depuis claude.ai | 14 |
| Skills de plugins | 25 |
Il a aussi listé 4 plugins non utilisés récemment. Désactivez un skill dans /skills ; les skills synchronisés reviennent si vous les supprimez, donc désactivez-les sur claude.ai ; les skills de plugins passent par le gestionnaire de plugins. Une ligne de description est petite : cela réduit le bruit plutôt que de libérer la moitié de votre contexte.
Habitude cinq : un regard neuf sur le diff
Un subagent est une seconde session Claude lancée pour une seule mission, avec son propre contexte vide, qui renvoie un résumé. La documentation d'Anthropic le dit sans détour : confier la même tâche à un subagent n'améliore pas la réponse, mais un relecteur neuf aide parce qu'il n'a pas vu votre raisonnement.
Notre relecteur vit dans .claude/agents/reviewer.md avec des outils en lecture seule : Read, Grep, Glob, Bash(git diff:*) et Bash(git status:*). Sur le diff des factures en retard, la propre relecture de la session auteur a trouvé un vrai bug : les factures ayant la même date d'échéance étaient triées par id comme du texte. Le relecteur a trouvé le même bug et le test manquant en 28 secondes, puis a vérifié une à une toutes les conventions du README. Il a aussi affirmé que la vérification des types était propre, ce que ses outils ne pouvaient pas exécuter, et la session principale l'a signalé comme non vérifié. Appelez-le une fois par fonctionnalité, avant le merge.
Quelle habitude mettre en place en premier
Commencez par le hook, sur la règle qui a déjà été enfreinte plus d'une fois dans votre repo. /clear et /skill-doctor ne coûtent rien. Gardez /goal pour les longues exécutions et le relecteur pour le merge. La règle à retenir : si une habitude doit tenir à chaque fois, faites-en quelque chose que Claude Code exécute, pas quelque chose que Claude lit.
