𝗘𝗩𝗢𝗟𝗨𝗭𝗜𝗢𝗡𝗘 𝗗𝗜 𝗨𝗡𝗔 𝗦𝗞𝗜𝗟𝗟 𝗗𝗜 𝗖𝗟𝗔𝗨𝗗𝗘

Una volta definita una skill non diventa qualcosa di immutabile, al contrario è un documento destinato ad un miglioramento continuo, in Claude e in tutte le AI.

Chi usa l’AI per lavoro, non per curiosità occasionale, si trova prima o poi nella stessa situazione. Le prime conversazioni funzionano bene, i risultati sono incoraggianti, e allora si comincia a usarla di più. Ma con l’uso quotidiano arriva la ripetizione, ogni nuova chat parte da zero e tu ti ritrovi a riscrivere le stesse istruzioni, a correggere gli stessi errori, a riallineare lo stesso tono.

«Non usare il grassetto per l’enfasi, usa il corsivo» «Il pubblico è fatto di professionisti, non di studenti» «Non scrivere “fondamentale”, non scrivere “cruciale”, non aprire con “in un mondo sempre più”» Lo fai una volta, due, dieci. Alla ventesima capisci che il problema non è l’AI, sei tu che non hai strutturato il modo in cui ci lavori.

Quando l’uso diventa quotidiano personalizzare l’AI è una necessità operativa. E non è un’operazione che fai una volta e poi dimentichi, è un processo che evolve con l’uso, esattamente come evolve il tuo modo di lavorare.

In Claude questo concetto si chiama «skill», un set strutturato di istruzioni che l’AI carica quando serve, con regole di stile, workflow, informazioni sul contesto e sul pubblico. Ma il principio è lo stesso su qualsiasi sistema. Che si tratti delle Custom Instructions di ChatGPT, delle istruzioni di sistema di Gemini o di un file di testo ben organizzato da incollare all’inizio di una conversazione, il meccanismo è identico. Stai dicendo all’AI come deve lavorare per te, senza dover ricominciare da capo ogni volta.

E i campi di applicazione sono molto più ampi di quanto si potrebbe pensare, la scrittura è solo uno dei tanti. Una skill può definire come l’AI deve condurre un’analisi di dati, con quale metodologia, quali controlli applicare, come presentare i risultati. Un’altra può codificare il workflow di revisione contrattuale di uno studio legale, con le clausole da verificare, i criteri di rischio, le soglie di escalation. Ancora può strutturare il processo di preparazione di una call commerciale, dalla ricerca sul prospect alla scaletta della conversazione. Oppure può formalizzare come un team di prodotto gestisce le specifiche funzionali, dal problema alla user story ai criteri di accettazione. In ciascuno di questi casi non si tratta di regole cosmetiche ma di processi operativi completi, con logiche decisionali, sequenze di verifica e criteri di qualità specifici del mestiere.

Qui parlo della mia skill per la scrittura, dalla nascita alla revisione generale, il tutto avvenuto nello spazio di tre mesi. Non è un tutorial tecnico, è il racconto di un percorso che credo illustri bene un principio più generale.

Partire dal bisogno, non dal cosa si può fare

Quando ho deciso di creare una skill dedicata alla scrittura non sono partito dalla domanda «cosa può fare una skill?» ma da «cosa mi trovo a ripetere ogni volta?». La differenza conta perché la prima domanda porta a esplorare funzionalità, la seconda porta a risolvere problemi concreti.

Nel mio lavoro produco molto testo, articoli per il blog, pezzi per riviste, post per i social, materiale formativo. E ogni piattaforma ha il suo tono, il suo pubblico, le sue regole.

Nel tempo avevo definito cosa volevo ottenere, senza però formalizzarlo, costruire la skill mi ha costretto a farlo. Ha finito per contenere il processo di lavoro completo, come si decide la struttura di un articolo, in quale ordine si procede, come si verificano le fonti prima di scrivere, che tipo di feedback ci si aspetta dall’AI e su cosa.

