Claude Skills: il layer di expertise che trasforma un LLM in uno strumento professionale

La maggior parte delle persone che usa Claude lo fa nello stesso modo in cui usa un motore di ricerca: apre una conversazione, scrive quello che vuole, legge la risposta. Funziona. Ma è come usare un IDE senza plugin, senza snippet, senza configurazione del linter: tecnicamente è possibile, ma si lascia sul tavolo una quantità di potenziale difficile da quantificare.

Il sistema di Skill di Claude è esattamente quel layer di configurazione che trasforma l'interazione generica con il modello in qualcosa di più vicino a un agente specializzato e ripetibile. È una funzione nativa di Claude Code, lo strumento CLI di Anthropic per il lavoro agenticamente assistito ed è disponibile anche tramite la Claude API per chi integra le Skill in sistemi propri. Capire cosa è, come funziona sotto il cofano, e dove sta andando è utile sia per chi lavora direttamente con Claude Code, sia per chi progetta sistemi AI professionali.

Cosa sono le Skill: definizione tecnica e modello concettuale

Una Skill è un pacchetto di istruzioni strutturate che Claude legge e applica prima di affrontare una categoria specifica di compiti. La forma fisica è semplice: una cartella con un file principale in Markdown (SKILL.md) e, opzionalmente, risorse di supporto come script, template e documenti di riferimento.

La struttura canonica di una Skill è questa:

nome-skill/
├── SKILL.md          ← istruzioni principali (obbligatorio)
├── references/       ← documentazione di supporto (opzionale)
├── assets/           ← template, file pronti all'uso (opzionale)
└── scripts/          ← codice eseguibile (opzionale)

Il SKILL.md è composto da due parti distinte. Il frontmatter YAML, che contiene i metadati della Skill (nome, descrizione e parametri di controllo) e il corpo Markdown, che contiene le istruzioni operative vere e proprie.

yaml

---
name: technical-report
description: >
  Usa questa skill ogni volta che l'utente richiede la
  stesura di report tecnici, analisi architetturali,
  documentazione di sistema o comparative tra tecnologie.
  Attivala anche quando il contesto implica un destinatario
  tecnico, anche se la richiesta non lo specifica esplicitamente.
---

# Technical Report — Istruzioni operative

## Struttura standard
1. Executive summary (max 150 parole)
2. Contesto e obiettivo dell'analisi
3. Metodologia o approccio adottato
4. Risultati e dati
5. Raccomandazioni operative
6. Appendici e riferimenti

## Tono e registro - Precisione terminologica prima della leggibilità - Nessuna frase di raccordo vuota ("è importante sottolineare che...") - Dati e metriche sempre accompagnati da fonte o contesto - Acronimi spiegati al primo utilizzo ## Cosa evitare - Bullet list come sostituto del ragionamento analitico - Affermazioni non verificabili presentate come fatti - Hedging eccessivo che svuota le raccomandazioni di utilità

Il meccanismo di triggering: come Claude decide quando applicare una Skill

Questo è il punto più delicato da capire, ed è anche quello che determina se una Skill funziona bene o male in produzione.

Claude non applica una Skill perché gliene viene data istruzione esplicita nel prompt. La applica perché, esaminando i metadati di tutte le Skill disponibili (solo il nome e la descrizione, non il corpo completo) decide autonomamente che quella Skill è rilevante per il compito richiesto. È un processo di pattern matching semantico che avviene in fase di preprocessing, prima che venga generata la risposta.

Tecnicamente, Claude Code costruisce un blocco <available_skills> dentro il tool system, popolato con nome e descrizione di ogni Skill trovata nelle cartelle di competenza. Claude legge quel blocco e decide se e quale Skill caricare per la conversazione in corso.

Il sistema usa un modello di caricamento progressivo a tre livelli:

