Sélecteur de modèles CLAUDE.md

Que fait Sélecteur de modèles CLAUDE.md ?

Aide un utilisateur ayant un niveau de codage « débutant opérationnel » (sait suivre des commandes, ne diagnostique pas les pannes, a besoin d'explications sans jargon technique implicite) à décider quel(s) modèle(s) .md copier dans le dossier d'un projet spécifique de Claude Code, et pourquoi. Le projet peut être technique (app, script, site web) ou non technique (scénario, production audiovisuelle, écriture, recherche).

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

Ne présumez pas des noms de fichiers et ne réutilisez pas un inventaire effectué précédemment dans la même conversation. La collection de modèles du Projet peut changer entre un projet et le suivant (l'utilisateur peut ajouter, supprimer ou remplacer des fichiers à tout moment). C'est pourquoi, chaque fois qu'un nouveau projet est analysé, revérifiez ce qui est réellement disponible maintenant, même si vous l'avez déjà fait plus tôt dans cette conversation.

1. Utilisez project_knowledge_search ou examinez les fichiers du Projet pour lister les .md 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 Projet, 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 conversation (nouveaux fichiers, fichiers disparus), 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 pour le code de l'outil et pour le contenu narratif qui va dedans

Cela peut être déduit de la façon dont l'utilisateur décrit le projet ; si ce n'est pas clair, demandez en donnant les trois options, pas seulement deux. Forcer un projet mixte dans « technique » ou « non technique » perd de l'information réelle : la moitié des questions obligatoires (stack technique, ou outils d'écriture) serait perdue selon la case choisie, et les deux moitiés sont nécessaires ici.

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), recherchez-le avec web_search_fast avant de continuer. Ne présumez pas de sa fonction à partir du nom ni ne le traitez comme générique. Le résultat de cette recherche doit informer la façon dont 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 la génération du fichier a commencé), ne modifiez pas le fichier existant avec des changements partiels. Les modèles diffèrent en structure, pas seulement en contenu (regroupement de règles, sections présentes ou absentes, noms de paragraphe), donc un patch à moitié laisse des mélanges incohérents. Au lieu de cela :

1. Confirmez explicitement ce qui change entre le modèle précédent et le nouveau (quelles sections sont réorganisées, lesquelles apparaissent ou disparaissent), pour qu'il soit clair que ce n'est pas un changement cosmétique
2. Jetez le fichier généré avec la décision précédente s'il existait déjà en tant que fichier (supprimez-le, ne le laissez pas comme résidu)
3. Régénérez le fichier complet à partir de 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, espaces déjà remplis), 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 spécifique dans cette même conversation) :

