Claude Config Audit: la skill per fare un check di Claude Desktop

Claude Config Audit è la skill open source che ispeziona la configurazione di Claude e ne misura il peso nel contesto. Questo articolo presenta la versione attuale, cresciuta parecchio dalla prima uscita di aprile, e la collega alla distinzione fra i due strati del prompt di sistema. Racconta cosa controlla oggi sui tre ambienti di Claude Desktop, come misura l’impronta del prompt di sistema dividendola in parte fissa e parte utente, con quali cautele modifica i file di configurazione e a chi conviene usarla.

Dallo strato utente allo strumento

Il prompt di sistema di una conversazione è tutto quello che entra nella finestra di contesto di una conversazione ancora prima della prima richiesta dell’utente. Il precedente articolo lo ha scomposto nei suoi due strati, quello deciso dal fornitore e quello costruito dall’utente. Di questi due solo il secondo è modificabile dall’utente, raccoglie preferenze, istruzioni di progetto, server MCP, skill e plugin, e cresce quasi sempre per aggiunta. Si collega un servizio oggi, si installa un componente domani, e quasi nessuno torna a togliere quello che non serve più.

Quell’articolo suggeriva di guardare ogni tanto lo strato utente, per sapere cosa contiene e quanto occupa. Come farlo davvero restava però da spiegare. Un elenco dei componenti installati non basta, perché non dice quanto pesano nel contesto, non mostra le descrizioni doppie e non segnala i server collegati e poi dimenticati. Inoltre lo strato utente prende forma completa solo dentro una sessione attiva, quando la piattaforma mette insieme i pezzi. Per vederlo davvero bisogna guardarlo mentre lavora, non ricostruirlo da un inventario.

Della parte di configurazione gestita dall’utente ho già scritto, inoltre vista la difficoltà di tenerla sotto controllo avevo rilasciato ad aprile la prima versione di Claude Config Audit, una skill che aiuta a gestire proprio quello strato. Da allora l’ho ampliata parecchio, ora nella nuova versione ispeziona la configurazione di Claude dall’interno di una sessione, misura quanto pesa ogni componente e segnala sovrapposizioni, elementi rotti e componenti inutilizzati.

Cosa fa oggi

La versione di aprile si limitava a controllare i server MCP duplicati, le sovrapposizioni fra le istruzioni e qualche problema nell’ecosistema delle skill. Di recente l’ho estesa, specializzandola su Claude Desktop e i suoi tre ambienti (Chat, Cowork e Code), ciascuno trattato come lo stack completo che una sessione in ognuno dei tre riceve davvero. Concentrarsi su un solo prodotto permette di analizzare ogni ambiente per quello che è, invece di fermarsi a un minimo comune denominatore fra piattaforme diverse. Chi usa solo il web non resta fuori, perché chi lavora in claude.ai usa quasi la stessa configurazione di Chat in Claude Desktop, infatti le due interfacce condividono l’account, e con esso preferenze, istruzioni di progetto e skill. Solo la gestione dei server MCP è parzialmente diversa perché l’ambiente Chat del Desktop legge anche il file locale claude_desktop_config.json.

Le aree di controllo oggi sono queste.

• Inventario dei componenti. Per ogni ambiente Claude Config Audit elenca server MCP, skill, plugin e livelli di istruzioni, così com’è la configurazione che quella sessione riceve, non come si crede che sia.
• Duplicati giudicati per ambiente. Due strumenti di ragionamento, due API di ricerca, server di filesystem sovrapposti. Un duplicato dentro un ambiente è un problema, lo stesso componente presente in due ambienti diversi di solito no, e la skill tiene distinti i due casi.
• Elementi rotti o inutilizzati. Un controllo in sola lettura verifica se ogni server può davvero partire, percorsi mancanti, pacchetti non risolvibili, credenziali segnaposto, servizi di appoggio spenti. Nello stesso passaggio segnala le skill mai usate e i plugin di setup rimasti attivi.
• Costo in contesto. La skill misura i token che ogni componente inietta a ogni sessione, calcolati dagli schemi reali degli strumenti e dalle descrizioni delle skill, non da medie generiche. Tiene conto del caricamento differito, dove i conti cambiano.
• Piano di intervento. Tutte le raccomandazioni finiscono in una tabella unica che attraversa i livelli, con spiegazione, difficoltà e impatto atteso, i guadagni facili per primi.

A questo si aggiunge l’analisi della gerarchia delle istruzioni, cioè lo stack che ogni ambiente riceve davvero, che distingue le regole messe al livello sbagliato dalle differenze che invece compensano un livello assente. È il punto in cui conta la precedenza fra gli strati, che la versione corrente ha rivisto per dire con esattezza cosa lo strato utente può cambiare e cosa resta fuori dalla sua portata.

L’impronta del prompt di sistema

Ogni report si apre con la dimensione del prompt di sistema di quella sessione, divisa nei due strati di cui parlava l’articolo precedente. Da una parte il prompt di sistema deciso dal fornitore e non modificabile, dall’altra la parte utente, fatta di istruzioni e componenti installati. Sono gli stessi due strati, ora misurati invece che descritti.

