#39 | La Skill perfetta di Claude non si trova. Si costruisce.

Entra nell'officina. Oggi si lavora.

Te l’avevo promesso.

Nella puntata scorsa sulle Claude Skills ti ho mostrato la mappa. Trentasei modi diversi di strutturare il lavoro. Trentasei Skill reali, con autore, problema risolto, motivo per cui funzionano.

Hai visto che esistono. Hai capito cosa fanno.

Bene.

Adesso vieni dentro.

Questa puntata è diversa dalle altre. Non è un aggiornamento. Non è un caso studio. Non è una notizia dal mondo AI filtrata e commentata.

È un manuale operativo del barista.

Uno di quei numeri che al bancone escono raramente, ma quando escono non li butti via. Li tieni. Li rileggi. Li usi quando è il momento di costruire qualcosa che duri.

E proprio per questo ti avverto subito: sarà denso. Non ho tagliato per renderlo leggero. Ho tagliato solo quello che non serviva. Quello che resta, serve tutto.

Mettiti comodo. Prenditi il tempo. E se devi fermarti a metà, salva la puntata e torna quando puoi concentrarti davvero.

Perché c’è una differenza enorme tra leggere “questa Skill genera lead magnet su misura per ogni offerta” e saper costruire qualcosa del genere da zero.

Una cosa è usare la mappa. Un’altra è avere il saldatore in mano.

Oggi entriamo nell’officina.
Il caffè è già sul bancone.
Iniziamo.

---

💡 Pensiero del giorno

Costruire una Skill non è un problema tecnico. È un problema di chiarezza.

Se non sai esattamente cosa vuoi che la macchina faccia, lei lo inventerà. E l’invenzione, nel lavoro reale, si chiama errore.

---

🧪 AI in azione: Entra nell’officina

La puntata scorsa era un catalogo. Questa è un manuale.

Non ti mostro cosa esiste. Ti mostro come si fa.

Ogni Skill che funziona ha una struttura precisa dietro. Una logica. Una sequenza di decisioni che chi l’ha costruita ha preso, spesso sbagliando prima di azzeccarle.

Nei prossimi blocchi smonto quella struttura pezzo per pezzo.

Partiamo dal primo errore che fa quasi tutti: credere di sapere già cos’è una Skill.

---

#1 - Cos’è davvero una Skill (e cosa NON è)

Iniziamo dal punto in cui tutti si perdono.

Non perché siano stupidi. Perché Claude ha quattro strumenti diversi per ricevere istruzioni. E dall’esterno sembrano tutti la stessa cosa. Non lo sono. E confonderli è esattamente il motivo per cui la tua Skill funziona a metà, o non funziona affatto.

Facciamola semplice.

Le Project Instructions sono la voce di fondo del bunker. Claude le legge all’inizio di ogni conversazione, in silenzio, senza che tu le chieda. Servono a fissare il perimetro: chi sei, come parli, per chi lavori. Sono il contesto permanente. Non cambiano da task a task.

Il System Prompt è il livello dell’operatore. Se stai costruendo un’applicazione o integrando Claude via API, è lì che installi il comportamento base del modello prima ancora che l’utente apra bocca. Non è roba per chi usa Claude da interfaccia. Ma è utile saperlo.

Un prompt salvato è una scorciatoia, non un sistema. Tieni il testo da qualche parte, lo copi, lo incolli. Ogni volta che serve, lo richiami manualmente. Utile. Ma ancora dipendente da te.

Una Skill è altra cosa.

Una Skill è un file. Un documento strutturato che descrive un processo specifico nel dettaglio: cosa fare, come farlo, in che ordine, con quali vincoli, con quali esempi di riferimento. Claude la carica, la legge come se fosse un manuale operativo interno, e la applica ogni volta che quel tipo di task entra in gioco.

Non stai dicendo a Claude chi sei. Stai dicendo a Claude come si fa questa cosa precisa, nel modo in cui la faresti tu.

La distinzione sembra sottile. Non lo è.

Immagina di avere un collaboratore nuovo. Le Project Instructions gli spiegano che sei un consulente, che il tuo tono è diretto, che i tuoi clienti sono imprenditori tra i 35 e i 55 anni. Questo è il contesto.

La Skill invece gli dice: “Quando ti chiedo di scrivere una newsletter, parti sempre da un’apertura narrativa di 3-5 righe che agganci il problema. Poi un Pensiero del giorno, breve, aforisma operativo. Poi la sezione centrale con questa gerarchia specifica. No elenchi puntati nelle prime due sezioni. Chiudi con una call to action indiretta.”

