audit-second-cerveau

name	audit-second-cerveau
description	Auditer la santé d'un vault second cerveau : écarts entre la doc et la réalité, dossiers qui dérivent, fichiers orphelins, conventions non respectées, contenus périmés. Produit un rapport trié par sévérité + un score /100 + le top 3 des actions. Lecture seule, n'écrit rien. Usage : /audit-second-cerveau [chemin du vault]

Audit second cerveau - santé d'un vault

Audit générique et en lecture seule de la santé d'un vault second cerveau (Obsidian, dossier Markdown, n'importe quelle structure). Le skill n'écrit rien : il lit, il compare, il rapporte. Aucune taxonomie n'est codée en dur - il apprend la structure attendue en lisant la documentation du vault lui-même.

Cible : le vault passé en argument, ou le dossier courant si aucun argument.

Principe

Un vault sain, c'est un vault où la documentation décrit la réalité, où chaque fichier a une place et une raison d'être, et où les conventions tiennent dans la durée. L'audit mesure l'écart entre l'intention déclarée (la doc) et l'état réel (les fichiers).

Étape 1 : Apprendre la structure déclarée

Lire la documentation que le vault donne sur lui-même, dans cet ordre de priorité :

• les fichiers d'instructions (CLAUDE.md, AGENTS.md, .cursorrules, etc.) à la racine et dans les sous-dossiers ;
• les index et sommaires (README.md, INDEX.md, MOC, notes "carte du dossier") ;
• tout fichier qui décrit la taxonomie, les conventions de nommage, le format de frontmatter, les règles de rangement.

But : reconstituer la structure attendue (quels dossiers, quels rôles, quelles conventions) telle que le vault la déclare. Ne présuppose rien : si le vault ne déclare pas de convention, ne l'invente pas.

Étape 2 : Inventorier le réel

• Cartographier l'arborescence réelle (dossiers + fichiers) avec Glob.
• Pour la fraîcheur, relever les dates de dernière modification. Si le vault est un repo git, git log -1 --format=%cs -- <fichier> est plus fiable que la mtime du système de fichiers ; sinon utiliser la mtime.
• Repérer les liens internes (wikilinks [[...]], liens Markdown relatifs) pour savoir quels fichiers sont reliés.

Travailler par échantillon raisonné si le vault est gros (lire intégralement les fichiers d'index et un échantillon représentatif par dossier), pas fichier par fichier exhaustivement.

Étape 3 : Exécuter les 5 checks

Check 1 - Structure vs documentation (sévérité : error/warning)

Écarts entre ce que la doc décrit et ce qui existe :

• dossier/fichier décrit mais absent (lien mort, référence à un dossier inexistant) -> error ;
• dossier/fichier présent mais non décrit (n'apparaît dans aucune doc/index) -> warning.

Check 2 - Dossiers qui dérivent (sévérité : warning)

• chevauchements de rôles (deux dossiers qui semblent faire la même chose) ;
• dossiers fourre-tout (divers, temp, notes, à trier qui gonflent) ;
• taxonomie floue (un dossier dont le rôle déclaré ne correspond plus à son contenu réel).

Check 3 - Fichiers orphelins (sévérité : warning/suggestion)

Fichiers non reliés (aucun wikilink/lien entrant ni sortant) et absents de tout index. Un fichier isolé et non rangé est invisible à l'usage.

Check 4 - Conventions non respectées (sévérité : warning/info)

Uniquement les conventions déclarées par le vault (étape 1) :

• nommage (kebab-case, préfixe de date, casse) ;
• frontmatter requis (champs manquants) ;
• format de date ;
• toute règle locale écrite dans un CLAUDE.md/README.md.

Check 5 - Fraîcheur (sévérité : info/suggestion)

• zones (dossiers/fichiers) non touchées depuis longtemps alors qu'elles devraient vivre ;
• contenus marqués "à jour" mais dont la source est ancienne ;
• documents périmés (statut draft resté tel quel depuis longtemps, TODO jamais résolus).

Étape 4 : Calculer le score /100

Grille pondérée, transparente (affiche le détail par catégorie) :

Catégorie	Poids	Comment l'estimer
Conformité structure <-> doc	30	part des éléments où doc et réalité coïncident (check 1)
Clarté de la taxonomie	20	20 moins une pénalité par dossier qui dérive (check 2)
Reliure (anti-orphelins)	20	part des fichiers reliés ou indexés (check 3)
Conventions respectées	15	part des fichiers conformes aux conventions déclarées (check 4)
Fraîcheur	15	part des zones à jour vs périmées (check 5)

Le score est une estimation défendable, pas une mesure exacte : montre toujours le calcul par catégorie pour qu'il soit vérifiable et discutable.

Étape 5 : Produire le rapport

## Audit second cerveau - {nom du vault} - {date}

**Fichiers** : {N} | **Dossiers** : {M}

### Errors ({count})
- {problème + chemins concernés}

### Warnings ({count})
- {problème + chemins concernés}

### Suggestions ({count})
- {opportunité + action recommandée}

### Info ({count})
- {observation}

### Score de santé : {X}/100
- Conformité structure/doc : {a}/30
- Clarté taxonomie : {b}/20
- Reliure : {c}/20
- Conventions : {d}/15
- Fraîcheur : {e}/15

### Top 3 des actions
1. {action la plus impactante}
2. {action suivante}
3. {action suivante}

Règles

• Lecture seule, strict. N'écris, ne renomme, ne déplace, ne régénère aucun fichier. Si l'utilisateur veut appliquer une correction, il le fera lui-même.
• Apprends la structure du vault par sa doc ; ne plaque jamais une taxonomie générique.
• Priorise errors > warnings > suggestions > info.
• Si le vault est sain (moins de 3 problèmes mineurs), dis-le simplement - pas besoin d'un rapport gonflé.
• Pas d'emojis.