wesammustafa/Claude-Code-Everything-You-Need-to-Know

Révision de CLAUDE.md

Auditez un CLAUDE.md par rapport aux modes d'échec qui coûtent réellement la qualité des résultats.

Prémisse : CLAUDE.md est chargé dans le contexte à chaque session, donc chaque ligne doit soit payer un loyer, soit vous coûter des tokens à chaque tour, pour toujours. La plupart des problèmes du type "le modèle ne suit pas les instructions" sont en réalité des problèmes d'instructions.

Étapes

1. Lisez le fichier cible (par défaut ./CLAUDE.md ; vérifiez aussi ~/.claude/CLAUDE.md et tout **/CLAUDE.md imbriqué si le projet en a, car le plus proche l'emporte).
2. Notez chaque dimension ci-dessous et citez les lignes spécifiques qui échouent.
3. Produisez le format de rapport en bas. Proposez des réécritures concrètes, pas "envisagez d'être plus spécifique".

Que vérifier

Spécificité — la dimension au plus fort levier.

• Signalez les directives invérifiables : "écrivez un code propre", "suivez les bonnes pratiques", "soyez prudent", "utilisez des noms corrects".
• Chaque règle doit pouvoir être vérifiée en lisant un diff. "Refactorisez les fonctions de plus de 40 lignes" est vérifiable ; "gardez les fonctions courtes" ne l'est pas.

Ancres nommées.

• Les règles qui font référence à "la config", "notre couche API", ou "le schéma habituel" forcent une redécouverte à chaque session. Remplacez par des chemins réels : src/config/env.ts, src/api/client.ts.
• Vérifiez que chaque chemin, commande et nom de fichier mentionné existe toujours. Signalez ceux qui sont morts — un CLAUDE.md pointant vers un fichier supprimé induit activement en erreur.

Obsolescence.

• Numéros de version, noms de modèles et commandes d'outils qui ne correspondent plus au dépôt.
• Instructions pour un framework, un script ou un répertoire qui a été supprimé depuis.
• Recoupez les commandes de build/test/lint avec package.json, Makefile, pyproject.toml ou équivalent — une mauvaise commande de test est pire que pas de commande.

Gonflement et loyer.

• Tout ce qui peut être dérivé du code lui-même (listes d'arborescence de fichiers, listes de dépendances, redite de ce que fait une fonction). Claude peut lire le dépôt.
• Les longues procédures qui ne s'appliquent qu'à une tâche occasionnelle : elles appartiennent à une compétence (skill), dont le corps se charge uniquement lorsqu'elle est utilisée, plutôt que d'être dans le contexte à chaque tour.
• Les conseils génériques qui s'appliquent à tous les logiciels et qui n'apprennent donc rien sur ce projet.

Conflits.

• Règles qui se contredisent, ou qui contredisent ce que le code fait réellement. Signalez les deux côtés et demandez lequel l'emporte.
• Surprises de précédence : un CLAUDE.md imbriqué ou ~/.claude/CLAUDE.md qui écrase ce que l'auteur attend.

Ce qui manque. Les lacunes qui valent la peine d'être signalées, si absentes :

• Comment exécuter les tests, builder et linter — les trois choses nécessaires pour auto-vérifier un changement.
• Contraintes non évidentes du projet (un répertoire qui ne doit pas être touché, un fichier généré, une étape de migration requise).
• Conventions qui sont véritablement surprenantes et non visibles à la lecture rapide du code.

Format de sortie

## Révision de CLAUDE.md — <chemin> (<N> lignes)

**Verdict :** <une phrase>

### Bloquant
- L<n> : <ligne citée> → <réécriture concrète>

### À corriger
- L<n> : <ligne citée> → <réécriture concrète>

### Supprimer (coûte du contexte à chaque session, ne rapporte rien)
- L<n>–<m> : <quoi et pourquoi>

### Manquant
- <lacune> → <ligne suggérée à ajouter>

**Taille estimée après modifications :** <N> lignes (depuis <M>)

Règles

• Citez les vrais numéros de ligne et le vrai texte. N'inventez jamais un constat pour remplir une section.
• Si une section n'a aucun constat, écrivez Aucun. — un fichier propre est un résultat valide.
• Privilégiez la suppression à la réécriture. Le meilleur CLAUDE.md est assez court pour que les gens le lisent.
• Ne modifiez pas le fichier sauf demande explicite. Rapportez d'abord.