---
name: audit-contexte
description: Audite, dégraisse ou crée le fichier CLAUDE.md d'un projet — le socle de contexte lu à chaque session. Utiliser quand l'utilisateur veut auditer, améliorer, raccourcir ou créer un CLAUDE.md (ou fichier équivalent type AGENTS.md).
---

# Audit Contexte — la carte, pas l'entrepôt

Un CLAUDE.md est lu à **chaque** session : chaque ligne est un loyer payé en tokens et en attention. Trop long, l'agent ignore les vraies règles. Un bon CLAUDE.md est un **routeur** : il sait *qui sait*, il ne sait presque rien lui-même.

## Déroulé

1. Cherche `CLAUDE.md` à la racine du projet (sinon `AGENTS.md`, `.cursorrules`, ou équivalent).
2. S'il existe → **mode AUDIT**. Sinon → **mode CRÉATION**.
3. Livre toujours un artefact concret : rapport noté /100 + fichier réécrit proposé (audit), ou fichier neuf < 100 lignes (création). Ne modifie jamais le fichier sans accord explicite.

---

## Mode AUDIT

Lis le fichier en entier. Applique à chaque ligne le test officiel Anthropic : **« si je retire cette ligne, l'agent fera-t-il des erreurs ? »** Si non, elle est candidate à suppression.

Puis évalue les 10 contrôles (10 points chacun) :

### Les 10 contrôles

1. **Commandes non devinables** — Le fichier contient-il les commandes exactes que l'agent ne peut pas deviner (build, deploy avec flags, scripts maison) ? Les commandes standard (`git push`, `npm install`) sont du bruit : à retirer.

2. **Pointeurs, pas copies** — Chaque savoir volumineux (architecture détaillée, liste de fonctions, doc API) doit être un **pointeur vers sa source de vérité** (« le code fait foi », `ls src/functions/`), jamais une copie qui se périme en silence.

3. **Décisions d'architecture + leur pourquoi** — Les choix structurants propres au projet sont-ils énoncés avec leur justification ? (Le *pourquoi* permet à l'agent de généraliser aux cas non prévus.) Les descriptions fichier-par-fichier du code sont interdites : l'agent les découvre seul.

4. **Conventions divergentes uniquement** — Seules les règles qui **divergent des défauts** méritent une ligne (nommage imposé, pattern de sécurité maison). Les conventions standard du langage et les évidences (« écrire du code propre ») sont du bruit.

5. **Gotchas payants** — Les pièges non évidents déjà rencontrés sont-ils notés ? (« le projet Vercel n'est PAS connecté à git », « toujours le flag X sinon 401 silencieux »). Meilleur ratio valeur/ligne du fichier.

6. **Impératifs directs** — Les règles sont-elles écrites en ordres (« TOUJOURS », « Ne PAS »), pas en suggestions ? « IMPORTANT » / « YOU MUST » réservés à 1-2 règles vraiment critiques — sur-utilisés, ils ne signalent plus rien.

7. **Taille** — Viser < 200 lignes. Au-delà, identifier ce qui doit migrer : savoir situationnel → skill (chargée à la demande), doc longue → fichier `.md` lié, règle bloquante → hook ou CI (le CLAUDE.md n'a qu'une valeur indicative).

8. **Zéro donnée volatile** — Aucun statut, deadline, checklist, KPI, compteur. Ces données se figent et deviennent fausses. Remplacer par la commande qui reste vraie (`grep -rn "TODO" src/`) ou par un pointeur vers l'outil qui fait foi.

9. **Zéro secret** — Jamais de valeur de secret. Toujours un pointeur vers l'emplacement (fichier gitignoré, dashboard, variable d'env). Un tableau « nom du secret + usage » sans valeur est le bon niveau.

10. **Hiérarchie respectée** — Racine = navigation + règles transverses. Sous-dossiers = CLAUDE.md enfants chargés à la demande. Pas de duplication entre niveaux : chaque donnée a UN fichier qui fait foi (si deux fichiers peuvent contenir la même info, le CLAUDE.md doit dire lequel fait foi).

### Rapport à produire

```
# Audit CLAUDE.md — {projet}
Score : XX/100 · {N} lignes (cible < 200)

## Ce qui est solide
- ...

## À corriger (par impact décroissant)
1. [contrôle N] constat → correction concrète
2. ...

## Lignes candidates à suppression
- L.XX « ... » — échoue au test « si je la retire »

## Proposition de fichier réécrit
{le CLAUDE.md complet réécrit, prêt à coller}
```

---

## Mode CRÉATION

Pose au maximum 5 questions (une par une) :

1. Quelles commandes exactes pour le build, les tests, le déploiement ? (avec les flags)
2. Quelle décision d'architecture un nouveau venu doit-il connaître, et pourquoi ?
3. Quelles conventions maison divergent des standards ?
4. Quel piège t'a déjà fait perdre plus d'une heure ?
5. Où vivent les secrets (sans les valeurs) ?

Puis génère un CLAUDE.md **< 100 lignes** structuré ainsi : règles agent (3-5 impératifs) → commandes fréquentes (tableau) → architecture + pourquoi → sources de vérité (tableau donnée → fichier qui fait foi) → gotchas. Rien d'autre. Le fichier grossira par l'usage — chaque erreur récurrente de l'agent devient une ligne, chaque ligne jamais utile est supprimée.

---

## Règle finale

Traite le CLAUDE.md **comme du code** : versionné, relu quand l'agent se trompe, élagué régulièrement. Si l'agent viole une règle qui est pourtant écrite, le fichier est probablement trop long — la règle se noie.
