Optimisation du contexte IA

Mission

Audite et optimise tout ce qu'un agent IA lit dans ce projet : CLAUDE.md, AGENTS.md, documentation, notes, règles d'agents. Objectif : réduire les tokens consommés à long terme en retirant ce qui est périmé, inutilisé, dupliqué ou superflu, et en réorganisant le reste pour que seul l'essentiel soit chargé à chaque requête, sans perdre d'information utile.

Tu ne lances aucun test de performance et aucune session Claude séparée. Tu travailles à partir des fichiers et du code.

Façon de me poser les questions

Toutes les décisions passent par des questions interactives à choix multiples, avec l'outil de questions (AskUserQuestion). S'il n'est pas disponible, pose des questions numérotées en texte et attends ma réponse.

• •Ta recommandation en premier, marquée « (Recommandé) ».
• •Contexte court dans chaque question : ce qui est concerné, la preuve (« le script build:legacy n'existe plus dans package.json ») et le gain en tokens.
• •Options concrètes, par exemple : « Supprimer », « Déplacer dans docs/ai/ », « Garder tel quel », « Corriger ». J'ai toujours la possibilité de répondre autre chose.
• •Par lots de 1 à 4 questions à la fois, regroupées par thème. N'avance pas au thème suivant avant d'avoir mes réponses.
• •Regroupe ce qui est évident et sans risque (style télégraphique, doublons évidents, éléments périmés prouvés) dans une seule question d'approbation globale. Garde les questions individuelles pour ce qui demande mon jugement.
• •N'applique rien sans réponse de ma part.

Phase 0 — Sécurité et choix git

• 1.Vérifie l'état git du dépôt (git status, branche actuelle).
• 2.Pose-moi une question interactive sur la façon de travailler, avec ces options :
• •« Créer une branche, modifications sans commit (Recommandé) » : tu crées chore/optimisation-contexte-ia et je commite moi-même.
• •« Créer une branche et commiter à la fin » : tu commites seulement après mon accord en Phase 6.
• •« Branche actuelle, modifications sans commit ».
• •« Branche actuelle, commit à la fin ».

Si l'arbre de travail n'est pas propre, indique-le dans la question : mes modifications en cours seront mélangées aux tiennes dans le diff. Recommande alors de travailler sans commit pour ne rien englober par erreur.

• 3.Ne fais jamais de commit, de stash, de reset ni de push sans que je l'aie choisi.
• 4.Ne modifie aucun fichier de code source, seulement les fichiers de contexte, de documentation et de configuration d'agents.

Phase 1 — Inventaire

Liste chaque fichier en indiquant s'il est chargé à chaque requête (coût permanent) ou lu à la demande (coût ponctuel), avec sa taille (wc -c, tokens ≈ caractères / 4) :

• •CLAUDE.md à la racine et dans les sous-dossiers, CLAUDE.local.md, et tout fichier importé via @chemin (un import charge le fichier à chaque requête) ;
• •AGENTS.md, .cursorrules, .cursor/rules/, .github/copilot-instructions.md, .windsurfrules, GEMINI.md, etc. ;
• •.claude/ : commands/, agents/, skills/ (leurs descriptions sont chargées en permanence) et settings.json ;
• •la configuration MCP (.mcp.json, etc.) ;
• •README.md, CONTRIBUTING.md, docs/, ADR, changelogs ;
• •les fichiers de notes : NOTES.md, TODO.md, journaux de session, plans, brouillons, fichiers *.md éparpillés.

Montre-moi un tableau avec quatre colonnes : fichier, type de chargement, tokens estimés, dernière modification (git log -1 --format=%cs -- <fichier>). Pas de question à cette étape, continue.

Phase 2 — Comprendre le projet

À partir des manifestes, de la structure et des scripts, détermine :

• •les langages, framework(s) et outils de build, de test et de lint ;
• •s'il s'agit d'un monorepo ou d'un projet simple ;
• •le type d'application ;
• •les zones où un agent perdrait du temps à chercher : logique dispersée, nommage trompeur, conventions implicites, commandes non standards.

Résume en 3 à 5 lignes. Si un point important est ambigu (par exemple un dossier dont tu ne sais pas s'il est encore utilisé), pose-moi la question.

Phase 3 — Vérifier ce qui est écrit

Pour chaque fichier, vérifie le contenu contre le code réel :

• •Chemins et fichiers mentionnés : existent-ils encore ?
• •Commandes et scripts : existent-ils encore ? Lance ceux qui sont sans risque (--help, lint) pour confirmer.
• •Fonctions, classes, modules, routes, variables d'environnement : sont-ils encore dans le code (grep) ?
• •Outils et dépendances : le projet utilise-t-il encore ce qui est décrit ?
• •Docs et notes : sont-elles référencées quelque part ? Modifiées récemment ? Le code qu'elles décrivent a-t-il beaucoup changé depuis (git log) ?

Marque chaque élément : à jour, périmé (avec la preuve) ou incertain.

Phase 4 — Trier le contenu

Pour chaque bloc, applique le critère central :

> Est-ce que cette information coûte plus cher à redécouvrir qu'à garder ?
> La garder dans un fichier permanent coûte des tokens à chaque requête.
> La redécouvrir coûte la lecture de plusieurs fichiers, des recherches, voire des erreurs.

| Catégorie | Recommandation par défaut |
|---|---|
| Essentiel et coûteux à redécouvrir : commandes non évidentes, pièges, interdictions, conventions non imposées par un outil, setup particulier, emplacement de la logique importante | Garder, en version concise |
| Carte du code : dossiers clés, points d'entrée, modules principaux | Garder ou créer si absente, 5 à 15 lignes |
| Utile mais ponctuel : procédures détaillées, architecture approfondie, guides par domaine, workflows rares | Déplacer dans un fichier lu à la demande |
| Facile à redécouvrir : liste des dépendances, arborescence évidente, règles déjà dans la config du linter | Supprimer |
| Générique : bonnes pratiques que tout modèle connaît | Supprimer |
| Dupliqué | Garder une seule source, référencer ailleurs |
| Périmé | Corriger si le sujet existe encore, sinon supprimer |
| Notes mortes : journaux de session, plans terminés, TODO réglés, brouillons | Supprimer ; résumer en une ligne une décision importante s'il y en a une |
| Instable : dates, état du sprint, tâches en cours | Retirer des fichiers permanents (invalide le cache de prompt) |
| Historique : changelog, anciennes décisions | Retirer du contexte permanent, archiver si utile |

Repère aussi les informations manquantes : les zones de la Phase 2 qu'aucun fichier n'explique.

Stratégies de réorganisation possibles :

• 1.Fichier racine minimal avec l'essentiel, la carte du code et une table « pour X, lire docs/ai/X.md ». Pas de @fichier pour du contenu ponctuel.
• 2.CLAUDE.md imbriqués pour les règles propres à un dossier.
• 3.Source unique entre AGENTS.md, CLAUDE.md, règles Cursor, Copilot, etc.
• 4.Skills ou commandes pour les workflows longs et rares ; descriptions de skills et d'agents raccourcies.
• 5.Style télégraphique.
• 6.Serveurs MCP inutilisés à désactiver.

Phase 5 — Décisions interactives

Commence par un récapitulatif court : tokens chargés en permanence actuellement, estimation après optimisation si tout est accepté, et nombre de décisions à prendre.

Puis pose les questions dans cet ordre, par lots :

• 1.Réorganisation générale : la structure proposée (ex. « CLAUDE.md racine minimal + 3 fichiers dans docs/ai/ + CLAUDE.md imbriqué dans packages/api/ »), et le choix de la source unique si plusieurs fichiers d'instructions coexistent. Propose 2 ou 3 structures si plusieurs sont raisonnables.
• 2.Changements sans risque, en une seule question d'approbation globale avec la liste résumée : style télégraphique, doublons évidents, éléments génériques, éléments périmés prouvés. Options : « Tout appliquer (Recommandé) », « Me montrer le détail d'abord », « Passer ».
• 3.Fichiers entiers à supprimer (notes mortes, docs obsolètes) : une question par fichier, avec sa taille, sa date de dernière modification et la raison.
• 4.Déplacements de contenu vers des fichiers à la demande, regroupés par fichier source.
• 5.Ajouts : carte du code, pièges manquants. Montre le texte proposé dans la question.
• 6.Points incertains : une question par point, en expliquant pourquoi tu hésites. Recommande « Garder » en cas de doute réel.
• 7.Serveurs MCP à désactiver, s'il y en a.

Phase 6 — Application et vérification

Applique uniquement ce que j'ai accepté, puis :

• 1.Contrôle de non-perte. Relis l'ancienne version via git diff et confirme que chaque information utile se retrouve quelque part. Si quelque chose a disparu sans que je l'aie explicitement accepté, signale-le.
• 2.Vérifie que chaque chemin et chaque commande mentionnés dans les nouveaux fichiers existent réellement.
• 3.Affiche le gain : tokens chargés en permanence avant et après, en valeur et en %.
• 4.Termine selon mon choix de la Phase 0 :
• •Sans commit : laisse les modifications dans l'arbre de travail et affiche git status et git diff --stat, plus une proposition de message de commit que je pourrai utiliser.
• •Avec commit : montre le résumé des changements et le message proposé, puis demande une confirmation finale avant de commiter. Ne pousse jamais (git push).

Phase 7 — Entretien

Termine par une dernière série de questions, avec tes recommandations adaptées au projet :

• 1.Taille cible du CLAUDE.md racine (propose une valeur).
• 2.Notes de travail futures : où les mettre pour qu'elles ne s'accumulent pas dans le contexte permanent (ex. dossier ignoré par git, ou suppression à la fin de chaque tâche). Propose d'ajouter la règle dans le fichier racine en une ligne.
• 3.Commande réutilisable : veux-tu enregistrer ce prompt dans .claude/commands/optimiser-contexte.md pour le relancer avec /optimiser-contexte ?
• 4.Fréquence pour relancer l'audit (après une grosse évolution, chaque mois, quand le fichier racine dépasse la taille cible).

Règles

• •En cas de doute sur l'utilité d'une information, recommande de la garder et laisse-moi décider.
• •Une affirmation n'est « périmée » que si tu l'as vérifiée dans le code. N'élimine rien sur une simple impression.
• •Ne fais jamais de commit, de stash, de reset ni de push sans mon choix explicite.
• •Ne réécris pas le ton ni les règles de l'équipe : condense-les.
• •Conserve la langue d'origine des fichiers.
• •N'invente aucune commande ni convention.