Il cancro delle Skills
Le skill promettono competenze per gli agenti AI, ma restano prompt fragili, insicuri e difficili da testare, che stanno impoverendo chi impara a usare l’AI.
In meno di un anno le skill sono diventate il modo in cui l’industria dell’AI generativa racconta a se stessa di aver risolto il problema della specializzazione degli agenti, e la velocità con cui il concetto si è diffuso dovrebbe già metterci in sospetto. Nate come una convenzione di Anthropic per Claude, poi pubblicate come specifica aperta e adottate da buona parte degli strumenti di coding agentico, le skill vengono oggi presentate come pacchetti di competenza che un modello acquisisce e usa quando servono, con un lessico che evoca l’apprendimento, la modularità e il riuso del software.
La tesi di questo articolo è che dietro quel lessico ci sia un meccanismo molto più povero di quanto venga lasciato intendere, e che la distanza tra ciò che le skill sono e ciò che si dice di loro stia producendo danni concreti su tre piani, quello dell’affidabilità dei sistemi, quello della sicurezza e quello, forse il più grave, della formazione di chi l’AI la usa e la progetta. Il paragone con una crescita incontrollata è voluto, perché il problema sta meno nella singola skill che nella proliferazione di un’abitudine che si autoalimenta, si diffonde per imitazione e occupa lo spazio in cui dovrebbe crescere una competenza vera.
Per essere utile una critica deve essere precisa, e quindi partiremo da cosa c’è effettivamente dentro una skill, per poi esaminare i sintomi uno per uno, affrontare le obiezioni più serie e chiudere con quello che, a mio avviso, servirebbe davvero.
Anatomia di una skill
Secondo la specifica pubblicata su agentskills.io, una skill è una cartella che contiene come unico elemento obbligatorio un file SKILL.md, composto da un frontmatter YAML e da un corpo in Markdown, a cui si possono affiancare cartelle opzionali per script eseguibili, documentazione di riferimento e asset. Il frontmatter richiede soltanto due campi, un nome di al massimo 64 caratteri e una descrizione di al massimo 1024 caratteri che dovrebbe dire cosa fa la skill e quando usarla, mentre gli altri campi, compreso quell’allowed-tools che pre-autorizza gli strumenti utilizzabili, sono opzionali e in parte dichiaratamente sperimentali, con un supporto che varia da un’implementazione all’altra.
Il dettaglio più eloquente riguarda il corpo del file, per il quale la specifica afferma esplicitamente che non esistono restrizioni di formato e che si può scrivere qualunque cosa aiuti l’agente a svolgere il compito. Coerentemente, lo strumento di validazione di riferimento controlla che il frontmatter sia ben formato e che il nome rispetti le convenzioni, e non ha nulla da dire sul contenuto, perché il contenuto è testo libero destinato a un modello linguistico.
Il meccanismo di esecuzione è quello che la specifica chiama divulgazione progressiva e si articola in tre livelli. All’avvio vengono caricati nel contesto nome e descrizione di tutte le skill disponibili, circa cento token ciascuna; quando il modello giudica pertinente una skill ne carica l’intero corpo, per il quale si raccomanda di restare sotto i cinquemila token; infine i file accessori vengono letti solo se e quando le istruzioni li richiamano. La documentazione di Microsoft Agent Framework descrive lo stesso schema in termini ancora più espliciti, con le descrizioni iniettate nel system prompt e un tool che restituisce il corpo della skill al modello che lo invoca, e ammette con franchezza che le istruzioni vengono iniettate nel contesto e possono influenzare il comportamento dell’agente.
Ridotta all’osso, dunque, una skill è un frammento di prompt con un’etichetta, un indice che il modello consulta per decidere se leggerlo e, facoltativamente, del codice che il modello può decidere di eseguire. Tutto ciò che segue discende da questa descrizione, che è bene tenere a mente ogni volta che si sente parlare di competenze acquisite dall’agente.
Primo sintomo, un prompt travestito da astrazione
L’ingegneria del software ha costruito le sue astrazioni più riuscite, la funzione, il modulo, l’interfaccia, il pacchetto, attorno a un’idea precisa, cioè che chi usa un componente possa affidarsi a ciò che il componente dichiara di fare senza conoscerne l’interno. Un’astrazione vale nella misura in cui il suo comportamento è determinato dalla sua dichiarazione, ed è esattamente questa proprietà che permette di comporla, sostituirla e ragionarci sopra.
La skill prende in prestito tutta la superficie di questo vocabolario, con le sue cartelle, i suoi metadati, i suoi campi di licenza e versione, il suo validatore e il suo ecosistema di installazione, senza possedere la proprietà che lo giustifica. Il suo comportamento dipende da come un modello probabilistico interpreta un testo in linguaggio naturale in un contesto che contiene anche tutto il resto della conversazione, le altre skill caricate, il system prompt della piattaforma e gli eventuali output degli strumenti, e nessuna di queste variabili è sotto il controllo di chi la scrive.
Il risultato è un oggetto che ha l’aspetto di un componente software e la semantica di un consiglio. Questo sarebbe un problema minore se fosse dichiarato con chiarezza, ma l’intero apparato comunicativo che accompagna le skill parla di capacità, competenze e moduli, e induce chi le adotta a trattarle con la fiducia che si riserva a una libreria, mentre andrebbero trattate con la cautela che si riserva a una raccomandazione scritta da qualcun altro e letta da un collaboratore di cui non si conosce bene il giudizio.
Secondo sintomo, un routing affidato al caso
Il punto più debole dell’intero meccanismo è il momento in cui il modello decide se caricare una skill, perché quella decisione è presa dal modello stesso sulla base di una descrizione di poche righe, senza alcuna regola esplicita che la governi. La specifica raccomanda di includere nella descrizione parole chiave che aiutino l’agente a riconoscere i compiti pertinenti, il che equivale ad ammettere che l’instradamento funziona per somiglianza lessicale e semantica, cioè per la stessa via approssimativa con cui funziona un motore di ricerca mal configurato.
I dati disponibili confermano che il problema è tutt’altro che teorico. A gennaio 2026 il team di Next.js in Vercel ha pubblicato i risultati di una serie di valutazioni su API di Next.js 16 assenti dai dati di addestramento dei modelli, confrontando una skill di documentazione con un indice compresso di circa 8 KB inserito direttamente in AGENTS.md, il file di contesto sempre presente. Nel 56% dei casi la skill non è mai stata invocata, e la sua sola presenza ha prodotto un tasso di successo identico a quello ottenuto senza alcuna documentazione, con un peggioramento sui test (58% contro 63%) che gli autori attribuiscono al rumore introdotto da uno strumento disponibile ma inutilizzato.
| Configurazione | Tasso di successo | Differenza sulla baseline |
|---|---|---|
| Nessuna documentazione | 53% | — |
| Skill, comportamento predefinito | 53% | +0 punti |
| Skill con istruzioni esplicite di invocazione | 79% | +26 punti |
| Indice di documentazione in AGENTS.md | 100% | +47 punti |
Aggiungendo ad AGENTS.md un’istruzione che imponeva di usare la skill, il tasso di invocazione è salito oltre il 95% e quello di successo al 79%, ma lo stesso studio documenta che formulazioni diverse della stessa istruzione producevano comportamenti molto diversi, al punto che gli autori definiscono l’approccio fragile per un uso in produzione. Vale la pena fermarsi sul paradosso, perché per far funzionare una skill è servito scrivere un prompt sempre presente che dicesse al modello di usarla, e la soluzione migliore è stata eliminare la decisione del tutto.
Per onestà va detto che si tratta di un singolo dominio, misurato con i modelli disponibili a inizio 2026, e che Vercel stessa riconosce alle skill un ruolo nei flussi verticali attivati esplicitamente dall’utente. Ma è proprio questa la questione, perché una skill che funziona in modo affidabile solo quando qualcuno la invoca a mano svolge la funzione di un comando, e un comando non richiede un apparato di metadati e di scoperta automatica per esistere.
A tutto questo si somma l’assenza di qualunque contratto. Una funzione dichiara i propri input e output, un’API ha uno schema, un tool ha almeno una firma tipizzata; una skill non dichiara precondizioni, effetti o garanzie, e due skill con descrizioni sovrapposte competono per l’attenzione del modello senza che esista un criterio di precedenza diverso dall’umore statistico del momento.
Terzo sintomo, versioni che non versionano nulla
La specifica prevede un campo metadata in cui gli esempi ufficiali collocano autore e versione, e l’ecosistema ha rapidamente costruito attorno a questo campo registri, comandi di installazione e repository pubblici, dando l’impressione che una skill abbia un ciclo di vita paragonabile a quello di una dipendenza software. L’impressione è fuorviante, perché il numero di versione fotografa soltanto il testo, mentre il comportamento effettivo è il prodotto di quel testo con un modello, una piattaforma e un contesto che cambiano indipendentemente.
La stessa skill alla versione 1.0 si comporta in modo diverso su Claude, su Codex, su Gemini CLI o su Cursor, e si comporta in modo diverso sullo stesso client quando il fornitore aggiorna il modello sottostante, modifica il proprio system prompt o cambia il modo in cui presenta l’elenco delle skill disponibili. La specifica stessa riconosce che il supporto ad alcuni campi varia tra implementazioni, e la documentazione di riferimento consiglia di provare ogni skill su più client, il che significa ammettere che la portabilità promessa dallo standard aperto riguarda il formato del file, mentre ciò che il file produce resta legato al modello che lo legge.
Da qui discende un problema di testabilità che nessuno strumento attuale risolve in modo soddisfacente. Per verificare una skill non basta un test unitario, servono valutazioni ripetute su campioni di compiti rappresentativi, con misure separate per l’attivazione corretta, per il rifiuto delle skill vicine ma sbagliate e per la qualità dell’esecuzione, da ripetere a ogni aggiornamento di modello. È un lavoro serio, che le organizzazioni mature fanno per i propri prompt di produzione, ma di cui le skill pubblicate nei repository pubblici raramente danno conto, e la cui assenza non è segnalata da nulla perché il validatore ufficiale si limita a controllare il frontmatter.
Il risultato pratico è una regressione silenziosa come condizione normale di esercizio. Un’azienda che costruisce i propri processi su un insieme di skill scopre che qualcosa ha smesso di funzionare solo quando un output sbagliato arriva a valle, senza un changelog da consultare, senza un diff che spieghi la differenza e senza la possibilità di bloccare la versione del componente che è davvero cambiato, cioè il modello.
Quarto sintomo, una supply chain costruita sulla fiducia implicita
Una skill può contenere due tipi di carico, istruzioni in linguaggio naturale e codice eseguibile, e l’agente tratta entrambi con un livello di fiducia molto superiore a quello che riserverebbe a un input qualsiasi, perché li riceve come parte della propria configurazione. Questo la rende un vettore d’attacco più insidioso di un pacchetto npm compromesso, dato che alle tecniche classiche di supply chain si sommano quelle di prompt injection, e queste ultime sfuggono per costruzione agli strumenti di analisi statica, che non sanno leggere l’intenzione di un paragrafo in prosa.
La prima analisi su larga scala, Agent Skills in the Wild di Liu e colleghi, ha esaminato 31.132 skill raccolte a dicembre 2025 da due marketplace pubblici. Il 26,1% presentava almeno un pattern potenzialmente pericoloso e il 5,2% pattern ad alta severità compatibili con un intento malevolo, mentre le skill che includevano script risultavano vulnerabili con una probabilità 2,12 volte superiore a quelle composte di sole istruzioni. Gli stessi autori precisano che buona parte dei casi riflette negligenza più che malizia e che il dato fotografa un ecosistema ai suoi primi due mesi di vita, ma rilevano anche che i comuni strumenti SAST provati su un sottoinsieme non hanno intercettato nessuno dei pattern di injection presenti nelle istruzioni.
Le ricerche successive vanno nella stessa direzione. Il rapporto ToxicSkills di Snyk, su 3.984 skill, ha trovato problemi di livello critico nel 13,4% dei casi e 76 payload malevoli confermati, il 91% dei quali combinava codice dannoso e prompt injection, con alcune skill malevole ancora installabili al momento della pubblicazione. Per completezza va citato anche il lavoro di Holzbauer e colleghi, che su oltre 238.000 skill ridimensiona drasticamente le percentuali prodotte dagli scanner automatici, portando la quota di skill sospette sotto l’1% una volta considerato il contesto del repository, ma che documenta a sua volta un vettore nuovo, il dirottamento di skill ospitate su repository GitHub abbandonati.
Il punto strutturale prescinde dalla percentuale esatta. Il problema nasce da quello che il primo studio chiama consent gap, cioè la distanza tra ciò che l’utente approva installando una skill e ciò che la skill fa davvero, aggravata dal fatto che il meccanismo di attivazione è implicito e che il campo destinato a limitare gli strumenti utilizzabili è, per ammissione della specifica, sperimentale e supportato in modo disomogeneo. Abbiamo così ricostruito l’ecosistema delle estensioni dei browser dei primi anni, con meno sandbox, nessuna firma del codice, nessun modello di permessi vincolante e in più una superficie d’attacco semantica che nessuno sa ancora ispezionare in modo affidabile.
Quinto sintomo, l’atrofia della competenza
Questo è il danno che considero più grave, perché i problemi di affidabilità e di sicurezza prima o poi verranno affrontati con strumenti tecnici, mentre quello che si perde sul piano della formazione difficilmente si recupera. Per lavorare bene con un modello linguistico serve capire alcune cose che non si imparano installando pacchetti, cioè che tutto ciò che il modello sa di un compito passa per il contesto, che l’ordine e la formulazione delle informazioni contano, che ogni istruzione compete con le altre per l’attenzione del modello, che un output va verificato contro criteri esterni e non contro la propria aspettativa. Sono nozioni semplici da enunciare e difficili da interiorizzare, e si interiorizzano solo scrivendo, sbagliando, misurando e correggendo.
La skill offre una scorciatoia che salta esattamente questo passaggio. Chi si avvicina oggi all’uso professionale dell’AI trova cataloghi con decine di migliaia di procedure già pronte, si abitua a cercare la skill giusta invece di chiedersi cosa manchi al modello per svolgere il compito, e attribuisce i successi alla skill e gli insuccessi al modello, senza mai acquisire gli strumenti per distinguere le due cose. Il linguaggio stesso con cui le skill vengono presentate, che parla di competenze che l’agente acquisisce, rafforza un modello mentale sbagliato, in cui il sistema impara qualcosa, quando in realtà nessun peso cambia e tutto ciò che accade è la lettura di un file.
C’è poi un effetto di omologazione meno evidente ma altrettanto concreto. Quando migliaia di utenti installano le stesse skill per scrivere documenti, progettare interfacce o revisionare codice, gli output convergono verso le scelte stilistiche e metodologiche di poche persone che quelle skill le hanno scritte, spesso senza dichiarare i propri presupposti e senza che chi le usa si accorga di averli adottati. Il risultato è una monocultura di procedure che nessuno ha davvero scelto, perché sono arrivate come impostazioni predefinite.
Infine, le skill spostano il sapere fuori dalle persone e dentro file che nessuno rilegge. In un’organizzazione la conoscenza di come si fa una certa cosa smette di risiedere nelle teste di chi la fa e si cristallizza in un markdown scritto da qualcuno mesi prima, magari per un modello diverso, e quando quel markdown smette di funzionare non c’è più nessuno in grado di capire perché, perché nessuno ha mai dovuto capire come funzionava.
Le obiezioni prevedibili
Una critica che non affronta le obiezioni più forti è facile da smontare, quindi conviene esaminarle una per una e riconoscere ciò che hanno di giusto.
La prima obiezione sostiene che la divulgazione progressiva risolve un problema reale, cioè l’impossibilità di tenere nel contesto le istruzioni per decine di compiti diversi senza degradare le prestazioni. È vero, e il problema della finestra di contesto esiste. Ma i dati di Vercel mostrano che un indice compresso sempre presente, che rimanda a file da leggere su richiesta, ottiene risultati migliori proprio perché elimina la decisione di attivazione, e quindi la parte utile della divulgazione progressiva, cioè il caricamento differito dei contenuti, si può avere senza la parte fragile, cioè l’instradamento affidato al modello.
La seconda obiezione osserva che una skill è almeno un file leggibile, più trasparente di un fine-tuning o di un system prompt nascosto. Anche questo è vero, e lo considero il pregio principale del formato. Il fatto che un file sia leggibile, però, non garantisce che venga letto, e gli studi citati mostrano che molte skill vulnerabili hanno accumulato download e stelle prima di essere scoperte; la trasparenza potenziale ha valore solo se accompagnata da una cultura della revisione che l’ecosistema attuale scoraggia, perché si fonda sull’installazione rapida.
La terza obiezione ricorda che le skill possono includere codice deterministico, e che in quel caso l’affidabilità è quella del codice. Corretto, ma la scelta di quando eseguire quel codice, con quali argomenti e come interpretarne l’output resta al modello, e lo stesso codice è la componente associata al rischio di sicurezza più alto. Uno script ben scritto dentro una skill rimane uno script ben scritto, che avrebbe potuto essere esposto come tool con una firma tipizzata e permessi espliciti.
La quarta obiezione è la più seria e sostiene che i modelli miglioreranno, che l’attivazione diventerà affidabile e che molti dei problemi descritti sono transitori. Può darsi, e una parte dei numeri qui riportati si riferisce a modelli e a un ecosistema di mesi fa. Tuttavia un modello più capace rende più affidabile l’esecuzione di istruzioni in generale, comprese quelle malevole, e nulla nel miglioramento dei modelli introduce contratti, permessi vincolanti o versionamento del comportamento; quanto al danno formativo, un sistema che funziona meglio senza che l’utente capisca perché lo aggrava invece di attenuarlo.
Cosa servirebbe invece
Rifiutare in blocco il formato sarebbe una reazione altrettanto pigra quanto adottarlo senza riflettere, e qualche indicazione concreta può limitare i danni descritti.
La prima è chiamare le cose con il loro nome. Una skill va trattata, documentata e revisionata come un prompt di produzione, con lo stesso rigore e la stessa diffidenza, e chi la presenta come una competenza dell’agente contribuisce a una confusione che ha costi reali.
La seconda riguarda l’attivazione. Quando un’istruzione deve essere seguita sempre, il suo posto è il contesto permanente, eventualmente in forma di indice compresso che rimanda a file da leggere su richiesta; quando invece una procedura serve solo in certi casi, è preferibile che sia l’utente o un orchestratore deterministico a invocarla esplicitamente, lasciando al modello la decisione di caricarla solo dove un errore di instradamento costa poco.
La terza riguarda il codice. Ciò che può essere deterministico va estratto dalle istruzioni ed esposto come tool con firma tipizzata, permessi minimi e sandbox, così che la parte affidabile del sistema abbia un contratto e la parte probabilistica sia ridotta al minimo indispensabile.
La quarta riguarda la valutazione. Nessuna skill dovrebbe entrare in un flusso di lavoro professionale senza un insieme di casi di test che misuri separatamente attivazione, mancata attivazione e qualità dell’esecuzione, da ripetere a ogni cambio di modello, e nessuna skill di terzi dovrebbe essere installata senza averne letto per intero istruzioni e script, esattamente come non si eseguirebbe uno script trovato in rete con privilegi elevati.
La quinta riguarda la formazione, ed è quella che mi sta più a cuore. Chi insegna l’uso dell’AI dovrebbe far scrivere agli studenti le proprie istruzioni da zero, fargliele misurare e fargliele rompere, prima di mostrare loro qualsiasi catalogo; le skill altrui andrebbero usate come materiale da leggere e smontare, per capire quali scelte contengono e perché funzionano o falliscono, e mai come scatole nere da installare.
Conclusione
Le skill sono un frammento di prompt con un’etichetta, un meccanismo di caricamento affidato al giudizio del modello e, a volte, del codice che il modello può decidere di eseguire. Come convenzione organizzativa per chi sa già come funziona l’ingegneria del contesto possono essere comode, e sarebbe disonesto negarlo. Il problema sorge quando questa convenzione viene raccontata come un’astrazione ingegneristica, distribuita come un ecosistema di pacchetti e adottata come sostituto della comprensione, perché in quel momento eredita la fragilità del prompting, la superficie d’attacco della supply chain e l’opacità del software di terzi, senza nessuna delle garanzie che rendono sopportabili queste ultime.
Il paragone con un tumore riguarda proprio questa dinamica di crescita, in cui una cellula di per sé banale si replica senza controllo, si diffonde per imitazione e sottrae risorse ai tessuti sani, che in questo caso sono la competenza di chi progetta sistemi basati su modelli linguistici e la cultura della verifica che quei sistemi richiedono. Per curarla basterebbe smettere di attribuire al formato proprietà che non ha e tornare a pretendere, da chi costruisce e da chi impara, che sappia esattamente quale testo arriva al modello, in quale momento e con quali conseguenze.