Livello 1 — Metadati: nome e descrizione di ogni Skill disponibile. Sempre in contesto, costo minimo in termini di token. È su questi dati che Claude decide se caricare il livello successivo.

Livello 2 — Corpo della SKILL.md: le istruzioni operative complete. Vengono caricate solo quando il triggering ha successo. La documentazione ufficiale raccomanda di mantenerle sotto le 500 righe per non impattare la finestra di contesto.

Livello 3 — Risorse esterne: file in references/, assets/, scripts/. Claude accede a questi file tramite bash, li legge o li esegue, solo quando le istruzioni nel livello 2 lo indicano esplicitamente. Questo livello è illimitato in dimensione: lo script non entra mai nel contesto come codice, solo il suo output.

La conseguenza pratica di questa architettura è che la descrizione nel frontmatter è il vero punto critico del sistema. Una descrizione vaga produce triggering inconsistente. Una descrizione troppo generica crea conflitti con altre Skill. La documentazione di Anthropic su questo punto è esplicita: le descrizioni devono anticipare i casi d'uso impliciti e coprire le formulazioni che un utente reale potrebbe usare senza sapere che esiste quella Skill.

Un esempio concreto di descrizione debole vs. descrizione efficace:

Debole:

yaml

description: Skill per scrivere email professionali.

Efficace:

yaml

description: >
  Usa questa skill quando l'utente deve scrivere o
  riscrivere email in contesti professionali: follow-up
  commerciali, comunicazioni con clienti, escalation
  interne, richieste a fornitori, risposte a lamentele.
  Attivala anche quando l'utente chiede "come scrivere"
  o "aiutami con" senza menzionare esplicitamente il
  formato email, se il contesto lo suggerisce.

La differenza non è stilistica. È funzionale.

Due tipi di invocazione: automatica e diretta

Uno degli aspetti più operativi del sistema e spesso trascurato è che le Skill si possono invocare in due modi distinti, con semantiche diverse.

Invocazione automatica (model-driven): Claude rileva la pertinenza e carica la Skill autonomamente, senza intervento esplicito dell'utente. È il caso d'uso principale per le Skill di tipo reference (convenzioni di codice, style guide, knowledge di dominio) dove si vuole che il contesto specializzato sia sempre disponibile quando pertinente.

Invocazione diretta (user-driven): l'utente digita /nome-skill per attivare la Skill esplicitamente. È il caso d'uso principale per le Skill di tipo action: workflow con effetti collaterali, operazioni che richiedono controllo del timing, procedure di deployment, commit, invio di messaggi. Cose per cui non si vuole che Claude decida autonomamente il momento giusto.

Il frontmatter controlla questo comportamento tramite due flag:

yaml

---
name: deploy-production
description: Pipeline di deploy su ambiente di produzione.
disable-model-invocation: true    # Solo l'utente può invocarla con /deploy-production

yaml

---
name: api-conventions
description: Convenzioni API di questo codebase.
user-invocable: false             
# Solo Claude la carica automaticamente, non è un comando utile per l'utente

Questa granularità di controllo è uno degli elementi più raffinati del sistema: permette di distinguere nettamente tra strumenti di conoscenza passiva e strumenti di azione attiva, con permissioning esplicito per ciascun tipo.

Reference vs. Action Skill: la tassonomia ufficiale

La documentazione ufficiale di Anthropic distingue due categorie di Skill che riflettono pattern d'uso fondamentalmente diversi.

Le Reference Skill portano conoscenza che Claude applica in background durante la sessione. Convenzioni, pattern, style guide, knowledge di dominio specifico. Non sono "comandi" che fanno qualcosa, sono contesto che modifica come Claude ragiona. Una Skill che descrive le convenzioni di un legacy system, le regole terminologiche di un settore regulated, o le norme redazionali di una pubblicazione rientra in questa categoria. Di solito si configura con user-invocable: false.

