COMPÉTENCE PRINCIPALE CLAUDE.md (Créer/Mettre à jour/Améliorer)

--- name: claude-md-master description: Compétence maître pour le cycle de vie de CLAUDE.md - créer, mettre à jour, améliorer avec du contenu vérifié dans le dépôt et support multi-modules. À utiliser lors de la création ou de la mise à jour de fichiers CLAUDE.md. --- # Maître CLAUDE.md (Créer/Mettre à jour/Améliorer) ## Quand l'utiliser - L'utilisateur demande de créer, améliorer, mettre à jour ou standardiser des fichiers CLAUDE.md. ## Règles de base - N'inclure que des informations vérifiées dans le dépôt ou la configuration. - Ne jamais inclure de secrets, jetons, identifiants ou données utilisateur. - Ne jamais inclure d'instructions spécifiques à une tâche ou temporaires. - Rester concis : racine <= 200 lignes, module <= 120 lignes. - Utiliser des puces ; éviter les longs paragraphes. - Les commandes doivent être copiables-collables et provenir des scripts/docs/CI du dépôt. - Ignorer les sections vides ; éviter le remplissage. ## Entrées obligatoires (analyser avant de générer) - Configuration de build/package pertinente pour la pile détectée (racine + modules). - Configuration d'analyse statique utilisée dans le dépôt (si présente). - Structure réelle des modules et modèles de code source (analyser les répertoires/fichiers réels). - Racines de code source représentatives par module pour extraire : structure des packages/fonctionnalités, types clés et annotations utilisées. ## Découverte (rapide + ciblée) 1. Localiser les variantes CLAUDE.md existantes : `CLAUDE.md`, `.claude.md`, `.claude.local.md`. 2. Identifier la pile et les points d'entrée via des lectures minimales : - `README.md`, `docs/*` pertinents - Fichiers de build/package (voir références de pile) - Exécution/configuration : `Dockerfile`, `docker-compose.yml`, `.env.example`, `config/*` - CI : `.github/workflows/*`, `.gitlab-ci.yml`, `.circleci/*` 3. Extraire les commandes uniquement si elles existent dans les scripts/config/docs du dépôt. 4. Détecter la structure multi-modules : - Android/Gradle : lire les includes de `settings.gradle` ou `settings.gradle.kts`. - iOS : détecter plusieurs cibles/espaces de travail dans `*.xcodeproj`/`*.xcworkspace`. - Si plus d'un module/cible a `src/` ou une configuration de build, planifier des fichiers CLAUDE.md de module. 5. Pour chaque module candidat, lire son fichier de build + documentation minimale pour capturer l'objectif spécifique du module, les points d'entrée et les commandes. 6. Analyser les racines de code source pour : - Dossiers de packages/fonctionnalités de premier niveau et conventions de couches. - Annotations/types clés utilisés (selon la référence de pile). - Conventions de nommage utilisées dans le codebase. 7. Capturer les flux de travail/pièges non évidents à partir des docs ou des modèles de code. Performance : - Privilégier la liste des fichiers + lectures ciblées. - Éviter les lectures complètes de fichiers lorsqu'une section ou un symbole suffit. - Ignorer les grands répertoires : `node_modules`, `vendor`, `build`, `dist`. ## Références spécifiques à la pile (Modèle 2) Lire la référence pertinente uniquement lorsque des signaux de détection apparaissent : - Android/Gradle → `references/android.md` - iOS/Xcode/Swift → `references/ios.md` - PHP → `references/php.md` - Go → `references/go.md` - React (web) → `references/react-web.md` - React Native → `references/react-native.md` - Rust → `references/rust.md` - Python → `references/python.md` - Java/JVM → `references/java.md` - Outillage Node → `references/node.md` - .NET/C# → `references/dotnet.md` - Dart/Flutter → `references/flutter.md` - Ruby/Rails → `references/ruby.md` - Elixir/Erlang → `references/elixir.md` - C/C++/CMake → `references/cpp.md` - Autre/Inconnu → `references/generic.md` (repli lorsqu'aucune référence spécifique ne correspond) Si plusieurs piles sont détectées, lire plusieurs références. Si aucune pile n'est reconnue, utiliser la référence générique. ## Politique de sortie multi-modules (obligatoire lorsqu'elle est détectée) - Toujours créer un `CLAUDE.md` racine. - Créer également `CLAUDE.md` dans chaque racine de module/cible significatif. - "Significatif" = possède sa propre configuration de build et `src/` (ou équivalent). - Ignorer les répertoires uniquement outillage comme `buildSrc`, `gradle`, `scripts`, `tools`. - Le fichier de module doit être spécifique au module et éviter la duplication : - Inclure l'objectif, les chemins clés, les points d'entrée, les tests du module et les commandes du module (si présentes). - Référencer les informations partagées via `@/CLAUDE.md`. ## Politique CLAUDE.md des modules métier (toutes piles) Pour les répertoires de logique métier en monorepo (`src/`, `lib/`, `packages/`, `internal/`) : - Créer `CLAUDE.md` pour les modules avec >5 fichiers OU leur propre README - Ignorer les répertoires uniquement utilitaires : `Helper`, `Utils`, `Common`, `Shared`, `Exception`, `Trait`, `Constants` - La structure en couches n'est pas requise ; fournir les informations du module quelle que soit l'architecture - Maximum 120 lignes par CLAUDE.md de module - Référencer la racine via `@/CLAUDE.md` pour l'architecture/modèles partagés - Inclure : objectif, structure, classes clés, dépendances, points d'entrée ## Sections de sortie obligatoires (par CLAUDE.md de module) Inclure ces sections si elles sont détectées dans le codebase (ignorer uniquement si absentes) : - **Inventaire des fonctionnalités/composants** : lister les répertoires de premier niveau sous la racine du code source - **Modules de base/partagés** : répertoires de code utilitaire, commun ou partagé - **Structure de navigation/routage** : graphes de navigation, routes ou routeurs - **Modèle de couche réseau/API** : clients API, points de terminaison, wrappers de réponse - **Modèle d'injection de dépendances (DI)** : modules, conteneurs ou configuration d'injection - **Fichiers de build/config** : configurations spécifiques au module (proguard, manifests, etc.) Voir les références spécifiques à la pile pour les modèles exacts à détecter et à rapporter. ## Flux de travail de mise à jour (à suivre) 1. Proposer uniquement des ajouts ciblés ; montrer les diffs par fichier. 2. Demander l'approbation avant d'appliquer les mises à jour : **IDE Cursor :** Utiliser l'outil AskQuestion avec ces options : - id : "approval" - prompt : "Appliquer ces mises à jour CLAUDE.md ?" - options : [{"id": "yes", "label": "Oui, appliquer"}, {"id": "no", "label": "Non, annuler"}] **Claude Code (Terminal) :** Afficher les modifications proposées et demander : "Approuvez-vous ces mises à jour ? (oui/non)" S'arrêter et attendre la réponse de l'utilisateur avant de continuer. **Autres environnements (Repli) :** Si aucun outil de question structuré n'est disponible : 1. Afficher clairement les modifications proposées 2. Demander : "Approuvez-vous ces mises à jour ? Répondez 'oui' pour appliquer ou 'non' pour annuler." 3. Attendre la confirmation explicite de l'utilisateur avant de continuer 3. Appliquer les mises à jour, en préservant le contenu personnalisé. Si aucun CLAUDE.md n'existe, proposer un nouveau fichier pour approbation. ## Règles d'extraction de contenu (obligatoires) - Uniquement à partir du codebase : - Extraire : noms de types/classes/annotations utilisés, modèles de chemins réels, conventions de nommage. - Jamais : valeurs codées en dur, secrets, clés API, logique spécifique au métier. - Jamais : extraits de code dans les règles À faire/À ne pas faire. ## Vérification avant écriture - [ ] Chaque règle référence des types/chemins réels du codebase - [ ] Aucun exemple de code dans les sections À faire/À ne pas faire - [ ] Les modèles correspondent à ce qui est réellement dans le codebase (pas obsolète) ## Règles de contenu - Inclure : commandes, résumé d'architecture, chemins clés, tests, pièges, particularités de flux de travail. - Exclure : meilleures pratiques génériques, informations évidentes, déclarations non vérifiées. - Utiliser les imports `@path/to/file` pour éviter la duplication. - Le format À faire/À ne pas faire est facultatif ; ne le conserver que s'il est déjà utilisé dans le fichier. - Éviter les exemples de code sauf les courtes commandes copiables-collables. ## Stratégie pour fichiers existants Détection : - Si `<!-- Generated by claude-md-editor skill -->` existe → exécution ultérieure - Sinon → première exécution Première exécution + fichier existant : - Sauvegarder `CLAUDE.md` → `CLAUDE.md.bak` - Utiliser `.bak` comme source et extraire uniquement les informations réutilisables et spécifiques au projet - Générer un nouveau fichier concis et ajouter le marqueur Exécution ultérieure : - Préserver les sections et formulations personnalisées sauf si obsolètes ou incorrectes - Mettre à jour uniquement ce qui entre en conflit avec l'état actuel du dépôt - Ajouter les sections manquantes uniquement si elles apportent une réelle valeur Ne jamais modifier `.claude.local.md`. ## Sortie Après les mises à jour, imprimer un rapport concis : ``` ## Rapport de mise à jour CLAUDE.md - /CLAUDE.md [CRÉÉ | SAUVEGARDÉ+CRÉÉ | MIS À JOUR] - /<module>/CLAUDE.md [CRÉÉ | MIS À JOUR] - Sauvegardes : lister les fichiers `.bak` ``` ## Liste de contrôle de validation - La description est spécifique et inclut les termes de déclenchement - Aucun espace réservé restant - Aucun secret inclus - Les commandes sont réelles et copiables-collables - Règle du rapport d'abord respectée - Les références sont à un niveau de profondeur