Nel lavoro di consulenza Adobe c’è una quota di attività che si ripete a ogni progetto: preparare un documento di analisi, controllare che un requisito sia coperto, smistare le richieste che arrivano, riformattare un deliverable secondo il template del cliente. Non è il lavoro che dà valore, ma è quello che mangia le ore. Da qualche mese ho smesso di rifarlo da zero ogni volta e ho iniziato a costruirmi dei mattoncini riutilizzabili: skill e plugin per Claude Code e per gli agenti che uso tutti i giorni. Questo articolo è il resoconto onesto di cosa ho costruito, perché standardizzare mi ha fatto risparmiare ore vere, e cosa ho sbagliato per strada.
Cosa intendo per skill e plugin
Chiarisco i termini, perché si fa confusione. Una skill, nel mio uso, è un pacchetto di istruzioni operative che insegna all’agente a fare bene un compito specifico e ripetibile: cosa leggere, in che ordine, quali controlli fare, che formato produrre in output. Non è codice, è procedura scritta in modo che la macchina la esegua in modo consistente. Un plugin per Claude Code è il contenitore che tiene insieme più skill, eventuali comandi e la configurazione dei connettori (MCP) necessari. Il tutto gira dentro Claude Code o dentro un agente costruito con l’Agent SDK, e da gennaio anche dentro Cowork per il lavoro più conversazionale.
La cosa importante non è la tecnologia, è il cambio di mentalità. Fino a un anno fa il mio rapporto con un assistente AI era: apro una chat, spiego il contesto, ottengo una risposta, chiudo. Ogni volta ripartivo da zero. Con le skill ho iniziato a trattare i prompt come si trattano le funzioni nel software: le scrivi una volta, le testi, le riusi. È la differenza tra improvvisare e avere un metodo.
I tre tipi di mattoncino che uso di più
Guardando cosa mi sono effettivamente costruito, i miei mattoncini ricadono in tre famiglie.
1. Triage. Sono le skill che smistano. Su un portfolio di clienti in application management arrivano richieste continue: una promo che non si applica, un prodotto che non compare a catalogo, una domanda tecnica. La skill di triage legge la richiesta, la classifica per tipo, priorità e complessità, recupera il contesto del cliente (che tipo di contratto ha, quante ore residue) e prepara una bozza di primo riscontro più una nota interna con la diagnosi e la stima. Non chiude il ticket al posto mio: prepara il terreno perché io decida in trenta secondi invece che in dieci minuti. Il valore del triage è che toglie il carico cognitivo del “da dove comincio”.
2. Generazione di deliverable. Sono le skill che producono documenti. La compilazione di un requisito funzionale in risposta a una RFP, il verbale di un workshop, un report mensile: tutta roba che ha una struttura fissa e un contenuto variabile. Qui la skill fa due cose. Impone il formato giusto (il template, le sezioni, il tono) e riusa i miei asset — testi di riferimento, referenze, descrizioni di competenze — invece di reinventarli. Un requisito non funzionale sulla sicurezza o sulle performance lo si scrive in un modo abbastanza standard: la skill parte dalla mia base e la adatta al bando specifico, poi io reviso. Il risparmio qui è netto e misurabile in ore.
3. Controlli. Sono le skill meno appariscenti ma, secondo me, le più preziose. Fanno verifica: la review di coerenza su un deliverable lungo (i numeri tornano tra una sezione e l’altra? il glossario è usato in modo uniforme?), il confronto tra ore dichiarate a sistema e ore reali tracciate, il controllo che una nuova certificazione sia stata propagata su tutti i punti del sito dove compare. Sono i controlli che di solito salti quando sei di corsa, e sono esattamente quelli che ti fanno fare brutta figura quando li salti. Delegarli a una skill significa che vengono fatti sempre, non solo quando ho tempo.
Perché standardizzare fa risparmiare ore
Il risparmio non arriva dalla singola esecuzione più veloce. Arriva da tre effetti composti.
Il primo è che elimini il tempo di setup. Ogni volta che rispieghi il contesto a un assistente stai pagando una tassa. Una skill quel contesto lo ha già dentro: sa com’è fatto il mio cliente tipo, sa che formato voglio, sa quali controlli servono. La tassa la paghi una volta, quando scrivi la skill.
Il secondo è la consistenza. Due deliverable prodotti a distanza di un mese, magari in giornate diverse di stanchezza diversa, escono uguali per struttura e qualità. Questo abbassa il tempo di review, che è il vero collo di bottiglia. Se so che l’output rispetta sempre lo stesso standard, controllo le eccezioni invece di rileggere tutto.
Il terzo, meno ovvio: standardizzare ti costringe a rendere esplicito il tuo metodo. Per scrivere una skill di triage ho dovuto mettere nero su bianco come ragiono quando classifico un ticket. Quel lavoro di esplicitazione ha migliorato il mio processo anche fuori dall’AI. È lo stesso beneficio che si ottiene scrivendo la documentazione di un sistema: capisci meglio ciò che stai descrivendo.
Le lezioni che ho imparato (a mie spese)
Non è andato tutto liscio. Alcune cose le ho capite sbagliando.
Le skill troppo grandi non funzionano. I miei primi tentativi erano skill onnicomprensive che cercavano di fare triage, diagnosi e risposta tutto insieme. Diventavano ingestibili e imprevedibili. La svolta è stata spezzarle in mattoncini piccoli, ciascuno con un compito solo, che si concatenano. Vale la stessa regola del buon codice: una funzione, una responsabilità.
Il confine tra “prepara” e “esegue” va tenuto stretto. Le mie skill quasi sempre si fermano un passo prima dell’azione irreversibile: preparano la bozza, propongono la modifica, ma l’ok lo do io. Su un contesto cliente questo non è un dettaglio, è la condizione per potermene fidare. Un agente che pubblica o modifica in autonomia senza checkpoint è un rischio che non voglio correre, e i clienti nemmeno.
La manutenzione è reale. Una skill non è un artefatto che scrivi e dimentichi. Quando cambia un template, un processo o un contratto, la skill va aggiornata, altrimenti produce output vecchi con la sicurezza di quelli nuovi — che è peggio di non averla. Le tratto come pezzi di software: hanno un owner (io) e vanno mantenute.
Il valore non è nell’AI, è nella codifica del mestiere. Questa è la lezione che porto a casa. Il modello è bravo, ma la parte che fa la differenza è quella che ci metto io: sapere quali controlli contano, che struttura deve avere un deliverable, dove si nasconde l’errore in un requisito. La skill è il contenitore in cui deposito vent’anni di lavoro su Magento e Adobe Commerce. Senza quel deposito, è solo un prompt generico.
Dove sto andando
La direzione che vedo è passare da skill isolate a un vero toolkit organizzato in plugin, condivisibili e versionati, con i connettori MCP giusti già configurati. L’obiettivo non è automatizzare il consulente, è togliere dal piatto del consulente tutto ciò che non richiede giudizio, per lasciargli il giudizio. Le ore che risparmio sul lavoro ripetitivo le riverso dove servo davvero: capire il problema del cliente e decidere cosa fare. Quello, per fortuna, un mattoncino non lo fa al posto mio.
Mini-FAQ
Qual è la differenza tra una skill e un plugin per Claude Code?
Una skill è un pacchetto di istruzioni che insegna all’agente a svolgere un compito specifico e ripetibile. Un plugin è il contenitore che raggruppa più skill, comandi e la configurazione dei connettori MCP necessari.
Che tipo di skill conviene costruire per prima?
Quelle di triage e di controllo, perché tolgono carico cognitivo e riducono gli errori senza toccare azioni irreversibili. La generazione di deliverable dà il maggior risparmio di ore, ma richiede prima di aver messo per iscritto i propri template.
Le skill sostituiscono il consulente?
No. Standardizzano il lavoro ripetitivo e mantengono l’umano sul checkpoint decisionale. Il valore resta nel giudizio e nella conoscenza di dominio depositata nella skill.
Sull’autore. Sono Fabio Canovi, consulente Adobe presso il gruppo Lutech, certificato Adobe Commerce, Adobe Experience Manager, Adobe Analytics e Adobe Target. Costruisco agenti, MCP e skill per rendere più veloce e consistente il lavoro quotidiano sui progetti Adobe, e su questo blog racconto cosa funziona davvero, dal punto di vista di chi le cose le costruisce.