Le Action Skill istruiscono Claude a eseguire una sequenza di operazioni specifiche. Sono progettate per essere invocate con /nome-skill e spesso includono script, chiamate a strumenti, workflow multi-step. Una Skill per generare commit message dallo staged diff, per creare documentazione da un file sorgente, per eseguire una review strutturata di una PR. Di solito si configura con disable-model-invocation: true.

La distinzione non è solo concettuale: impatta direttamente la struttura del SKILL.md, il tipo di frontmatter che ha senso usare, e il modo in cui gli utenti interagiranno con la Skill nel lavoro quotidiano.

Skill vs. System Prompt vs. Memory: chiarire la tassonomia

Chi lavora con LLM in contesti professionali ha già incontrato i concetti di system prompt e memory. Le Skill si aggiungono a questo ecosistema, ma occupano uno spazio architetturale distinto. Confonderli porta a progettare soluzioni inefficienti.

Il system prompt definisce il comportamento globale e persistente del modello per tutta la durata di una sessione o di un deployment. È la configurazione base dell'assistente: personalità, regole di output, vincoli operativi. Non è contestuale, viene applicato sempre, a prescindere dal compito.

La memory gestisce informazioni sull'utente che devono persistere tra sessioni diverse: preferenze, contesto personale o professionale, informazioni ricorrenti. È centrata sull'identità dell'utente, non sul compito.

Le Skill sono expertise specializzata attivata on-demand in base al contesto del compito. Non sono persistenti nel senso della memory — non ricordano lo stato tra sessioni — e non sono globali come il system prompt. Sono modulari, specializzate, intercambiabili.

In Claude Code, l'ecosistema completo include anche CLAUDE.md (il file di configurazione di progetto, letto all'inizio di ogni sessione), MCP servers (che estendono i tool disponibili), hooks (che automatizzano azioni su eventi specifici) e subagent (per workflow paralleli o isolati). Le Skill si integrano con tutti questi componenti, una Skill può invocare tool MCP, lanciare subagent, o referenziare istruzioni dal CLAUDE.md, ma mantengono la loro identità di layer di expertise on-demand.

La composizione più efficace usa tutti questi strumenti in sinergia: CLAUDE.md porta il contesto di progetto, la memory porta il contesto sull'utente, le Skill portano la competenza specifica sul compito, gli MCP server portano la connettività verso sistemi esterni.

Cosa può contenere una Skill: le capacità reali del sistema

Una Skill non è solo un file di testo con istruzioni, è un ambiente di lavoro completo che può contenere:

Istruzioni operative strutturate: le regole che Claude deve seguire per il compito. Possono includere workflow step-by-step, condizioni, regole di formattazione, checklist di qualità.

Esempi input/output: questa è probabilmente la feature più sottovalutata. Claude applica il ragionamento per analogia in modo molto efficace. Includere 3-5 esempi concreti di input atteso e output ideale dentro una Skill produce risultati significativamente più coerenti rispetto alle sole istruzioni astratte. È la differenza tra "scrivi in modo conciso" e mostrare cinque esempi di cosa significa "conciso" in quel contesto specifico.

File di riferimento: il SKILL.md può linkare a file aggiuntivi (FORMS.md, REFERENCE.md, schemi di database, specifiche tecniche) che Claude legge tramite bash solo quando necessario. Questo permette Skill molto ricche senza appesantire il contesto nelle sessioni dove quella profondità non serve.

Template e asset: file pronti all'uso che Claude utilizza come punto di partenza invece di costruire da zero ogni volta. Un documento già formattato, un foglio Excel con la struttura dati corretta, un file HTML con il layout atteso.

Script eseguibili: script Python, Bash o di altro tipo che Claude esegue tramite bash e di cui riceve solo l'output. Il codice dello script non entra mai nel contesto: questo significa che operazioni computazionalmente costose o che accedono a sistemi esterni possono essere delegate allo script senza consumare token aggiuntivi.

