Générateur de CLAUDE.md
Analyse le code source. Écris un fichier CLAUDE.md qui dit exactement ce dont Claude a besoin : ni plus, ni moins.
Règle cruciale : Un bon CLAUDE.md fait moins de 100 lignes. Il ne contient que les informations que Claude ne peut pas déduire en lisant le code lui-même. N'écris pas le fichier automatiquement : affiche toujours le brouillon et attends l'approbation de l'utilisateur d'abord.
Règle des extraits de code : N'inclus jamais d'exemples de code en ligne dans CLAUDE.md. Utilise plutôt des références comme fichier.ts:42. Le code dans CLAUDE.md gaspille des tokens et devient obsolète.
Étape 1 : Détection du mode
Détermine lequel des trois modes exécuter :
create : Aucun fichier CLAUDE.md n'existe. Écris-en un à partir de rien. update : Un fichier CLAUDE.md existe. Améliore-le sans supprimer le contenu personnalisé. audit : Note tous les fichiers CLAUDE.md du projet de A à F et produit un rapport de qualité. Si l'utilisateur dit « auditer », « vérifier », « revoir » ou « noter » mon CLAUDE.md, exécute le mode audit.
# Découvrir TOUS les emplacements de CLAUDE.md
find . -name "CLAUDE.md" -not -path "*/node_modules/*" -not -path "*/.git/*" 2>/dev/null
ls ~/.claude/CLAUDE.md 2>/dev/null && echo "CLAUDE.md global trouvé"
ls .claude.local.md 2>/dev/null && echo ".claude.local.md trouvé"
Si plusieurs fichiers CLAUDE.md sont trouvés : liste-les. Demande : « CLAUDE.md trouvé dans [emplacements]. Dois-je tous les mettre à jour ou seulement [racine] ? »
Étape 2 : Mode audit (passe à l'étape 3 si create/update)
Pour chaque CLAUDE.md trouvé, note-le de A à F en utilisant cette grille :
| Critère | Que vérifier |
|---|---|
| Commandes | Les commandes de build/test/lint sont-elles présentes et exécutables ? |
| Architecture | La structure non évidente est-elle expliquée ? |
| Motifs non évidents | Les pièges, fichiers générés, variables d'env ordre sont-ils documentés ? |
| Concision | Moins de 100 lignes ? Pas de remplissage évident ? |
| Actualité | Les commandes correspondent-elles toujours au package.json/Makefile actuel ? |
| Actionnabilité | Un nouveau contributeur peut-il suivre cela sans poser de questions ? |
Score : 90-100 = A, 70-89 = B, 50-69 = C, 30-49 = D, 0-29 = F
Présente sous forme de tableau :
## Rapport d'audit CLAUDE.md
| Fichier | Score | Note | Problèmes principaux |
|---------|-------|------|----------------------|
| ./CLAUDE.md | 72 | B | Section pièges manquante, commande de test obsolète |
| ./packages/api/CLAUDE.md | 45 | D | Aucune commande, 340 lignes (trop long), notes archi obsolètes |
**Global : B (72/100)**
Problèmes trouvés :
- ./packages/api/CLAUDE.md : 340 lignes : bien au-dessus de l'objectif de 100 lignes
- ./packages/api/CLAUDE.md : La commande de test fait référence à `jest` mais package.json utilise `vitest`
- ./CLAUDE.md : Pas de section Pièges : la section la plus précieuse manque
Après le rapport, demande : « Veux-tu que je corrige certains de ces fichiers ? (tous / juste la racine / précise) »
Si l'utilisateur répond oui, continue à l'étape 3 pour chaque fichier qu'il souhaite corriger.
Étape 3 : Analyse de la structure du projet
# Type de projet et gestionnaire de paquets
ls package.json yarn.lock pnpm-lock.yaml bun.lockb requirements.txt pyproject.toml Cargo.toml go.mod 2>/dev/null
# Structure des répertoires de premier niveau
find . -maxdepth 2 -type d \
| grep -v node_modules | grep -v .git | grep -v __pycache__ \
| grep -v ".next" | grep -v dist | grep -v build | sort
Étape 4 : Extraction des commandes de build et de test
# Scripts npm/yarn/pnpm/bun
cat package.json 2>/dev/null \
| python3 -c "
import sys, json
d = json.load(sys.stdin)
for name, cmd in d.get('scripts', {}).items():
print(f'{name}: {cmd}')
"
# Makefiles Python, Go, Rust
cat Makefile 2>/dev/null | grep -E "^[a-z].*:" | head -20
# Go
cat go.mod 2>/dev/null | head -5
# Rust
cat Cargo.toml 2>/dev/null | grep -E "^\[" | head -10
Identifie les commandes exactes pour : build, test (tous), test (un seul fichier/nom), serveur de développement, lint/typecheck. Note les variables d'environnement nécessaires pour les exécuter.
Étape 5 : Trouver le style de code et les pièges
# Alias d'import (les plus souvent oubliés)
python3 -c "
import json, sys
try:
d = json.load(open('tsconfig.json'))
paths = d.get('compilerOptions', {}).get('paths', {})
if paths: print('Alias d\'import :', json.dumps(paths, indent=2))
except: pass
" 2>/dev/null
# Variables d'environnement requises
cat .env.example 2>/dev/null | grep -v "^#" | grep -v "^$" | head -20
# Fichiers auto-générés (ne doivent pas être modifiés)
find . -path "*/node_modules" -prune -o -name "*.ts" -print \
| xargs grep -l "DO NOT EDIT\|@generated\|Generated by" 2>/dev/null | head -5
# Configuration de test
cat jest.config.js jest.config.ts vitest.config.ts 2>/dev/null | head -30
# Configuration de base de données/migration
ls migrations/ prisma/ drizzle/ db/ 2>/dev/null
Ce qui compte comme un piège (inclus ceux-ci, ignore tout le reste) :
- Fichiers générés automatiquement (à ne pas modifier)
- Variables d'environnement requises AVANT l'exécution des tests
- Mappages d'alias d'import non par défaut
- Commandes de test qui nécessitent un service en cours
- Bizarreries intentionnelles connues (solutions de contournement, pas des bugs)
Étape 6 : Générer un brouillon de CLAUDE.md avec Gemini
Compile tous les résultats et génère le brouillon :
cat > /tmp/claude-md-request.json << 'ENDJSON'
{
"system_instruction": {
"parts": [{
"text": "Écris un fichier CLAUDE.md pour un projet logiciel. Règles : (1) Moins de 100 lignes au total. (2) Inclus uniquement ce que Claude ne peut pas déduire en lisant le code. (3) Pas d'exemples de code en ligne : utilise des références comme fichier.ts:42 à la place. (4) Sections : Commandes, Style de code (uniquement les non-par défaut), Tests (uniquement si une configuration est nécessaire), Pièges (obligatoire : ce qui pose problème aux gens). Ignore toute section qui n'a rien de non évident à dire. (5) Toutes les commandes dans des blocs de code. (6) Ordre préféré : court Aperçu du projet (1-2 phrases, uniquement si non évident), Commandes, Architecture (uniquement structure non évidente), Style de code, Tests, Pièges. (7) N'utilise pas de tirets cadratins. (8) Produis uniquement le contenu de CLAUDE.md, aucun commentaire."
}]
},
"contents": [{
"parts": [{
"text": "ANALYSE_DU_PROJET_ICI"
}]
}],
"generationConfig": {
"temperature": 0.3,
"maxOutputTokens": 2048
}
}
ENDJSON
curl -s -X POST \
"https://generativelanguage.googleapis.com/v1beta/models/gemini-2.0-flash:generateContent?key=$GEMINI_API_KEY" \
-H "Content-Type: application/json" \
-d @/tmp/claude-md-request.json \
| python3 -c "import sys,json; d=json.load(sys.stdin); print(d['candidates'][0]['content']['parts'][0]['text'])"
Remplace ANALYSE_DU_PROJET_ICI par les résultats des étapes 3 à 5.
Pour les grands projets (50+ fichiers) : Ajoute un pointeur @path en bas de CLAUDE.md au lieu des détails en ligne :
## Référence étendue
Voir @docs/ai-context/architecture.md pour la carte complète des modules.
Voir @docs/ai-context/testing.md pour les détails de configuration des tests d'intégration.
Écris les fichiers référencés dans docs/ai-context/ avec les détails qui ne tiendraient pas dans 100 lignes.
Étape 7 : Auto-vérification
Avant de présenter le brouillon, vérifie :
- Moins de 100 lignes (compte :
echo "$CONTENU" | wc -l) - Pas d'exemples de code en ligne (uniquement des références
fichier.ts:42ou des commandes shell) - Toutes les commandes dans des blocs de code et exécutables telles quelles
- Section Pièges présente avec au moins une entrée réelle
- Aucune section qui ne dit que des choses évidentes à partir des fichiers
- Pas de tirets cadratins
- Pas de mots marketing ou de phrases de remplissage (« Ce projet utilise React pour... »)
- Alias d'import documentés s'ils existent
- Fichiers générés automatiquement marqués « ne pas modifier » s'ils existent
Si un contrôle échoue, révise avant de présenter.
Étape 8 : Présenter le brouillon et attendre l'approbation
N'écris jamais le fichier sans l'approbation de l'utilisateur.
Présente le brouillon dans un bloc de code :
## Brouillon CLAUDE.md ([N] lignes)
[contenu complet du brouillon ici]
---
Écrire ceci dans CLAUDE.md ? (oui / modifier d'abord / annuler)
Si l'utilisateur dit oui : écris le fichier, puis confirme : « CLAUDE.md écrit ([N] lignes). Sections : [liste des ## en-têtes]. »
Si l'utilisateur dit modifier d'abord : applique ses modifications, réaffiche le brouillon.
Si l'utilisateur dit annuler : arrête.
Ce qu'il NE FAUT PAS inclure
- Version du langage/framework (« Ceci est un projet TypeScript »)
- Fonctionnement du framework (Claude connaît déjà React, FastAPI, etc.)
- Liste de toutes les dépendances
- Règles de style que le linter applique déjà (taille d'indentation, style de guillemets)
- Contenu qui duplique README.md
- Exemples de code en ligne ou extraits multi-lignes
- Tout ce qui serait identique pour tout projet utilisant la même pile