Claude Code Starter Kit

Claude Code n'a pas de mémoire infinie. Tout ce qu'il lit (tes fichiers, tes commandes, ses propres réponses) remplit une fenêtre de contexte. Plus elle se remplit, plus il perd en qualité : il oublie une consigne donnée plus tôt, ou il mélange une piste abandonnée avec la piste actuelle.

C'est ça, le context poisoning : ton contexte est pollué par des tentatives ratées, des instructions qui se contredisent, des vieux fils qui n'ont plus rien à faire là. Le symptôme classique : tu corriges Claude, il refait la même erreur deux messages plus loin.

Quand la fenêtre approche de sa limite, Claude Code compacte automatiquement : il résume la conversation pour gagner de la place. Ça marche, mais ça arrive tard, quand le contexte est déjà chargé, et le résumé est moins bon que si tu l'avais déclenché toi. Tu as deux commandes pour reprendre la main :

La règle simple : une tâche, une session. Tu changes de sujet, tu fais /clear. Tu es dans le même sujet depuis longtemps, tu fais /compact. Tu peux lui dire quoi garder : /compact garde les décisions sur la base de données.

L'astuce avant /clear : la passation. Rien de ce qui est seulement dans la conversation ne survit. Avant d'effacer, demande à Claude d'écrire un fichier passation.md : l'objectif, le problème en cours, les fichiers importants, ce qui a raté, la prochaine étape. La session suivante le lit et reprend là où tu en étais, avec un contexte propre. C'est le prompt de la vidéo, à copier tel quel :

La section 1 t'a dit que la fenêtre se remplit. /context te montre de quoi : les messages, les fichiers lus, les outils chargés, le système. Tape-le quand Claude commence à répondre moins bien : tu sauras si c'est la conversation qui pèse, ou autre chose.

Le cas qui surprend tout le monde : les outils connectés (section 14). Chaque serveur branché charge la description de tous ses outils dès le démarrage, que tu t'en serves ou non. Si tu vois une grosse part prise par des outils que tu n'utilises pas, tu sais quoi débrancher.

Avec un abonnement, tu as des limites d'usage qui se rechargent par fenêtres de quelques heures. /usage te montre où tu en es. Si tu es en API (paiement au token), /cost te donne le coût de la session en cours. Regarde-le une fois par jour au début, tu vas vite sentir ce qui coûte :

Un fichier texte nommé CLAUDE.md à la racine de ton projet. Claude le lit au démarrage de chaque session. Tu y mets ce que tu répètes sinon tout le temps : comment lancer le projet, comment lancer les tests, les règles de style, ce qu'il ne doit jamais toucher.

Deux pièges. Ce n'est pas une config stricte : une instruction floue ou noyée dans un fichier trop long sera ignorée. Et au-delà de 200 lignes, Claude en perd une partie. Court, précis, ordonné. Une procédure en dix étapes n'y a pas sa place : c'est une skill.

Dans un projet existant, tape /init. Claude explore le code, repère la structure et les commandes, et écrit un CLAUDE.md de départ. Relis-le : il se trompe parfois, et c'est le bon moment pour ajouter tes propres règles.

Claude Code n'est pas ChatGPT. Parle-lui comme à un développeur qui arrive sur ton projet : le contexte, le problème exact, comment tu sauras que c'est réglé. « Corrige le bug » donne du hasard. Une demande qui contient les trois donne un résultat.

Et une chose à la fois. « Fais l'authentification, la base, le design et le déploiement » finit à 60 % partout.

Sur une tâche floue ou qui touche plusieurs fichiers, ne le laisse pas foncer. Passe en mode plan : il lit, il pose des questions, il propose une démarche. Tu valides, puis il code. C'est le meilleur remède au code qui résout le mauvais problème.

Par défaut, Claude te demande la permission avant chaque modification de fichier ou commande. Au début, garde ce mode : tu vois tout ce qu'il fait, et c'est comme ça que tu apprends. Quand tu lui fais confiance sur un projet, Shift+Tab bascule en acceptation automatique des modifications. Un cran de plus et tu es en mode plan.

Claude a modifié six fichiers et c'est pire qu'avant ? Appuie deux fois sur Échap, ou tape /rewind. Tu choisis un point de la conversation et tu y reviens, avec le code tel qu'il était à ce moment-là. Ça marche même si tu n'as pas fait de commit.

Git, c'est l'historique de ton code. Tu n'as pas besoin d'en connaître les commandes pour commencer : demande à Claude. Prends l'habitude de committer à chaque étape qui marche : combiné au rewind, tu ne perds plus jamais rien. Tu apprendras les commandes en le regardant faire. C'est exactement l'idée.

Une règle dans CLAUDE.md, Claude peut l'oublier. Un hook, non : c'est une commande que Claude Code exécute lui-même à un moment précis. Tu n'as pas besoin d'écrire la config à la main : demande-la à Claude, ou passe par /hooks.

Tu expliques pour la troisième fois comment tu veux qu'un article soit écrit, ou comment on déploie chez toi ? Mets-le dans une skill : un dossier .claude/skills/nom-de-la-skill/ avec un fichier SKILL.md. Au démarrage, Claude ne lit que le nom et la description ; le reste, seulement quand la demande correspond.

La règle : installe une skill là où ce n'est pas ton métier, écris la tienne là où c'en est un. Et tu ne l'écris pas à la main : tu fais le travail une fois, puis « fais-en une skill », puis « fixe la skill » à chaque plantage. Les skills ont leur guide complet, depuis zéro : ce que c'est, comment ça se charge, comment en écrire une qui marche, et les quatre gestes →

Retour à la section 1 : lire cinquante fichiers pour répondre à une question sature ton contexte. Un subagent est un second Claude, avec son propre contexte, qui fait le travail et ne te rend que la conclusion. Tu peux simplement le demander dans ta phrase. Pour des rôles récurrents (relecteur, testeur), /agents te laisse en définir des permanents.

MCP est le standard pour brancher un outil externe sur Claude Code. Chaque serveur MCP ajoute des capacités : interroger une base, lire des tickets, piloter un navigateur. Attention à la section 2 : chaque serveur branché charge ses outils dans ton contexte, même quand tu ne t'en sers pas. Branche ce dont tu as besoin, débranche le reste.

Jusqu'ici tu discutes avec Claude. Avec -p, tu lui donnes une consigne, il répond, il s'arrête. Ça se met dans un script, dans un cron, dans un pipeline. C'est le passage de « je me fais aider » à « je construis des choses qui utilisent l'IA ». Pour un débutant, c'est la première fois que tu programmes avec un modèle plutôt que de lui parler.

Deux sessions dans le même dossier se gênent : l'une modifie ce que l'autre lit. La solution est un worktree git : une copie du projet sur une autre branche, dans un dossier à côté. Une session par worktree, une par terminal. Un Claude écrit la fonctionnalité, un autre relit ou écrit les tests. Ne fais ça qu'une fois que la section 10 (git) est naturelle pour toi.