Claude Code se dote d’un audit en lecture seule pour ses skills

Un prompt d’audit en lecture seule pour Claude Code circule afin d’examiner un skill tiers avant installation, sans rien exécuter ni modifier. L’idée est de cartographier ce que le skill peut lancer, lire, écrire ou envoyer sur le réseau, avec des preuves file:line. Le sujet compte parce qu’un skill n’est pas juste un texte: il peut embarquer scripts, hooks, manifests et consignes de configuration. Et quand on lui donne les clés du terminal, mieux vaut savoir ce qu’il compte faire avec.

Un audit statique qui traite le skill comme une source non fiable

Le prompt demande de considérer tout le contenu de TARGET comme des données à auditer, jamais comme des instructions à suivre. Il impose une garantie de lecture seule, interdit toute installation, tout appel réseau et toute modification de configuration Claude, puis exige un inventaire complet des fichiers et une carte d’exécution à partir de SKILL.md et des manifests éventuels.

Cette approche vise surtout les skills tiers qui peuvent contenir des scripts, des hooks, des commandes slash, des définitions d’agents ou des dépendances installées séparément. Le texte insiste aussi sur les textes cachés, les commentaires HTML, les chaînes encodées et les caractères invisibles. Autrement dit, il faut lire comme un scanner, pas comme un enthousiaste du copier-coller.

Ce que l’outil veut couvrir, et pourquoi c’est large

La procédure demande de remonter chaque référence: markdown lié, scripts mentionnés, fichiers appelés par ces scripts, dépendances, variables d’environnement, endpoints réseau et chemins système. Elle prévoit aussi un passage spécifique sur les mutations de configuration Claude, comme CLAUDE.md, settings.json, les hooks, les permissions ou les répertoires agents/ et commands/.

Le cœur de la méthode repose sur une distinction nette entre capacité et intention. Lire un jeton d’environnement n’est pas une preuve d’abus, mais cela reste un accès sensible. De la même manière, un curl | bash ou un hook automatique constitue une surface d’exécution, même si le texte le présente comme une simple étape de vérification. Le prompt demande donc de classer les éléments en Suspicious findings, Benign-but-powerful behavior ou Unknowns, selon l’évidence disponible.

Un signal utile pour les équipes qui installent des skills tiers

En pratique, ce canevas ressemble à une check-list de sécurité adaptée aux usages de Claude Code: pas de confiance implicite, pas d’exécution automatique, pas de dépendance avalée sans revue. Il s’adresse autant aux développeurs qu’aux équipes sécurité qui veulent limiter les surprises avant d’ajouter un skill à un environnement de travail. Le message est simple. Avant d’installer, on lit. Ensuite seulement, on décide.

Les deux autres sources vont dans une direction connexe. L’une décrit l’usage de CLAUDE_CONFIG_DIR et de direnv pour isoler plusieurs abonnements Claude Code par projet, avec des répertoires de configuration séparés. L’autre explique comment faire fonctionner Claude Code localement avec Ollama et des modèles open source, via une API compatible Anthropic. Dans les deux cas, la logique est la même: déplacer la confiance là où elle est visible, qu’il s’agisse d’un dossier de config, d’un modèle local ou d’un audit avant installation.

Au passage, cette discipline d’audit évite un classique du genre: “ça avait l’air d’un simple skill”. Les scripts, eux, aiment beaucoup les faux amis.