101 Claude Code Tips

1Pas de vérification, pas de victoire

Première parade, la plus directe : donner à Claude un moyen de se contrôler lui-même. Le livre en donne une définition large : « tout ce que Claude peut exécuter et lire est une vérification » (module 6). Un test automatique en est une. Un contrôle de types vérifie que chaque valeur a bien le type annoncé : c'en est une aussi, comme une capture d'écran à comparer à une cible. Sans vérification possible, on réduit la tâche jusqu'à en trouver une, ou on ne la délègue pas.

La vérification s'écrit dans la consigne. Le modèle du livre s'appuie sur bun, un outil JavaScript qui lance les tests. Le voici, précédé de la consigne nue :

✗ AVANT (exemple de mon cru)
Ajoute un limiteur de débit dans src/limiter.ts.

✓ APRÈS (modèle du livre)
Après avoir implémenté le limiteur de débit dans src/limiter.ts :
- Lance `bun test src/limiter.test.ts` et confirme que tous les tests passent.
- Lance `bun run typecheck` et confirme zéro nouvelle erreur.

Si la vérification échoue, ne déclare pas le succès. Recommence.

Sans la dernière ligne, selon le livre, Claude produit souvent un résumé confiant même quand la vérification a échoué.

Deux montages à deux sessions renforcent ce contrôle. Dans le premier, une session écrit le changement et une session neuve relit le diff, la liste des lignes modifiées, sans connaître le raisonnement de la première. Dans le second, l'une écrit le test et l'autre le code qui le fait passer.

2Un CLAUDE.md de cinquante lignes, et surtout ce qu'il interdit

Vérifier après coup ne rattrape pas une tâche partie dans la mauvaise direction. D'où la seconde famille d'idées : garder Claude dans le cadre, à commencer par un fichier. Le CLAUDE.md est le fichier de consignes permanentes que Claude relit au début de chaque session. Gonflé, il fait l'inverse de l'effet voulu. Le livre le dit ainsi : « les CLAUDE.md gonflés poussent Claude à ignorer les vraies consignes, parce que les règles se perdent dans le bruit » (module 2). Le livre mesure sa taille en tokens. Un token est un morceau de mot, l'unité que le modèle compte et facture. Cible du livre : environ 50 lignes, moins de 1 000 tokens. Boris Cherny, qui dirige Claude Code chez Anthropic, élague le fichier de son équipe à chaque nouvelle version du modèle.

Le livre y recommande deux sections. La première fixe les limites du projet : une ligne sur ce qu'on fait, plusieurs sur ce qu'on ne fait pas :

## Project boundaries
**In scope:** génération de présentations, export PDF et HTML local
**Out of scope:**
- Authentification ou comptes utilisateurs
- Base de données ou tout backend persistant
- Édition collaborative en temps réel

Sans cette section, un mot flou suffit à faire dérailler Claude. Vous écrivez « améliore l'éditeur de diapositives ». Or « améliorer » n'a pas de limite. D'après le livre, Claude peut passer quatre heures à ajouter des comptes utilisateurs que personne ne demandait. Avec la section, les comptes utilisateurs figurent dans la liste de ce qu'on ne fait pas. Claude sait qu'il ne doit pas y toucher.

La seconde section est une liste de faits sur votre machine. Une ligne dit par exemple : « Python : non installé (ne le cherche pas) ». Claude lit cette ligne. Il ne perd donc plus de temps à chercher un outil qui n'existe pas.

3Un hook garantit ce que le CLAUDE.md espère

Le CLAUDE.md a une limite : ce ne sont que des consignes. Claude les suit la plupart du temps, et rien ne prouve qu'il les a suivies cette fois. C'est le problème de la première idée : on n'a que sa parole. Pour une règle absolue, le livre passe aux hooks. Un hook est un petit script que Claude Code lance automatiquement avant ou après une action de Claude. Il peut la refuser. La formule du module 7 : « les hooks garantissent l'exécution ; les prompts, non ».

# ✗ Dans le CLAUDE.md : « Ne jamais lancer rm -rf ni git push --force. »
#   Claude s'en souvient souvent, pas toujours.

# ✓ Hook du livre, lancé avant chaque commande Bash :
cmd=$(jq -r '.tool_input.command' <&0)          # jq lit le JSON : extrait la commande proposée
if echo "$cmd" | grep -Eq '(rm -rf|git push --force|git reset --hard)'; then
  echo "Blocked dangerous pattern: $cmd" >&2    # message renvoyé à Claude
  exit 2                                        # code 2 = « refusé »
fi
exit 0                                          # tout autre cas : on laisse passer

Le script compare la commande à une liste noire. Si elle y figure, il sort avec le code 2, le signal de refus. Claude lit alors le message et peut proposer une variante plus sûre. Le livre signale trois pièges :

• Un hook qui bloque doit se déclencher avant l'action, sur l'événement PreToolUse. Branché sur PostToolUse, qui suit l'action, il arrive trop tard : le fichier est déjà écrit.
• Claude Code a un mode où il ne demande plus aucune confirmation, bypassPermissions. Un hook qui sort avec le code 2, le refus du script ci-dessus, bloque l'action quand même.
• Le terminal lit votre .bashrc au démarrage. Un echo placé dedans s'ajoute à la réponse du hook et la casse. Le correctif vérifie que le shell est interactif :

if [[ $- == *i* ]]; then
  echo "Welcome back, $(whoami)"    # affiché seulement dans un terminal humain