1. Existe-t-il déjà un CLAUDE.md dans le dossier de ce projet ? Oui / Non / Je ne sais pas
2. Va-t-il être maintenu actif pendant des semaines/mois, ou est-ce ponctuel/expérimental ?
3. Selon le type de projet :
   • Technique : stack technique (framework, langage) — s'il ne le sait pas, c'est une réponse valide, ne le forcez pas
   • Non technique : outils et format de travail (par exemple : Fountain, Final Draft, Google Docs, Word, dossiers d'Obsidian, feuilles de calcul de production) — de même, « je ne sais pas » est valide
   • Mixte : les deux questions, la technique et celle des outils/format. Elles ne se substituent pas l'une à l'autre — le projet a besoin des deux réponses. Demandez aussi si, pendant la construction de l'outil propre, 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 à la première réponse si le projet comporte plusieurs phases de travail distinctes (par exemple : un outil pour la recherche/le lore et un autre distinct 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 (développement narratif avec recherche + écriture, production avec préproduction + tournage + postproduction, etc.), demandez explicitement s'il y a un autre outil à part pour l'autre phase, au lieu de supposer qu'un seul outil couvre tout le 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 son nom, dans la conversation actuelle. Les réponses données pour un projet différent ne sont jamais extrapolées, même si elles semblent générales (par exemple, « Je maintiens mes projets pendant des mois » dit pour le Projet A ne s'applique pas automatiquement au Projet B).

Si des données spécifiques manquent pour remplir le CLAUDE.md et qu'elles ne figurent pas dans ce que l'utilisateur a déjà partagé, demandez-les. Ne les inventez pas. Exemples de ce qu'il faut demander selon le type :

• Technique : point d'entrée, commandes de test/lint, conventions de style, structure de dossiers
• Non technique : structure de dossiers/documents du projet, conventions de format (numérotation des scènes, nomenclature des versions), comment le travail est révisé ou validé (lecture à voix haute, révision de continuité, passage par un collaborateur)

Règles de décision

• 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'ailleurs, ou comporte des espaces non remplis (marqueurs comme [PENDANT], placeholders incomplets). Dans ce cas, il convient d'utiliser le guide de migration disponible dans le Projet (s'il y en a un) pour le faire passer au modèle choisi, en préservant le contenu spécifique de l'utilisateur
  • Déjà vérifié par Claude Code par rapport au dépôt réel : le fichier contient des détails techniques extraits directement du code (conventions observées dans des 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). Exemple concret : un projet avec son propre système de « knowledge graph » (outil de type graphify) 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 genre 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 et il ne peut pas être reconstruit sans inspecter à nouveau le dépôt. Signe de cela : précision et spécificité qui seraient impossibles à produire sans avoir lu le dépôt. Dans ce cas, n'imposez pas la structure d'un nouveau modèle par-dessus. Ce contenu a plus de valeur 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 si la fusion vers le modèle choisi est effectuée (sections ou détails techniques sans équivalent dans le modèle) et ce qu'il gagnerait (structure d'historique, memory bank, etc., s'il ne les a pas déjà), et laissez-le décider s'il veut une fusion sélective (ajouter uniquement les pièces qui lui manquent, comme l'historique de développement, sans toucher au reste) ou laisser tel quel
  • En cas de doute sur lequel des deux cas correspond à un CLAUDE.md préexistant, demandez à l'utilisateur plutôt que de présumer
• CLAUDE.md préexistant n'existe pas → 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 → priorisez le modèle le plus compact disponible, sans besoin de demander plus
• Projet nouveau ou petit, mais avec maintenance prévue pour des semaines/mois → c'est un cas de signaux contradictoires (« nouveau » pousse vers le compact, « maintenance longue » pousse vers le modèle 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 spécifique avant de recommander
• Maintenance semaines/mois → ajoutez le modèle d'historique de développement, s'il en existe un dans la collection (l'historique s'applique également aux projets non techniques : par exemple, décisions de scénario, changements de structure narrative, jalons de production)
• Maintenance ponctuelle/expérimentale → ne proposez pas d'historique de développement
• Docs spécifiques de plateforme/infrastructure (Cloudflare, Convex, bases de données, auth, etc.) → ne s'appliquent 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 (par exemple, un doc Cloudflare peut couvrir Workers, D1, KV, R2, Queues, Workers AI, Sandbox, Containers, et des guides de déploiement pour plusieurs frameworks). Avant de décider, identifiez les services concrets que le projet utilise réellement
  • 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 (par exemple, seulement le déploiement statique)
  • Si le projet utilise un ou plusieurs services réels du document, mais que le document couvre plus de services que ceux utilisés par le projet → 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 (même si elles sont dans le même fichier). Dites-le explicitement à l'utilisateur : quelles sections ont été incluses et lesquelles ont été laissées de côté, et pourquoi
  • Ne copiez le document complet sans le réduire que 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 bon (révision de continuité, lecture à voix haute, passage par un collaborateur, checklist de production)
Code Style & Conventions	Conventions de format et de style (numérotation des scènes, nomenclature des versions de document, structure de dossiers)
Architecture	Structure du projet (dossiers, documents clés, ordre des parties)

Les sections Core Rules, Memory Bank et Development History restent conceptuellement identiques (rechercher avant d'affirmer, ne pas sortir du cadre demandé, historique des décisions), seul le domaine d'exemple change dans chacune.

Composer le CLAUDE.md pour les projets mixtes

Ne choisissez pas un seul modèle de section : combinez les deux. Le CLAUDE.md d'un projet mixte nécessite :

• Tech Stack (technique) ET Outils/format pour le contenu créatif (non technique) comme deux entrées séparées dans Project Overview, non fusionnées en une seule ligne ambiguë
• Build, Test & Verify avec les commandes réelles de code, sans traduire en vocabulaire non technique — cela reste un logiciel réel qui se compile et se teste
• Une section supplémentaire (peut s'appeler « Contenu et décisions créatives » ou similaire) pour ce qui, dans un projet non technique, figurerait dans « Comment vérifier que quelque chose est bon » — critères de révision du contenu narratif/créatif que l'outil va héberger, si l'utilisateur les a
• Si l'utilisateur continue d'utiliser un outil externe en parallèle pendant la construction de sa propre app, notez-le explicitement et marquez-le comme temporaire (« en attendant le développement de la fonctionnalité équivalente dans l'app propre »). Cela ne doit pas rester une note statique sans suivi : dans le point de contrôle de « création d'une entrée d'historique » (voir la section Development History), chaque fois qu'une entrée est enregistrée...