Ecco la skill da imparare per i prossimi 5 anni


Il prompt perfetto sta diventando un’abilità che vale sempre meno. Quello che conta non è più la capacità di formulare la richiesta giusta a un modello, ma la capacità di trasformarla in un file che chiunque, agenti compresi, può eseguire allo stesso modo, all’infinito. Il formato si chiama skill.md, ed è uno standard aperto documentato da Anthropic in un paper tecnico pubblico, con tanto di repository su GitHub che ne fissa la specifica. È un cambio di unità di lavoro: dal prompt estemporaneo alla procedura persistente.

Un file al posto di un trucco personale

La differenza tra un prompt e uno skill file è di natura, non di lunghezza. Un prompt è una richiesta buona per quella sessione, pensata da una persona per ottenere un risultato in quel momento. Uno skill file è un documento che descrive un compito specifico in modo stabile: quali passaggi seguire, quali fonti consultare, quale formato di output produrre, sempre nello stesso modo, indipendentemente da chi lo esegue.

Il caso tipico è quello del collega che sa scrivere un case study meglio di chiunque altro in azienda. Finché quella competenza resta un prompt nella sua testa, o peggio in una chat privata, il collega è l’unico canale attraverso cui passa. Trascritta in uno skill file, la stessa competenza diventa eseguibile da chiunque, umano o agente, senza dover reinventare il contesto ogni volta. È il passaggio dal trucco individuale alla procedura di squadra, lo stesso movimento che su Tom’s Hardware Italia abbiamo già descritto parlando della fine del prompt engineering come competenza isolata: contava quando l’unica interfaccia con l’AI era una casella di testo, conta meno quando l’interfaccia diventa un sistema di file, permessi e agenti che leggono altri file.

Un trucco personale resta un trucco. Scritto in un file, diventa un processo che sopravvive a chi lo ha inventato.


Anthropic ha reso lo standard pubblico, l’adozione è già multi-vendor

Lo standard skill.md esiste, ha una sintassi definita, ed è descritto nel dettaglio tecnico da Anthropic. L’adozione multi-vendor è già reale: altri strumenti agentici hanno iniziato a leggere lo stesso formato, il che lo avvicina a uno standard di fatto più che a una funzione chiusa dentro un unico ecosistema.

Su Claude, gli skill file possono essere raggruppati in un plugin e, sui piani Team ed Enterprise, un amministratore può distribuirli a tutta l’organizzazione senza passare da cartelle condivise o processi manuali. Il controllo su quali processi aziendali vengono formalizzati, e come, si sposta verso chi amministra la piattaforma agentica, spesso non la persona che quel processo lo ha inventato.

Il file si scrive in poche ore, si rompe in pochi mesi

Costruire un primo skill file non richiede competenze tecniche particolari. Bastano cinque domande da mettere per iscritto: cos’è il compito, quando va usato, quali sono i passaggi in ordine, cosa significa che il lavoro è finito, quali output reali imitare come modello. Un paio d’ore di lavoro concentrato bastano per una prima bozza funzionante.

Il problema riguarda quello che questo metodo lascia fuori. Uno skill file descrive un processo in un momento preciso: se il processo cambia, se uno strumento a valle aggiorna un’interfaccia, se cambia una normativa interna, il file resta fermo dov’era. È un asset che decade se nessuno lo tocca, e la manutenzione richiede tanto lavoro quanto la scrittura iniziale, spesso di più, perché serve qualcuno che si accorga del disallineamento prima che produca un errore a valle.

La documentazione tecnica di Anthropic pone esplicitamente anche un tema di superficie: ogni skill file è una nuova porzione di sistema che un agente può eseguire, quindi anche una nuova porzione da mettere in sicurezza, versionare, controllare negli accessi. Non è scrivere e dimenticare: è più vicino a un piccolo pezzo di infrastruttura, con tutta la responsabilità che ne consegue nel tempo.


Scrivere il file è il lavoro facile. Tenerlo vero nei mesi successivi è quello che nessuno vuole fare.

Chi possiede il file possiede il processo

Un effetto collaterale resta di solito sotto silenzio. Quando la conoscenza tacita di una persona, il modo in cui scrive un case study, negozia un contratto, imposta un’analisi, viene trascritta in un file leggibile da un agente, quella conoscenza smette di appartenere solo a lei. Diventa un asset dell’azienda, indipendente da chi lo ha prodotto.

Per l’organizzazione è un guadagno evidente: meno dipendenza da singoli individui, meno rischio quando qualcuno lascia il team, più uniformità nei risultati. Per la persona che ha scritto il file la faccenda è più ambigua: la competenza distintiva che la rendeva difficile da sostituire diventa un documento che chiunque, o quasi, può eseguire. È un costo che va nominato apertamente, non nascosto sotto il linguaggio dell’efficienza. Il tema si intreccia con quanto già scritto su come l’AI ridisegna i ruoli nel software enterprise: la formalizzazione della conoscenza è spesso il primo passo, non l’ultimo, di una ristrutturazione più ampia.

Chi vince, chi rischia, cosa fare

Chi vince con questo spostamento è abbastanza chiaro: i fornitori di piattaforme agentiche guadagnano ogni volta che un’azienda investe tempo a costruire skill file dentro il loro ecosistema. Più file scritti, più lock-in, più costo se un giorno si vuole cambiare fornitore: è semplicemente il meccanismo economico che regge l’intera categoria di prodotto.

Chi rischia sono due categorie distinte. La prima è chi tratta lo skill file come un progetto concluso invece che come un asset da manutenere, e si ritrova tra sei mesi con un processo automatizzato che esegue istruzioni superate senza che nessuno se ne accorga. La seconda sono i dipendenti la cui competenza tacita, una volta trascritta, diventa più sostituibile, non meno. Sono discorsi che si intrecciano con quanto già emerso parlando di competenze per il 2026: la competenza che conta di più non è sempre quella che protegge di più chi la possiede.


La cosa più onesta da fare, prima di riscrivere ogni procedura aziendale in skill.md, è testarla su un singolo processo a basso rischio: qualcosa di ripetitivo, ben definito, dove un errore costa poco. Poi assegnare la manutenzione del file a una persona con tempo dedicato, non lasciarla come compito informale di chi lo ha scritto la prima volta, perché è esattamente il punto in cui la promessa delle poche ore smette di reggere. La memoria degli agenti resta un problema aperto, e uno skill file scritto male finisce per aggravarlo invece di risolverlo.


#Adessonews seleziona nella rete articoli di particolare interesse.
Se vuoi leggere l’articolo completo clicca sul seguente link
 Giulia Bianchi

Source link

Di