fi

4Demandez à Claude ce qu'il a décidé sans vous

Un hook arrête les actions qu'on a su prévoir. Mais Claude prend aussi des décisions qu'on n'a pas prévues, et il ne les signale pas.

Le livre propose deux questions. Avant le code, on demande à Claude la liste de toutes ses hypothèses. Après le code, on lui demande la liste des décisions prises sans qu'on les ait précisées. La seconde paie le plus (module 5). Toute implémentation fait des choix en silence. Par exemple, Claude choisit seul :

• la bibliothèque utilisée ;
• le style de gestion d'erreurs ;
• l'emplacement du nouveau fichier ;
• le nom de l'API publique.

Moins on laisse de choix ouverts, moins il y en a à démasquer. Le livre va dans ce sens : « un prompt court et contraint fait mieux qu'un long prompt soigné sans périmètre ». Voici une consigne vague, puis la même consigne contrainte. Redis est une base de données en mémoire : ici, elle garde les sessions de connexion.

✗ Ajoute l'authentification à cette application.

✓ Ajoute l'authentification par e-mail et mot de passe avec le modèle
  d'utilisateur existant, stocke les sessions dans Redis, n'introduis pas
  de nouvelles abstractions et ne change aucune route existante.
  Si c'est impossible sans violer ces contraintes, arrête-toi et explique pourquoi.

Chaque partie de la consigne ferme un choix. « Par e-mail et mot de passe » dit quoi construire. « Dans Redis » dit où garder l'état. « Ne change aucune route » dit ce qui ne bouge pas. La dernière phrase demande à Claude de s'arrêter plutôt que de trancher seul.

Certains mots ouvrent tous les choix d'un coup. Le livre met en garde contre « refactor », « improve », « clean up » et « optimize » (astuce 100) : lus à la lettre, chacun autorise Claude à redessiner la zone visée. « Refactor » est entendu comme « repense ce code » : fonctions extraites, noms changés, nouvelles abstractions, parfois de nouveaux fichiers. Une petite amélioration localisée est entendue comme une retouche chirurgicale. Le livre conseille de garder les mots forts pour quand on les pense vraiment, et sinon de prendre un vocabulaire borné : « tighten », « rename », « extract this one helper ».

✗ Refactorise la logique de génération des diapositives.
   → helpers extraits, fonctions renommées, nouvelles abstractions, parfois de nouveaux fichiers

✓ Fais une petite amélioration localisée de la logique de génération des diapositives,
  sans changer la structure.
   → une retouche chirurgicale du code existant

5Le chat n'est pas une preuve

Retour à la première famille : ne pas croire Claude sur parole. Ce que Claude écrit n'est pas une preuve. Quand vous le contredisez, il répond sur le ton de la conversation. Il acquiesce puis corrige, dans un texte fluide, que la correction soit juste ou non. Le livre le dit : le modèle imite la forme de l'accord. Un « Vous avez absolument raison ! » ne prouve donc rien. La parade est mécanique : lire le diff plutôt que la réponse. Le livre le résume en une phrase : « le langage du chat ne porte rien » (module 15). Autrement dit, rien ne doit reposer sur ce qui s'écrit dans la conversation.

Même piège avec les tests (astuce 98). Claude peut écrire « j'ai lancé bun test, tout est vert » sans avoir appelé l'outil Bash, celui qui exécute réellement une commande. Le texte est fluide, plausible et faux. Le raccourci Ctrl+O ouvre la transcription : sans appel Bash visible, il n'y a pas eu de test. Ce contrôle compte surtout dans les exécutions automatiques (mode -p, GitHub Actions), où personne ne regarde chaque appel. Le livre demande d'y mettre la vérification dans la structure de l'exécution.

6Videz le contexte, ou il vous le fera payer

Retour à la seconde famille : garder Claude dans le cadre, cette fois pendant la session. Le contexte, c'est tout ce que Claude a sous les yeux dans la session : vos messages, ses réponses, les fichiers lus. « Un contexte périmé dégrade les performances », dit le module 14, d'où trois gestes :

• /clear vide le contexte entre deux tâches sans rapport, par exemple après une refonte d'authentification, avant un bug de paiement.
• /compact résume la conversation quand la même tâche continue. Le livre l'accompagne d'une consigne sur ce qu'il faut garder, par exemple « concentre-toi sur le plan de refonte et les tests en échec ».
• Un fichier de passation, écrit avant de vider le contexte et relu par la session suivante. Sur un projet long, le livre le préfère à /compact : Claude y retrouve l'état exact des travaux.

## Tâche en cours
Migrer `src/auth/` vers le nouveau sessionStore.
## Fait
- `loginHandler` migré, tests au vert.
## En cours
- Migration de `passwordResetHandler`, bloquée sur la branche du jeton de récupération.
## Prochaines étapes
1. Reprendre la migration de `passwordResetHandler`.

Ces gestes vident un contexte déjà plein. Les sous-agents, eux, évitent qu'il se remplisse. Un sous-agent est un second Claude, lancé à part, avec son propre contexte. Le livre donne une règle (module 9) : quand une tâche produit beaucoup de texte qu'on ne relira pas (résultats de recherche, journaux, contenu de fichiers), on la confie à un sous-agent. Son exemple : « trouve tous les endroits où l'on utilise cette API obsolète » renvoie des centaines de lignes. Ces lignes restent dans le sous-agent. Il ne vous donne qu'un résumé, et votre contexte reste léger.