Sélecteur de modèles CLAUDE.md (Claude Code)

Que fait Sélecteur de modèles CLAUDE.md (Claude Code) ?

Aide un utilisateur avec un niveau de codage « débutant opérationnel » (sait suivre des commandes, ne diagnostique pas les erreurs, a besoin d'explications sans jargon technique) à décider quel(s) modèle(s) .md copier dans le dossier d'un projet concret, et pourquoi. Le projet peut être du code (app, script, site web) ou non technique (scénario, production audiovisuelle, écriture, recherche). Contrairement à la version de cette compétence pour claude.ai, ici il y a un accès réel au système de fichiers : on peut lire le dossier des modèles, lire le projet de destination, et écrire les fichiers finaux sans que l'utilisateur ait à les copier à la main.

Chemin du dossier des modèles

Il n'y a pas d'emplacement par défaut pour la collection de modèles : cherchez-le dans les instructions de l'utilisateur ou dans son CLAUDE.md. S'il n'y apparaît pas, si l'utilisateur mentionne un chemin différent, ou si ce chemin n'existe pas lors de la vérification, demandez le chemin correct au lieu de supposer ou d'en inventer un. Ne présumez pas que le dossier contient toujours le même contenu que la dernière fois que vous l'avez consulté : relisez-le toujours au début d'un nouveau projet (voir section suivante).

Avant toute chose : inventorier ce qu'il y a réellement

Ne supposez pas les noms de fichiers, et ne réutilisez pas un inventaire fait précédemment dans la même session. La collection de modèles dans le dossier local peut changer entre un projet et le suivant (l'utilisateur peut ajouter, supprimer ou remplacer des fichiers à tout moment, même en dehors de cette conversation). C'est pourquoi, chaque fois que vous analysez un nouveau projet, listez à nouveau le dossier des modèles maintenant, même si cela a déjà été fait auparavant dans cette même session.

1. Listez le contenu du dossier des modèles (ls ou équivalent) pour voir quels .md sont réellement disponibles.
2. Lisez le contenu de chacun (pas seulement le nom) pour comprendre ce qu'il fait : modèle de base, guide de migration, extension d'historique, doc spécifique de plateforme (Cloudflare, Convex, etc.).
3. Si l'utilisateur mentionne un fichier par son nom qui n'apparaît pas dans le dossier, dites-le explicitement au lieu de supposer qu'il existe ou d'inventer son contenu.
4. Si l'inventaire de cette fois diffère de celui fait précédemment dans la session (nouveaux fichiers, ou certains ont disparu), dites-le explicitement avant de recommander — n'appliquez pas silencieusement une recommandation basée sur un inventaire obsolète.

Première étape : identifier le type de projet

Avant les questions obligatoires, déterminez le type de projet. Il y a trois catégories, pas deux :

• Technique : code pur (app, script, site web, outil) sans composant de contenu créatif intégré
• Non technique : scénario, production audiovisuelle, écriture, recherche, notes — sans composant de code
• Mixte : le produit lui-même combine les deux de manière indissociable. Ce n'est pas « une app avec une phase d'écriture séparée » (cela reste technique, avec une note sur l'outil d'écriture externe le cas échéant) — c'est un cas où la construction du logiciel ET le contenu/les décisions créatives que ce logiciel va héberger font partie du même projet et ne peuvent pas être séparés en phases distinctes. Exemple : un site web que l'utilisateur programme lui-même pour écrire et organiser des scénarios, à la manière d'outils comme Campfire, où l'utilisateur a besoin à la fois d'aide sur le code de l'outil et sur le contenu narratif qui va dedans

Avec l'accès au système de fichiers, le type de projet peut aussi être partiellement déduit en inspectant le dossier de destination : présence de package.json, fichiers de code source, etc. suggère une composante technique ; absence totale de cela avec des documents texte, scénarios ou notes suggère du non technique. Mais l'inspection du code ne remplace pas la question à l'utilisateur lorsque le résultat est ambigu — confirmez avec lui avant de supposer la catégorie.

Le type détermine quel vocabulaire et quelles questions utiliser dans le reste de la compétence.

Outils ou plateformes inconnus

Si l'utilisateur mentionne un outil, une plateforme ou un logiciel que vous ne reconnaissez pas avec confiance (nom propre, produit peu connu, ou quelque chose que vous ne pouvez pas décrire avec précision de mémoire), et qu'un outil de recherche web est disponible dans cette session de Claude Code, cherchez-le avant de continuer. Si aucune recherche web n'est disponible, dites-le explicitement et demandez à l'utilisateur une brève description de ce que fait l'outil au lieu de supposer sa fonction à partir du nom. Le résultat doit informer comment vous décrivez cet outil dans le CLAUDE.md final (quel type de travail il organise, s'il est pour le lore/la recherche, pour l'écriture de scénario proprement dite, pour la production, etc.), au lieu d'utiliser une étiquette vague comme « outil de notes ».

Changements de décision en cours de route

Si l'utilisateur corrige une décision déjà prise (par exemple, change de modèle de base après que la composition ou même l'écriture du fichier sur disque a commencé), ne modifiez pas le fichier existant avec des changements partiels. Les modèles diffèrent par la structure, pas seulement par le contenu (regroupement des règles, sections présentes ou absentes, noms de rubrique), donc un correctif à moitié laisse des mélanges incohérents. À la place :

1. Confirmez explicitement ce qui change entre l'ancien modèle et le nouveau (quelles sections sont réorganisées, lesquelles apparaissent ou disparaissent), pour que ce soit clair qu'il ne s'agit pas d'un changement cosmétique
2. Si le fichier a déjà été écrit sur disque avec la décision précédente, confirmez avec l'utilisateur avant de le réécrire ou de le supprimer — ne supprimez pas les fichiers du projet de l'utilisateur sans son confirmation explicite, même s'ils ont été générés par cette même compétence il y a un instant
3. Régénérez le fichier complet depuis zéro avec le nouveau modèle, en réutilisant le contenu spécifique de l'utilisateur déjà collecté (réponses aux questions obligatoires, trous déjà remplis, ou ce qui a pu être déduit en lisant le code réel), mais sans réutiliser la structure du fichier précédent

Données obligatoires avant de recommander

Pour chaque projet nouveau que l'utilisateur mentionne, demandez (si elles n'ont pas déjà été fournies pour ce projet concret dans cette même session, et si elles ne peuvent pas être déterminées en lisant le projet réel) :