Il campo allowed-tools nel frontmatter permette di limitare quali tool Claude può usare durante l'esecuzione di una Skill, utile per Skill di tipo read-only che non dovrebbero avere accesso a operazioni di scrittura:

yaml

---
name: codebase-analysis
description: Analisi strutturale del codebase per review e refactoring.
allowed-tools: Read, Grep, Glob

Come creare e installare una Skill: il processo operativo

Dove salvare le Skill

Le Skill in Claude Code possono essere salvate in due percorsi con scope diversi:

• ~/.claude/skills/nome-skill/ - disponibile globalmente in tutti i progetti
• .claude/skills/nome-skill/ - disponibile solo nel progetto corrente

La scelta dipende dalla natura della Skill: quelle legate a convenzioni personali o strumenti usati ovunque vanno in scope globale; quelle legate a un progetto specifico (schemi di database, API di un cliente, stile di una pubblicazione specifica) vanno in scope di progetto.

Fase 1: Identificare il compito candidato

Il candidato ideale per una Skill è un compito che ricorre con frequenza, ha output riconoscibili e abbastanza standardizzati, e richiede di rispiegare le stesse regole ogni volta. Se ci si trova a copiare e incollare lo stesso blocco di istruzioni in più conversazioni, quella è una Skill in attesa di essere scritta.

Fase 2: Raccogliere i riferimenti

rima di scrivere istruzioni, è utile raccogliere 3-5 esempi di output ottimali. Questi esempi costituiranno la parte più efficace della Skill — Claude ragiona per analogia molto più efficacemente che per regole astratte.

Fase 3: Scrivere il SKILL.md

La struttura minima operativa:

markdown

---
name: nome-breve-senza-spazi
description: >
  Descrizione assertiva e specifica di quando usare
  questa skill. Includere casi d'uso espliciti e
  impliciti. Almeno 3-5 righe.
disable-model-invocation: true   # opzionale, solo per action skill
---

# Nome Skill — Istruzioni

## [Sezione principale]
[Istruzioni operative]

## Esempi
**Input:** [esempio di richiesta tipica]
**Output atteso:** [esempio di risposta ideale]

Fase 4: Test e iterazione

Il testing efficace si fa su richieste reali, non su casi costruiti ad hoc. Vanno usate le stesse formulazioni del lavoro quotidiano, incluse quelle vaghe o implicite. Il comando /context in Claude Code permette di verificare se le Skill disponibili rientrano nel budget dei metadati o se alcune vengono escluse per sovraffollamento.

Un dettaglio tecnico rilevante: le descrizioni di tutte le Skill attive vengono caricate nel contesto con un budget dinamico pari al 2% della finestra di contesto, con un fallback di 16.000 caratteri. Se le Skill attive superano questo budget, alcune vengono escluse. È un limite da tenere presente quando si costruisce un ecosistema di molte Skill.

Fase 5: Distribuzione

er chi usa Claude Code in un team, la distribuzione di Skill avviene semplicemente mettendo i file nelle cartelle .claude/skills/ del repository condiviso, che finiscono quindi sotto version control. Per chi usa le Skill tramite la Claude API, Anthropic mette a disposizione endpoint dedicati (/v1/skills) attraverso cui caricare Skill custom condivise a livello di organizzazione.

Vantaggi per il professionista: cosa cambia concretamente

Eliminazione del "prompt debt"

Chi lavora con LLM in modo intensivo accumula inevitabilmente quello che si potrebbe chiamare "prompt debt": istruzioni, regole, contesti e specifiche che vanno riscritte o copiate in ogni nuova conversazione. Questo debito diventa un costo operativo reale: tempo, attenzione, rischio di dimenticare un vincolo critico.

Le Skill azzerano questo debito per i compiti ricorrenti. Le istruzioni vengono scritte una volta, testate e, da quel momento, sono sempre disponibili senza sforzo aggiuntivo.

Coerenza dell'output in contesti multi-utente