La divisione conta perché racconta le proporzioni. La parte del fornitore è quasi sempre la più estesa, anche molte volte più grande di quella utente, è il costo fisso della conversazione, quello che si paga sempre e su cui non si può intervenire. Per come è costruita, però, lascia all’utente un margine per incidere sul comportamento del modello, e quel margine si esercita agendo sulla parte utente. È la ragione per cui conviene lavorare proprio sulla porzione più piccola, che resta l’unica leva effettivamente a disposizione. La skill misura la parte di sistema solo per darne la proporzione, e su quella base mostra perché ottimizzare l’altra metà vale la pena.

La parte utente è quella su cui si agisce e il report la conta per intero. Non solo le istruzioni scritte, preferenze, istruzioni di progetto, CLAUDE.md, ma anche i componenti installati, con le descrizioni delle skill e le schede degli strumenti che ogni server aggiunge al contesto. Un server con ventisei strumenti aggiunge ventisei schede, e sono token che entrano a ogni avvio di sessione, che quel server venga utilizzato o no. Rendere visibile questo conto è uno degli scopi della skill.

Bisogna fare attenzione ad un aspetto in qualche modo procedurale, vista la complessità delle possibili interazioni fra le varie componenti, il peso reale delle varie parti si misura solo dall’interno di una sessione, cosa che la skill fa con la propria. Il report dichiara sempre quale ambiente ha misurato e non prova a indovinare gli altri. È lo stesso motivo per cui questo numero non si può leggere altrove, esiste solo nel momento in cui la piattaforma assembla il prompt di sistema, e la skill lo cattura mentre accade. Insomma la skill genera una fotografia dello stato dell’arte della propria sessione.

Come lavora

Il lavoro della skill segue un percorso in sei fasi, ma la cosa che conta di più per chi la usa è come si comporta quando arriva il momento di cambiare qualcosa. Prima legge i file di configurazione e il contesto della sessione, e si adatta a quello che trova, che sia l’accesso completo al filesystem, il solo contesto della sessione o dati forniti a mano. Poi verifica ogni componente una volta sola e analizza ciascun ambiente come lo stack completo che riceve. Il risultato è un report in markdown, e su richiesta anche una versione HTML a schede, una per ambiente più il piano di intervento.

I controlli di salute sono in sola lettura. Per sapere se un server può partire la skill ne verifica percorsi, pacchetti e servizi di appoggio, ma non lo lancia mai per provarlo. Lo classifica a posto, degradato, rotto, mal configurato o non verificabile senza eseguirlo.

Ogni modifica è preceduta da un backup. Prima di cambiare qualcosa la skill salva lo stato precedente, e il report finale riporta le istruzioni per ripristinarlo.

Niente si applica senza una conferma esplicita. La skill non esegue le proprie raccomandazioni da sola, le propone a piccoli gruppi, tre o quattro decisioni per volta, e attende una risposta per ciascuna. Le modifiche approvate entrano una categoria alla volta, con un controllo di validità del file dopo ogni passaggio.

Alla fine la skill documenta cosa ha fatto, cosa resta da fare a mano e ogni quanto conviene ripetere il controllo.

A chi serve

La skill è utile a chi ha personalizzato Claude nel tempo e ha perso di vista cosa ha accumulato. Chi ha collegato diversi server MCP, installato skill e plugin man mano che servivano, e lavora su più di un ambiente, si ritrova quasi sempre con sovrapposizioni e componenti dimenticati che continuano a pesare sul contesto. È la condizione in cui l’inventario mentale non coincide più con la configurazione reale, ed è quella in cui l’audit rende di più.

Il momento giusto per eseguirlo è dopo un periodo di aggiunte, quando si è collegato o installato parecchio senza mai tornare a togliere. Non serve farlo spesso, un controllo ogni tanto basta a tenere lo strato utente sotto osservazione invece di lasciarlo crescere alla cieca.

Restano due limiti dichiarati. La skill non tocca lo strato di sistema, lo misura solo per sapere quanto incide in proporzione, perché non è modificabile. E fotografa un ambiente alla volta, quello da cui gira, senza indovinare gli altri. Il report dice sempre quale ambiente ha misurato, e descrive lo stato attuale, senza confronti con controlli precedenti a meno che non si chieda.

Dove trovarla

Claude Config Audit è un progetto open source su GitHub, con licenza MIT. La versione corrente è la 2.2.2.

Si installa come una cartella, senza dipendenze e senza passaggi di compilazione. Basta scaricarla e copiarla nella directory delle skill di Claude, e alla sessione successiva è disponibile. Il repository spiega i due modi per farlo, il download come archivio zip per chi non usa Git e la clonazione per chi preferisce aggiornarla con un comando. Chi vuole segnalare un problema o proporre un miglioramento è benvenuto, i pattern di analisi sono documentati in file separati e pensati per essere estesi.

Chi parte da zero può leggere prima l’articolo che presentava la prima versione, per vedere da dove è nata la skill e cosa faceva all’inizio. Da lì a oggi il percorso è quello raccontato qui, uno strumento cresciuto insieme alla configurazione che deve tenere in ordine.