Le skill di Claude Code sono passate da annuncio di funzionalità a termine cercato di propria iniziativa in pochi mesi. Il copione è familiare: esce un meccanismo, arrivano i tutorial su come costruirne una, si forma un mercato attorno alla condivisione, e la copertura si ferma esattamente lì, a "ecco come impacchetti una skill", senza chiedersi cosa manca a una skill una volta che un agente ne ha davvero eseguita una.
Cos'è una skill di Claude Code, e come si distingue da un system prompt
Una skill è una cartella, non un prompt incollato in una chat. Al minimo contiene un file, SKILL.md, con un frontmatter YAML tra delimitatori --- e un corpo in markdown sotto. I due campi del frontmatter che contano di più sono name, che deve coincidere con il nome della cartella che lo ospita, e description, la stringa che Claude legge davvero per decidere se quella skill è pertinente al task che ha davanti. Campi opzionali restringono ulteriormente: allowed-tools limita cosa la skill può toccare una volta attiva, disable-model-invocation controlla se il modello può attivarla da solo oppure se serve un'invocazione esplicita da parte di una persona. Il corpo è dove sta il metodo vero e proprio, i passaggi, le convenzioni, la checklist, tutto ciò che un team vuole che ogni agente segua allo stesso modo.
È un oggetto sensibilmente diverso da un system prompt o da un'istruzione data al volo dentro una sessione. Un system prompt è globale e sempre caricato. Una skill viene scoperta, delimitata da una corrispondenza sulla description, e può portarsi dietro script e file di riferimento propri oltre al markdown, documentato per intero nella guida ufficiale alle skill di Claude Code. È più vicina a una funzione che l'agente può chiamare quando il task corrisponde, che a un paragrafo di contesto sempre attivo.
Perché le skill si diffondono in fretta: condivisibili, versionate, pronte per un marketplace
Il pacchetto è tutto il punto. Una skill è una directory, quindi è una cosa che un team può mettere sotto controllo di versione, diffare, revisionare e spedire come spedisce il codice. anthropic/skills è il repository pubblico che Anthropic stessa pubblica come set di riferimento. Oltre a quello non esiste un unico negozio ufficiale: le skill circolano attraverso il primitivo di marketplace dei plugin di Claude Code, attraverso cataloghi della community, e attraverso team che semplicemente committano una cartella .claude/skills/ nel proprio repository e la tirano dentro a ogni clone. È una soglia d'ingresso più bassa di quella che pongono la maggior parte degli ecosistemi di estensioni, nessun registro proprietario a cui pubblicare, nessuna coda di approvazione, solo una cartella con i due campi giusti nel frontmatter.
Un formato che ogni agente di un progetto legge gratis, con la cartella stessa come unità di condivisione, era destinato a diffondersi oltre un singolo team. Quello che è nuovo non è l'idea di impacchettare istruzioni, i team lo fanno da anni con README e wiki, è che ora il pacchetto è qualcosa che l'agente stesso analizza e attiva da solo, a metà sessione, in base a cosa serve davvero al task.
Ancora file di istruzioni contro registro di sessione
È la stessa distinzione in cui incappa AGENTS.md, applicata a un meccanismo più specifico e uscito più di recente. Una skill viene letta prima, o durante, un task per orientare come l'agente lo affronta. È input. Quando la sessione si chiude, il file SKILL.md non è cambiato, dice esattamente quello che diceva prima che l'agente lo aprisse, perché descrive un metodo, non un'esecuzione. Un team con una skill precisa e ben versionata e un team con una skill scritta male sbattono contro lo stesso muro nel momento in cui qualcuno chiede cosa è successo in una sessione specifica: nessuno dei due file risponde a quella domanda, perché nessuno dei due è stato costruito per farlo.
Le skill, di fatto, allargano leggermente il divario rispetto a un semplice file di istruzioni, proprio perché sono più potenti. Una skill con allowed-tools ristretto, script inclusi, e una description calibrata per attivarsi in automatico sta facendo un lavoro vero a metà sessione, decide cosa l'agente usa e come lo usa. Questo rende la domanda su cosa un'esecuzione specifica abbia davvero fatto con una versione specifica della skill più rilevante, non meno, e il meccanismo non ha nessun campo per rispondere.
Cosa una skill non può dirti dopo che l'agente l'ha eseguita
Prendi un team che fa tutto bene: uno SKILL.md snello, una description precisa che si attiva solo quando deve, allowed-tools limitato esattamente a ciò che serve al metodo, versionato in git insieme al codice che tocca. Quel team non può comunque consegnare a un cliente o a un revisore un oggetto che dica, per questo task specifico, quale skill si è attivata, in quale versione, cosa ha effettivamente fatto l'agente con gli strumenti che gli erano permessi, e chi ha revisionato il risultato prima che partisse. Il file della skill, per quanto scritto bene, risponde a una domanda diversa: cosa deve succedere quando si presenta questo tipo di task, per ogni sessione che corrisponderà mai a quella descrizione, non cosa è successo in quella appena eseguita.
È lo stesso divario che gli hook di Claude Code colmano solo in parte, da un'angolazione diversa: un hook intercetta l'evento grezzo mentre accade invece di descrivere in anticipo un comportamento previsto, ma l'intercettazione resta comunque diversa da un registro firmato che nomina il task, la versione della skill e chi l'ha autorizzata. Una skill sta a monte della sessione, come un file di istruzioni; un hook sta dentro, a guardare. Nessuno dei due, da solo, sta a valle della sessione, a guardarla indietro con una firma allegata.
Cosa dovrebbe registrare una software house accanto alle proprie skill
Scrivi la skill, tieni la description abbastanza precisa da attivarsi solo quando deve, tratta la cartella come l'asset riusabile e versionato che è pensata per essere: è disciplina genuinamente utile, non tempo sprecato. Quello che non sostituisce è un registro separato, per ogni consegna: quale versione della skill era attiva per quel task, cosa ha effettivamente fatto l'agente con gli strumenti che quella skill ha sbloccato, e una firma umana sul risultato prima che un cliente lo veda, il livello che sta sopra la configurazione dell'agente, non dentro. Una skill condivisa fa partire ogni agente di un team dallo stesso metodo. Non è mai stata pensata per essere l'oggetto che dimostra, a posteriori, che quel metodo è stato davvero seguito nell'unica esecuzione che contava.