In un team dove più persone usano Claude per compiti simili, la variabilità dell'output è uno dei problemi più difficili da gestire con i soli prompt. Ogni persona formula le richieste in modo diverso, porta contesti diversi, ha aspettative diverse su cosa costituisce un buon output.

Una Skill condivisa risolve questo problema a monte: definisce lo standard di output a livello di strumento, non di singolo utente. Il risultato è una coerenza che non dipende dalla disciplina del team, ma è intrinseca al modo in cui lo strumento funziona.

Portabilità del know-how

Una Skill è una forma di know-how esplicito e trasferibile. Contiene non solo le istruzioni operative, ma anche gli esempi, le eccezioni, i casi limite identificati nell'uso reale. Un professionista che ha costruito una Skill efficace per la sua area di competenza ha prodotto qualcosa che un collega può installare e usare immediatamente, senza il processo di trial and error che di solito accompagna l'adozione di un nuovo strumento.

È una forma di knowledge management che funziona perché è direttamente integrata nello strumento di lavoro, non in un documento separato che nessuno legge.

Riduzione del carico cognitivo nelle conversazioni complesse

In un workflow dove Claude è parte di un processo articolato (analisi, revisione, produzione di output in formati specifici, iterazione su feedback) dover gestire esplicitamente le regole del compito mentre si gestisce il compito stesso crea interferenza cognitiva. Le Skill tolgono dal tavolo la parte procedurale e lasciano spazio alla parte sostanziale del lavoro.

I limiti reali: cosa le Skill non fanno

Le Skill non hanno stato. Non ricordano l'output di una conversazione precedente, non tracciano progressi su un progetto multi-sessione, non si aggiornano automaticamente in base al feedback ricevuto. Ogni sessione inizia da zero, con la Skill che porta il contesto di dominio ma non quello storico.

Il triggering automatico non è deterministico. Diversi utenti hanno riportato difficoltà nell'ottenere che Claude attivi autonomamente una Skill senza invocazione diretta, anche con descrizioni ben scritte. La via pragmatica, ovvero usare /nome-skill quando si vuole essere certi dell'attivazione, è spesso più affidabile dell'attivazione automatica per le Action Skill.

Il budget dei metadati è un vincolo reale. Con molte Skill attive, si può raggiungere il limite del 2% della finestra di contesto. /context permette di diagnosticarlo, ma la soluzione richiede di ridurre il numero di Skill attive globalmente o di spostare alcune in scope di progetto.

La compatibilità non è universale. Le Skill sono native di Claude Code e della Claude API. Chi usa Claude tramite claude.ai web senza Claude Code installato non ha accesso al sistema di Skill nello stesso modo. Prima di investire nella costruzione di un ecosistema di Skill per un'organizzazione, è necessario verificare la compatibilità con l'ambiente specifico in uso.

Possibili evoluzioni future: dove sta andando questo modello?

Le Skill, nella loro forma attuale, sono uno strumento utile ma ancora artigianale. La direzione che il modello suggerisce è quella di un ecosistema strutturato dove le Skill diventano artefatti di prima classe nell'architettura dei sistemi AI professionali.

Skill come standard di interoperabilità

Il formato delle Skill è già un artefatto portabile e versionabile. L'evoluzione naturale è un ecosistema di Skill condivisibili tra organizzazioni, settori, ruoli professionali, simile a quanto è successo con i plugin nei browser, con i package nei linguaggi di programmazione, con i connector nelle piattaforme di integrazione. Una Skill per la gestione dei contratti legali in ambito italiano, una per la produzione di report finanziari secondo gli standard IFRS, una per la documentazione tecnica in contesti regulated: oggetti che una community professionale produce, verifica, e mantiene. I Plugins di Claude Code — pacchetti che raggruppano Skill, agent, hook e MCP server — sono già un primo passo in questa direzione.

Skill con triggering adattivo