Quella è una procedura. Un modo di lavorare codificato in linguaggio che la macchina può eseguire ogni volta, con costanza, senza che tu ripeta nulla.

Le Project Instructions gestiscono il carattere. La Skill gestisce il processo.

Un’ultima cosa, e poi andiamo avanti.

Molti pensano che mettere tutto nelle Project Instructions risolva il problema. Scrivono istruzioni chilometriche, aggiungono strato su strato, e poi si stupiscono che Claude le ignori parzialmente o le applichi in modo inconsistente.

Il motivo è semplice: le Project Instructions non sono pensate per contenere processi complessi. Sono pensate per il contesto. Più le sovraccarichi, meno efficaci diventano.

Le Skill esistono proprio per separare il contesto dal processo. Una cosa per volta. Una testa per ogni lavoro.

---

#2 - L’anatomia di una Skill ben costruita

Ogni Skill che funziona ha la stessa struttura interna. Non importa se serve a scrivere newsletter, analizzare contratti, strutturare report post-call o fare l’onboarding di un nuovo cliente.

La struttura è sempre la stessa. Cambia il contenuto. Non lo schema.

Vediamolo pezzo per pezzo.

Header descrittivo.

Il primo blocco di ogni Skill non è per te. È per Claude.

Quando una Skill viene caricata in un Project, Claude non sa automaticamente quando usarla e quando ignorarla. L’header risolve questo problema. Dice: come si chiama questa Skill, cosa fa in una riga, in quali situazioni è rilevante, in quali non lo è.

Senza header chiaro, Claude la applica dove non serve. O peggio: la ignora quando serve, perché il contesto non combacia.

Un header scritto male non è un problema estetico. È un problema funzionale.

Trigger di attivazione.

Quando scatta questa Skill? Quali parole chiave la attivano? Quali richieste, quali contesti, quali segnali fanno sì che Claude la riconosca come pertinente?

Questo è il meccanismo che trasforma un documento passivo in un processo attivo.

Se scrivi “Aiutami con la newsletter”, Claude deve sapere se quella frase attiva la Skill Newsletter o la Skill Content Creation o nessuna delle due. I trigger sono la risposta. Più sono precisi, meno spazio c’è per l’interpretazione casuale.

Istruzioni operative in sequenza.

Il corpo della Skill.

Non “produci un buon output”. Non “tieni conto del tono”. Fasi numerate. Azioni specifiche. Output atteso per ogni step.

C’è un test pratico che funziona sempre: riesci a leggere le istruzioni a voce alta a un collaboratore al primo giorno, senza che faccia domande? Se la risposta è no, le istruzioni non sono abbastanza chiare. E se non sono chiare per un umano, per Claude non lo sono di certo.

Esempi di input e output.

Questo è il componente più sottovalutato in assoluto. E spesso il più potente.

Claude impara dagli esempi molto meglio che dalle spiegazioni astratte. Un esempio concreto di cosa vuoi ricevere, con il relativo input che lo ha generato, vale più di un paragrafo di istruzioni teoriche.

Non stai “mostrando” come funziona. Stai calibrando il modello su uno standard reale.

Se hai già un output perfetto che hai prodotto in passato, è oro puro. Mettilo nella Skill. Diventa il punto di riferimento che Claude cerca di replicare ogni volta.

Vincoli e limiti.

Cosa questa Skill non deve fare. Cosa deve evitare. Quali errori ricorrenti deve prevenire attivamente.

I vincoli non sono limitazioni: sono protezioni.

Una Skill senza vincoli espliciti tende a espandersi verso il default. E il default di Claude non è sempre il tuo standard.

Esempio concreto: se non scrivi “non usare mai elenchi puntati nell’apertura”, Claude li userà quando la struttura del contenuto lo suggerisce. Perché per lui è una scelta ragionevole. Per te è una violazione del tono.

I vincoli trasformano le intenzioni in regole. E le regole, nel lavoro reale, si chiamano qualità consistente.

Versione e data di revisione.

Non glamour. Ma necessario.

Una Skill è un documento vivo. Il tuo processo cambia. Il tuo tono si affina. Il tuo mercato si sposta.

Se non sai quando hai aggiornato la Skill l’ultima volta, probabilmente stai usando istruzioni vecchie per produrre contenuti nuovi. E la deriva si accumula piano piano, fino a quando ti accorgi che l’output non ti soddisfa più, senza capire perché.

Una riga in fondo. “Versione 1.2 — aggiornata in marzo 2025. Modificato il trigger e aggiunto esempio di output.” È tutto quello che serve per tenere il sistema sotto controllo.