1. Existe-t-il déjà un CLAUDE.md dans le dossier de ce projet ? Vérifiez-le directement en listant le dossier de destination au lieu de demander — ne demandez que si le chemin du projet de destination n'est pas clair
2. Le projet va-t-il être maintenu activement pendant des semaines/mois, ou est-il ponctuel/expérimental ? Cela ne peut pas être déduit du code, il faut le demander
3. Selon le type de projet :
   • Technique : stack technique (framework, langage) — essayez de le déduire d'abord en lisant package.json, requirements.txt, Cargo.toml, build.gradle ou tout autre manifeste de dépendances dans le dossier de destination, avant de demander. S'il n'y en a pas ou si le projet est vide, demandez ; « je ne sais pas encore » reste une réponse valide
   • Non technique : outils et format de travail (par exemple : Fountain, Final Draft, Google Docs, Word, dossiers d'Obsidian, feuilles de calcul de production) — cela ne peut pas être déduit du système de fichiers de manière fiable, demandez-le. « Je ne sais pas » est valide
   • Mixte : les deux questions, la technique (en essayant de déduire d'abord comme dans le cas technique) et celle des outils/format (demandée). Elles ne se remplacent pas l'une l'autre — le projet a besoin des deux réponses. Demandez aussi si, pendant la construction de l'outil lui-même, l'utilisateur continue d'utiliser un autre outil externe en parallèle pour le contenu (scénario, lore), pour ne pas perdre cette référence

Cette question sur les outils est souvent incomplète au premier abord si le projet comporte plusieurs phases de travail distinctes (par exemple : un outil pour la recherche/le lore et un autre pour écrire le scénario proprement dit). Si la réponse initiale ne mentionne qu'un seul outil mais que le type de projet suggère qu'il peut y avoir plus d'une phase, demandez explicitement s'il y a un autre outil pour l'autre phase, au lieu de supposer qu'un seul couvre l'ensemble du projet.

Règle de non-répétition : une réponse n'est réutilisée que si elle a été donnée explicitement pour ce même projet, identifié par nom ou chemin, dans la session en cours. Les réponses données pour un projet différent ne sont jamais extrapolées, même si elles semblent générales.

Si une donnée concrète manque pour remplir le CLAUDE.md et ne peut être déterminée ni en demandant ni en lisant le code réel, marquez-la comme en attente. Ne l'inventez pas. Exemples de quoi demander ou inspecter selon le type :

• Technique : point d'entrée (cherchez-le dans le manifeste de dépendances ou les fichiers de configuration de build avant de demander), commandes de test/lint (lisez les scripts du manifeste), conventions de style (inspectez le code réel s'il existe déjà), structure de dossiers (listez directement)
• Non technique : structure de dossiers/documents du projet (listez directement), conventions de format (numérotation des scènes, nomenclature des versions — demandez), comment le travail est révisé ou validé (demandez)

Règles de décision

• Un CLAUDE.md préexistant existe → avant de décider comment procéder, distinguez deux cas :
  • Sans vérification par rapport au code réel : l'utilisateur l'a écrit à la main, l'a hérité d'un autre site, ou comporte des trous non remplis (marqueurs de type [EN ATTENTE], placeholders incomplets). Dans ce cas, il convient d'utiliser le guide de migration disponible dans le dossier des modèles (s'il y en a un) pour le faire correspondre au modèle choisi, en préservant le contenu spécifique de l'utilisateur
  • Déjà vérifié par rapport au dépôt réel (par une session précédente de Claude Code, ou parce que les détails qu'il contient sont trop spécifiques pour avoir été écrits sans lire le code) : le fichier contient des détails techniques extraits directement du code (conventions observées dans les fichiers réels, hooks git concrets, systèmes ou outils du projet non documentés dans aucun modèle générique, commandes de test/lint confirmées plutôt que supposées). Avec l'accès au système de fichiers, cela peut être réellement confirmé : comparez ce que dit le CLAUDE.md avec le code réel (les fichiers et commandes qu'il mentionne existent-ils ? Les conventions décrites correspondent-elles à ce qui se trouve dans le code ?). Exemple réel : un projet avec son propre système de « knowledge graph » documenté dans le CLAUDE.md avec la commande exacte pour le reconstruire et un avertissement sur la commande à NE PAS utiliser car elle casse le graphe — ce type de détail est irrécupérable s'il est perdu dans une fusion, car aucun modèle générique ne le prévoit. Dans ce cas, n'imposez pas la structure d'un nouveau modèle par-dessus. Ce contenu est plus précieux que le modèle, car il est vérifié par rapport à la réalité du projet et le modèle ne l'est pas. Demandez à l'utilisateur avant de toucher à quoi que ce soit : montrez ce qu'il perdrait s'il fusionnait vers le modèle choisi et ce qu'il gagnerait, et laissez-le décider s'il veut une fusion sélective ou le laisser tel quel
  • En cas de doute sur lequel des deux cas s'applique à un CLAUDE.md préexistant, demandez à l'utilisateur au lieu de supposer
• Aucun CLAUDE.md préexistant → créez à partir de zéro avec le modèle de base choisi
• Projet nouveau ou petit, sans CLAUDE.md préexistant, ET maintenance ponctuelle/expérimentale → privilégiez le modèle le plus compact disponible, sans avoir besoin de demander plus
• Projet nouveau ou petit, mais avec maintenance prévue sur des semaines/mois → c'est un cas de signaux contradictoires (« nouveau » pousse vers le compact, « maintenance longue » pousse vers le modèle plus complet). Ne résolvez pas silencieusement en faveur de l'un des deux : demandez explicitement à l'utilisateur lequel pèse le plus pour lui dans ce projet concret avant de recommander
• Maintenance semaines/mois → ajoutez le modèle d'historique de développement, s'il existe dans le dossier des modèles (l'historique s'applique également aux projets non techniques)
• Maintenance ponctuelle/expérimentale → ne proposez pas d'historique de développement
• Documentation spécifique de plateforme/infrastructure (Cloudflare, Convex, bases de données, auth, etc.) → ne s'applique qu'aux projets techniques. Ce n'est pas une décision binaire tout-ou-rien : ces documents couvrent généralement plusieurs services distincts d'une même plateforme. Avant de décider, identifiez quels services concrets le projet utilise réellement — avec l'accès au système de fichiers, cela peut être confirmé en lisant le manifeste de dépendances ou les fichiers de configuration réels (par ex. wrangler.toml, variables d'environnement utilisées dans le code) plutôt que de simplement demander
  • Si le projet n'utilise rien de ce que couvre le document → ne copiez rien de celui-ci, résumez en 3-6 lignes manuelles dans le CLAUDE.md ce qui s'applique
  • Si le projet utilise un ou plusieurs services réels du document, mais que le document couvre plus de services que le projet n'en utilise → ne copiez pas le fichier entier. Extrayez et copiez uniquement les sections correspondant aux services que le projet utilise réellement, en laissant de côté les sections des services non utilisés. Dites-le explicitement à l'utilisateur : quelles sections ont été incluses, lesquelles ont été laissées de côté et pourquoi
  • Copiez le document complet sans le réduire uniquement lorsque le projet utilise effectivement tous ou presque tous les services que le document couvre
• Si l'utilisateur hésite entre deux modèles de base, demandez d'abord la taille du projet et la maintenance à long terme avant de recommander (déjà couvert par les questions obligatoires ci-dessus)

Adapter le modèle de base aux projets non techniques

Lorsque le projet n'est pas du code, ne copiez pas littéralement les sections conçues pour le développement logiciel. Adaptez en conservant la logique, pas le vocabulaire :

Section technique originale	Adaptation non technique
Tech Stack	Outils et format de travail
Build, Test & Verify	Comment vérifier que quelque chose est correct (révision de continuité, lecture à voix haute, passage par un collaborateur, checklist de production)
Code Style & Conventions	Conventions d'écriture, de structure ou de format du document

Questions supplémentaires pour les projets non techniques

Quand le projet est non technique, en plus des données obligatoires ci-dessus (outils et format de travail, durée de maintenance), posez ces questions (sauf si elles ont déjà été répondues pour ce projet dans cette session) :

1. Y a-t-il des collaborateurs impliqués ? Si oui, combien et à quel moment (lecture/révision, co-écriture, production) — pour adapter les règles de collaboration et les flux de travail
2. Le projet a-t-il des contraintes de format spécifiques (longueur cible, nombre de pages/minute, structure obligatoire en actes/chapitres) — pour adapter les sections de vérification et de validation
3. Existe-t-il déjà un plan ou une structure de contenu ? Si oui, où se trouve-t-il (dans un autre fichier .md, un document externe, une note mentale que l'utilisateur peut décrire) et faut-il l'intégrer comme référence dans le CLAUDE.md ?

Ces questions ne remplacent pas les questions obligatoires de la section « Données obligatoires avant de recommander » ci-dessus ; elles les complètent.

Après la recommandation

Une fois que l'utilisateur a accepté une recommandation (quelle(s) plantilla(s) copier, avec ou sans adaptations) :

1. Si une seule plantille est choisie : copiez-la dans le dossier du projet (ou créez CLAUDE.md avec son contenu), en remplissant les trous avec les données collectées (ou en laissant les marqueurs [EN ATTENTE] si les données manquent)
2. Si plusieurs plantilles sont choisies : décidez si elles doivent être fusionnées en un seul CLAUDE.md ou gardées séparées selon leur nature (par exemple : CLAUDE.md principal + CLAUDE-HISTORY.md pour l'historique de développement). Expliquez brièvement pourquoi vous proposez cette structure
3. Si une plantille d'historique de développement est choisie : créez CLAUDE-HISTORY.md dans le dossier du projet, avec des sections vides ou des exemples prêts à être remplis par l'utilisateur (ou remplis si l'historique est déjà connu)
4. Avant d'écrire quoi que ce soit : si le dossier de destination contient déjà un fichier du même nom que celui que vous allez créer, confirmez avec l'utilisateur avant de l'écraser (comme spécifié dans la section sur les changements de décision)
5. Lisez toujours le fichier que vous venez d'écrire avant de confirmer qu'il est correct : avec l'accès au système de fichiers, vérifiez qu'il a bien été créé et que son contenu correspond à ce qui a été convenu