Un fichier d'instructions de projet est lu au début de chaque session : chaque ligne est donc payée à chaque requête tant que le fichier existe. Ce seul fait décide de ce qui y a sa place et de ce qui n'en a pas. Tout ce qui se découvre en lisant le code — le langage, le framework, l'arborescence — est répété à un lecteur qui le voit déjà. Ce qui mérite sa place, c'est l'inverse : la commande de test qui exige une option, la version de Node qui casse la compilation, la convention qu'un nouveau devinerait de travers, ce qui a déjà coûté un après-midi à quelqu'un. Ce créateur s'organise autour de ces catégories, estime le coût du fichier et signale les lignes qui racontent au dépôt des choses sur lui-même.
Fonctionnalités
Sections guidées par leur contenu attendu, non par une page blanche
Estimation de tokens en continu : le coût à chaque requête, pas une fois
Signale les lignes qui répètent ce que le code montre déjà
Signale les exhortations vides qui ne changent rien
Avertit quand le fichier atteint la taille où il n’est plus que survolé
Note l’absence de titres par lesquels élaguer
Les sections vides sont écartées plutôt qu’écrites à blanc
Se télécharge en CLAUDE.md
Comment utiliser Instructions du projet
Nommez le projet
Ne remplissez que les sections où vous avez du non-évident à dire
Surveillez l’estimation de tokens à mesure
Lisez les alertes puis téléchargez le fichier
Exemple
Entrée
This project is a React app.
Sortie
Warning: the language and framework are visible from the manifest
Le test pour chaque ligne : un lecteur trouverait-il cela en dix secondes ?
Erreurs courantes et dépannage
Le fichier est signalé comme trop gros. — Déplacez ce qui n’est pertinent qu’occasionnellement vers un document séparé que la session lira au besoin. Le fichier d’instructions est pour ce qui est toujours vrai.
Une ligne que je voulais est signalée comme découvrable. — Ignorez l’alerte si elle porte vraiment. La vérification invite à se demander si un lecteur le trouverait de toute façon ; ce n’est pas une règle.
Rien ne change quand j’ajoute des instructions. — Des instructions précises et vérifiables portent bien mieux que des générales. « Utilise les primitives de components/ui » bat « écris du code propre ».
Faut-il l’appeler CLAUDE.md ou autrement ? — Le contenu est le même. Enregistrez-le sous le nom que lit votre outillage ; la structure et la discipline ne changent pas.
Foire aux questions
Qu’est-ce qui a vraiment sa place dans ce fichier ?
Ce qui ne se découvre pas dans le code et serait sinon mal deviné : la commande qui exige une option, la version qui casse la compilation, la convention invisible dans n’importe quel fichier isolé, et les interdictions explicites. Le reste est répété à un lecteur qui sait déjà lire.
Quelle longueur ?
Assez court pour être encore lu. L’estimation s’affiche à la frappe ; au-delà de quelques milliers de tokens, il vaut la peine de se demander quelles lignes sont toujours pertinentes, car le reste peut vivre dans un document lu à la demande.
Pourquoi signaler « écris du code propre » ?
Parce que cela ne change rien. Une exhortation générale coûte des tokens à chaque requête sans fournir de base de décision ; une convention précise — où va la logique, quelles primitives utiliser — en fournit une.
Le paiement à chaque requête change-t-il quelque chose ?
C’est exactement la raison d’élaguer le fichier. Une page d’instructions est un petit coût une fois et un coût réel sur des milliers de requêtes ; d’où l’estimation à côté du texte plutôt que cachée.
Puis-je y mettre des secrets ?
Non — il est chargé en contexte à chaque session et généralement versionné. Gardez les identifiants dans votre environnement et n’y référez que par leur nom si les instructions doivent les mentionner.
Outils associés
Générateur de skills — Écrivez un SKILL.md dont le frontmatter est vérifié à la frappe.
Générateur de sous-agents — Créez le fichier de définition d'un sous-agent, outils et modèle compris.
Générateur de commandes — Créez une commande personnalisée, avec arguments et liste d'outils.