Inventaire de TOUS les projets de François présents sur cette machine, obtenu par un scan du disque en direct (aucun fichier de configuration, donc jamais périmé). Renvoie pour chaque projet : son nom, son chemin absolu, s'il est versionné sous git, sa pile technique détectée, son rôle résumé en une phrase (extrait de son CLAUDE.md, sinon de son README) et la liste de ses documents de contexte. Appelle cet outil en premier dès que tu as besoin de savoir ce qui existe en dehors du dépôt courant : l'utilisateur mentionne un projet que tu ne connais pas, tu cherches où vit une fonctionnalité, tu veux vérifier qu'un projet existe encore. N'inclut volontairement ni l'état git (voir etat_git) ni le contenu des documents (voir lire_cerveau), pour rester léger.

Briefing de démarrage à froid : une synthèse markdown compacte de tout l'écosystème de François, projets regroupés par famille, avec pour chacun son rôle, sa pile, sa branche courante et sa dernière activité git. C'est l'outil à appeler au tout début d'une session quand tu arrives dans un dépôt sans contexte et que tu veux comprendre en un seul appel ce que François fabrique, combien de projets il a, lesquels sont vivants et lesquels dorment. Plus dense que lister_projets et déjà mis en forme. Si tu as besoin des données brutes pour les filtrer toi-même, utilise plutôt lister_projets.

Fiche complète d'UN projet : chemin, dépôt distant, pile technique et dépendances marquantes, rôle déduit, état git détaillé, derniers commits, branches, documents de contexte disponibles et arborescence de surface. Utilise cet outil quand tu sais déjà de quel projet tu parles et que tu veux tout savoir dessus d'un coup, avant d'aller lire ses fichiers ou de conseiller François sur ce projet. Pour lire vraiment le contenu de son CLAUDE.md ou de son README, enchaîne avec lire_cerveau.

Lit le contenu des documents de contexte d'un projet : son CLAUDE.md, son .claude/CLAUDE.md, son AGENTS.md, son README, son ARCHITECTURE.md, et sur demande n'importe quel autre markdown de ses dossiers docs, notes, références ou .claude. C'est ainsi que tu apprends comment François pense un projet donné : ses conventions, sa pile, ses règles d'écriture, ses pièges connus, sans qu'il ait à te les redire. Par défaut, seuls les documents prioritaires sont retournés, tronqués pour ne pas saturer ton contexte. Pour un document précis, passe son chemin relatif dans « fichier ». Pour connaître les documents disponibles sans les lire, mets « lister_seulement » à true. Lecture seule : cet outil n'écrit jamais dans les dépôts.

État git en direct, lu au moment de l'appel : branche courante, dernier commit avec sa date et son auteur, nombre de fichiers modifiés non commités, avance et retard sur le dépôt distant, et niveau d'activité du projet (actif si moins de 30 jours, ralenti jusqu'à 120 jours, dormant au delà). Sans paramètre « projet », renvoie le tableau de bord de TOUS les dépôts d'un coup, trié du plus récemment touché au plus ancien : c'est la façon la plus rapide de savoir sur quoi François travaille en ce moment et ce qu'il a laissé en chantier. Avec un « projet », se concentre dessus et peut remonter l'historique des derniers commits. Strictement en lecture : cet outil n'exécute aucune commande git qui modifie quoi que ce soit, ni add, ni commit, ni push, ni checkout, ni fetch.

Cherche un texte ou une expression régulière dans le CONTENU des fichiers de tous les projets à la fois, et renvoie les correspondances groupées par projet avec le fichier et le numéro de ligne. C'est l'outil qui répond aux questions du type : où est-ce que j'ai déjà écrit ce personnage, dans quel projet se trouve cette clé d'API, quels dépôts utilisent cette dépendance, où ai-je documenté cette décision. Utilise ripgrep quand il est installé sur la machine, sinon un parcours interne équivalent. Les dossiers lourds (node_modules, dist, build, .astro, venv, pycache, .git) sont toujours exclus. Restreins la recherche avec « projets » et « filtre_fichiers » dès que tu peux : c'est plus rapide et le résultat est plus lisible.

Cherche des fichiers par leur NOM ou leur chemin à travers tous les projets, via un motif glob. Complémentaire de chercher_partout qui fouille le contenu : ici tu réponds à des questions de localisation, par exemple où sont tous les CLAUDE.md, quels projets ont un fichier .mcp.json, où vivent les chapitres du roman, quels dépôts contiennent un Dockerfile. Les dossiers lourds (node_modules, dist, build, .astro, venv, pycache, .git) sont toujours ignorés.

Renvoie la configuration effective du serveur Pilotage : racines scannées, dossiers exclus, profondeur de scan, présence de ripgrep, durée du cache, et rappel des garanties de sécurité. Appelle cet outil quand un résultat te surprend (un projet manquant, une recherche vide, une lenteur) pour comprendre ce que le serveur voit réellement du disque avant de conclure.

Usage de l'API Claude de l'utilisateur : tokens consommés et factures, lus en direct depuis le dossier usage/ (réglable par PILOTAGE_DOSSIER_USAGE). Source des tokens : un export CSV par mois (un token compte pour de l'entrée, cache compris, ou de la sortie), déposé à la main par l'utilisateur. Source des factures : un tableau tenu à la main, indépendant des exports de tokens (il mélange abonnement et usage mesuré, les montants ne se déduisent pas des tokens). Sans paramètre, renvoie la période complète : totaux, détail mois par mois avec répartition par projet et par modèle, classement des projets et des modèles sur toute la période, et la liste des factures. Avec « mois », se concentre sur un seul mois (répartition par projet et par modèle de ce mois-là uniquement) ; les factures restent toujours renvoyées en entier car leurs dates ne correspondent pas forcément au mois d'usage. Utile pour écrire un article de blog transparent sur le coût ou l'usage de l'IA : les chiffres sont prêts à citer, avec leurs libellés en clair. Strictement en lecture : ne modifie jamais les fichiers du dossier usage/.