L'attuale meccanismo di triggering è statico: la descrizione viene scritta una volta e rimane invariata. Un'evoluzione prevedibile è quella di descrizioni che si raffinano automaticamente in base all'uso osservato: un sistema che impara quando una Skill è stata utile e quando non lo è stata. È un problema di meta-learning applicato a un contesto molto specifico e ben delimitato, e quindi tecnicamente più trattabile rispetto alla versione generale del problema.

Skill come interfaccia verso MCP

Il Model Context Protocol di Anthropic sta diventando uno standard de facto per l'integrazione tra Claude e sistemi esterni. La connessione naturale è quella di Skill che fungono da interfacce verso server MCP specifici: una Skill che sa come interrogare il CRM aziendale, come scrivere nel sistema di ticketing, come produrre output nel formato atteso dal gestionale. La Skill non si limiterebbe a istruire il modello su come rispondere, ma porterebbe con sé la connettività verso i sistemi che rendono quella risposta azionabile. I primi esempi di questa integrazione esistono già.

Pipeline di expertise componibili

I sistemi di automazione più sofisticati concatenano più agenti AI in pipeline dove l'output di uno diventa l'input del successivo. Le Skill potrebbero evolvere verso oggetti composabili che si attivano in sequenza: una Skill che riceve un brief grezzo, ne estrae i requisiti, li passa a una seconda Skill che produce la struttura, a una terza che genera il contenuto, a una quarta che applica le regole redazionali finali. Il campo agent nel frontmatter — che permette già oggi di specificare il tipo di subagent da usare per l'esecuzione di una Skill — è l'embrione di questa direzione.

Skill con stato e memoria di progetto

La limitazione più significativa del sistema attuale è l'assenza di stato tra sessioni. Un'evoluzione plausibile è quella di Skill che mantengono un contesto persistente sul progetto in corso, non sulla conversazione in sé, ma sullo stato del compito. Una Skill per la gestione di un progetto editoriale che sa in quale fase si trova il progetto, quali contenuti sono stati completati, quali sono in revisione. Questo richiederebbe un layer di persistenza esterno, ma l'architettura modulare delle Skill è compatibile con questa integrazione.

In sostanza…

Le Skill di Claude non sono una feature rivoluzionaria nel senso di un salto tecnologico. Sono qualcosa di più utile: una soluzione a un problema pratico e specifico che chiunque lavori con i modelli linguistici in modo professionale ha incontrato: la mancanza di un layer di configurazione specializzata, portabile, e indipendente dalla singola conversazione.

Il modello architetturale che propongono, metadati per il triggering, corpo per le istruzioni operative, risorse per il contesto e gli strumenti, permissioning granulare per tipo di invocazione, è pulito e sufficientemente generale da supportare casi d'uso molto diversi con la stessa struttura. Questo è raro in un settore dove ogni strumento tende a ottimizzare per il proprio caso d'uso specifico a scapito della generalità.

Per un professionista che usa Claude Code quotidianamente, costruire anche solo due o tre Skill ben progettate per i compiti ricorrenti della propria area è probabilmente uno degli investimenti a più alto ritorno disponibili oggi nell'ecosistema AI. Non perché le Skill siano magiche, ma perché il problema che risolvono (la ripetizione del contesto, la variabilità dell'output, la perdita di know-how implicito) è reale, costoso, e spesso invisibile finché non si vede l'alternativa.

Riferimenti

• Documentazione ufficiale Skills — Claude Code: code.claude.com/docs/en/skills

Documentazione ufficiale Agent Skills — Claude API: platform.claude.com/docs/en/agents-and-tools/agent-skills/overview

Nota redazionale: questo articolo fa riferimento alla documentazione ufficiale di Anthropic disponibile su code.claude.com/docs/en/skills e platform.claude.com/docs/en/agents-and-tools/agent-skills/overview, aggiornata a marzo 2026.