La fase di creazione è stata un lavoro di analisi prima ancora che di scrittura. Il tono da collega che condivide riflessioni, non da consulente che dispensa consigli. Le convenzioni tipografiche italiane che l’AI ignorava. La sequenza di passaggi che porta da un’idea a un testo pubblicabile, e il ruolo che l’AI dovrebbe avere in ciascuno di questi passaggi. Il risultato finale non è solo un set di istruzioni ma una mappa del mio metodo di lavoro resa esplicita.

Questo processo ha un effetto collaterale, spiegare a un sistema perché una certa costruzione non funziona obbliga a capirlo meglio. Descrivere un workflow per farlo eseguire a qualcun altro evidenzia le ambiguità e i passaggi dati per scontati. La skill, in altre parole, diventa anche uno strumento di autoconsapevolezza professionale.

I piccoli aggiustamenti, l’esperienza che la teoria non prevede

La prima versione della skill funzionava, ma l’uso quotidiano ha rivelato una serie di problemi che la progettazione a tavolino non poteva prevedere.

Alcuni erano dettagli stilistici, la lunghezza delle frasi indicata come «medio-brevi» lasciava troppo margine di interpretazione. Meglio un range numerico, 15-25 parole, con la precisazione che non è una regola rigida ma un riferimento.

Ma i gap più interessanti riguardavano il processo e l’interazione. Il workflow che avevo descritto era troppo lineare, non prevedeva i ritorni indietro che nella pratica sono inevitabili. Le istruzioni sul tono dicevano «usa un tono professionale ma accessibile», che è una descrizione corretta ma troppo vaga per produrre risultati consistenti. Nella pratica serviva qualcosa di più preciso, «il tono è quello di un collega che condivide riflessioni con altri professionisti in una situazione informale. Non è il tono di una consulenza, non è il tono di un blog aziendale, non è il tono di un comunicato stampa» Definire cosa non è si è rivelato altrettanto utile quanto definire cosa è.

Un altro gap riguardava la coerenza tra correzioni. Quando correggevo qualcosa in un punto del testo l’AI applicava la correzione lì, ma non verificava se lo stesso problema fosse presente altrove. Ho dovuto aggiungere un’istruzione esplicita, il principio di propagazione delle correzioni, che sembra ovvio ma senza istruzione esplicita non viene applicato.

Questi aggiustamenti si sono accumulati nell’arco di settimane, ciascuno piccolo in sé ma importanti nel complesso. Nessuno di loro poteva essere previsto in anticipo. Nascono dall’uso reale, dal notare che l’AI interpreta un’istruzione in modo diverso da come la intendevi, o che manca un caso che non avevi considerato. Il processo è inevitabilmente iterativo, la skill si affina man mano che l’uso concreto ne rivela i limiti.

L’evoluzione, quando l’esperienza cambia la struttura

Dopo un lungo uso quotidiano con la skill è arrivato il momento in cui i piccoli aggiustamenti non bastavano più. Non serviva un’altra regola in più, serviva ripensare l’impostazione.

La skill originale era uno strumento di scrittura generico, buono per chiunque scrivesse contenuti sulle AI. Quello che mancava era la dimensione personale e operativa, chi sono io come autore, per chi scrivo, come si articola il mio processo di lavoro, che ruolo ha l’AI in questo processo.

Il cambiamento più importante ha riguardato il ruolo dell’AI. Nella versione originale l’AI era un esecutore che seguiva regole. Nella versione evoluta è un collaboratore che verifica. Deve controllare la solidità delle mie argomentazioni, segnalare quando una valutazione è imprecisa o basata su premesse deboli, esporre le cose come ritiene che siano senza diplomazia eccessiva. In pratica gli ho chiesto di fare il partner intellettuale, non il segretario. La differenza nei risultati è stata meno testo compiacente e più osservazioni utili. Quando l’AI ti dice «questa argomentazione ha un punto debole qui» invece di eseguire senza fiatare, la qualità del prodotto finale migliora.

