---
name: claude-code-maintenance
description: Audite un setup Claude Code pour repérer les instructions obsolètes, répétées, contradictoires, trop vagues ou inutilement chargées dans le contexte. À utiliser pour un nettoyage périodique ou après une mise à jour importante de modèle.
disable-model-invocation: true
---

# Audit de maintenance Claude Code

Audite mon setup Claude Code. Chaque instruction doit mériter sa place : demande-toi si Claude en a encore besoin et si la supprimer donnerait le même résultat.

## Limite absolue

Travaille en lecture seule jusqu’à ce que j’approuve des recommandations par numéro.

Avant cette approbation, ne modifie, ne déplace, ne renomme et ne supprime aucun fichier ou réglage. N’installe, ne désinstalle, n’active et ne désactive aucun skill, plugin, hook ou serveur MCP. Ne crée pas de commit et ne pousse rien.

Ne révèle jamais la valeur d’une clé API, d’un jeton, d’un mot de passe, d’un cookie ou d’une variable secrète. Signale seulement qu’un réglage sensible existe et où il se trouve.

## Inventaire

Commence par identifier uniquement les sources réellement présentes et accessibles dans ce setup :

- les fichiers CLAUDE.md, CLAUDE.local.md et AGENTS.md qui peuvent se charger ;
- les règles sous `.claude/rules/` et `~/.claude/rules/` ;
- les skills de projet, utilisateur et plugins ;
- la mémoire automatique visible dans `/memory` ;
- les fichiers de réglages et leurs règles de permissions ;
- les hooks configurés et les scripts qu’ils appellent ;
- les serveurs MCP et plugins configurés.

N’invente pas un chemin, une source ou un état que tu ne peux pas vérifier. Si une information n’est visible que dans un menu interactif, indique la commande ou le menu que je dois ouvrir et attends mon retour.

## Contrôles

Pour chaque instruction ou réglage pertinent, vérifie :

1. Est-ce encore exact pour la version actuelle du projet et de Claude Code ?
2. Claude peut-il déduire cette information directement du code ou des fichiers du projet ?
3. La même règle existe-t-elle déjà ailleurs ?
4. Contredit-elle une autre instruction chargée dans le même contexte ?
5. Décrit-elle une préférence durable ou seulement un cas ponctuel ?
6. Est-elle concrète et vérifiable, ou vague et impossible à contrôler ?
7. Mentionne-t-elle un ancien modèle, une ancienne commande ou un ancien contournement ?
8. Une obligation technique serait-elle plus fiable dans un hook ou une permission ?
9. Une procédure occasionnelle serait-elle mieux placée dans un skill ?
10. Une règle liée à certains fichiers devrait-elle devenir une règle ciblée par `paths` ?

Pour les permissions, signale les motifs trop larges et explique précisément leur portée. Pour les hooks, vérifie que la commande ou le script ciblé existe encore. Pour les skills inutilisés, distingue « inutile » de « saisonnier » et demande confirmation quand l’intention n’est pas claire.

## Verdicts

Attribue un seul verdict principal à chaque constat :

- **GARDER** : utile, précis et impossible à déduire autrement ;
- **SUPPRIMER** : faux, dépassé, redondant ou inutilement générique ;
- **FUSIONNER** : doublon partiel à regrouper avec une autre règle ;
- **RÉÉCRIRE** : intention utile, formulation trop vague, agressive ou longue ;
- **DÉPLACER** : meilleure place dans un hook, un skill, une permission ou une règle ciblée ;
- **VÉRIFIER** : preuve insuffisante, décision à confirmer avec moi.

## Rapport

Présente d’abord un résumé court :

- sources inspectées ;
- sources non accessibles ;
- nombre de constats par verdict ;
- principaux risques de contradiction ou de permissions trop larges ;
- économie de contexte approximative en lignes ou en blocs, sans inventer un nombre précis de tokens.

Puis donne les constats numérotés. Pour chacun, inclus :

- le verdict ;
- le chemin et les lignes lorsque cela vient d’un fichier ;
- le texte exact concerné, sauf s’il contient un secret ;
- la raison concrète ;
- la recommandation ;
- le texte de remplacement prêt à utiliser pour une réécriture ou une fusion ;
- la destination exacte proposée pour un déplacement.

Regroupe les doublons ou contradictions dans un seul constat afin que je puisse les approuver ensemble.

Termine par : « Réponds avec les numéros à appliquer. Je ne modifierai rien d’autre. »

## Après mon approbation

Applique uniquement les numéros que j’ai choisis. Si une recommandation devient ambiguë au moment de l’appliquer, arrête-toi et pose une question précise.

Montre ensuite les fichiers modifiés et un résumé du diff. Ne supprime définitivement aucun fichier, ne change aucune permission sensible et ne crée aucun commit sans demande explicite.