Il secondo cambiamento è stato strutturare il workflow editoriale in modo esplicito. Non più «scrivi bene», ma «come si arriva a scrivere bene», con cinque fasi definite. Si parte dalla raccolta del contesto e dalla definizione del pubblico. Si propone una struttura e la si valida prima di scrivere una sola riga, perché riscrivere un articolo mal strutturato costa più che pensarci prima. Si procede sezione per sezione con verifica continua. Si chiude con una revisione complessiva. Sembra burocratico, ma nella pratica questo workflow ha eliminato un problema frequente nel lavoro con l’AI, la tendenza a partire a scrivere subito senza aver verificato che la struttura regga.

Il terzo cambiamento è stato inserire il profilo dell’autore e delle piattaforme. Non una biografia, ma le informazioni operative, la mia filosofia di lavoro, il tipo di pubblico per ciascuna piattaforma, le regole specifiche di formato e registro. Ora quando chiedo un articolo per il blog l’AI sa già che scrivo in prima persona e che l’autoironia è parte del mio stile, non qualcosa da correggere. Quando chiedo un pezzo per una rivista sa che il registro cambia completamente. Non devo più spiegarlo ogni volta.

Il principio trasferibile, costruirsi la propria architettura

Fin qui ho raccontato un’esperienza specifica con Claude, ma il concetto è più ampio e vale la pena esplicitarlo.

Qualsiasi professionista che usa l’AI come strumento di lavoro quotidiano può costruirsi il proprio equivalente di una skill. Non serve una piattaforma che lo supporti nativamente. Un file di testo ben organizzato con le tue regole, il tuo contesto, il tuo workflow è già una skill, basta caricarlo all’inizio della conversazione. È meno elegante, meno automatico, ma funziona. Il principio è lo stesso, stai esternalizzando la memoria operativa del tuo metodo di lavoro in un formato che l’AI può utilizzare.

Il passaggio successivo, e più interessante, è pensare in termini di architettura. Non un unico set di istruzioni monolitico, ma un ecosistema di strumenti specializzati che si coordinano. Nel mio caso la skill di scrittura è il centro, ma si appoggia ad altre. Una per il brainstorming strutturato quando devo generare e valutare idee prima di scriverle. Una per organizzare materiale grezzo, note sparse, trascrizioni, appunti, in una struttura logica. Una per la revisione di testi già scritti, che è un compito diverso dalla produzione e richiede istruzioni diverse. Ciascuna fa una cosa sola e la fa bene.

Anche questo è un principio esportabile. Non serve che il tuo sistema supporti la composizione automatica tra strumenti. Puoi avere file di istruzioni diversi per compiti diversi e caricare quello giusto al momento giusto. Il valore non sta nell’automazione del caricamento, sta nell’aver pensato e progettato il tuo modo di lavorare con l’AI come un sistema, non come una sequenza di conversazioni indipendenti.

Il processo funziona allo stesso modo indipendentemente dallo strumento, formalizzare il proprio metodo di lavoro per renderlo utilizzabile dall’AI costringe a comprenderlo meglio. La skill, qualunque forma abbia, finisce per essere tanto uno strumento per l’AI quanto una mappa del proprio mestiere.

Nella pratica quotidiana

Lavorare con un set di istruzioni ben calibrato cambia l’esperienza in modo tangibile. Non è che l’AI diventa perfetta, continua a richiedere supervisione, correzioni, indirizzamento. Ma il punto di partenza è diverso. Invece di spendere i primi minuti di ogni conversazione a riallineare tono, stile e contesto, si parte già dal lavoro vero.

Il risparmio non è solo di tempo, è di energia cognitiva. Quando non devi più preoccuparti che l’AI ignori le tue convenzioni o produca testo con il tono sbagliato puoi concentrarti su quello che conta, la qualità dell’argomentazione, la chiarezza della struttura, l’efficacia della comunicazione.

Ma l’aspetto più interessante non è l’efficienza, è l’evoluzione. Una skill, o comunque la si voglia chiamare, non è un prodotto finito. È uno strumento che cresce con l’uso, che si adatta man mano che il modo di lavorare si chiarisce. Ogni correzione, ogni regola aggiunta, ogni aggiustamento che l’uso rivela necessario è un pezzo di conoscenza professionale che passa da implicita a esplicita.