I plugin di Claude Cowork

Un primo tutorial sui plugin di Cowork, componente fondamentale di questo nuovo prodotto del mondo Claude di Anthropic.

Quando sentiamo «plugin» pensiamo a del software, a del codice che aggiunge funzionalità a un programma. I plugin di Cowork sono una cosa diversa e la differenza merita attenzione.

Un plugin di Cowork è un pacchetto di file di testo che definiscono una competenza professionale strutturata. Non contiene codice eseguibile, si tratta di file di testo in formato markdown che descrivono procedure, criteri decisionali, checklist, workflow e conoscenze specifiche di un dominio professionale. È come se qualcuno avesse preso le procedure operative di un team specializzato, le checklist che un professionista esperto tiene nella testa e i criteri con cui valuta una situazione, e li avesse organizzati in una forma che un modello linguistico può consultare e applicare.

La metafora più vicina non è quella del plugin software tradizionale ma quella dell’onboarding di un nuovo collega. Quando un professionista senior trasferisce le proprie competenze a un junior non gli dà del codice: gli dà procedure, casi tipici, criteri di valutazione, esempi di come gestire le situazioni più comuni e indicazioni su quando è il caso di chiedere aiuto. I plugin di Cowork fanno esattamente questo, solo che il «collega junior» è Claude.

Questo ha un’implicazione pratica rilevante. Dato che i plugin sono file di testo e non codice, la barriera per crearli è più bassa di quanto ci si aspetterebbe. Non serve un programmatore, ma ovviamente serve qualcuno che conosca bene il proprio dominio e sappia descrivere le proprie procedure in modo strutturato. Anthropic ha anche incluso un meta-plugin il cui scopo è guidare l’utente nella creazione di nuovi plugin, sempre tramite conversazione con Claude, senza mai toccare una riga di codice.

Anatomia di un plugin

Per rendere concreto il discorso conviene guardare come è fatto un plugin. Il plugin Legal, uno degli undici rilasciati da Anthropic al lancio, è un buon esempio che funziona per tutti perché la struttura è la stessa.

Un plugin è composto da tre tipi di componenti.

  • I comandi sono le azioni che l’utente può attivare. Si presentano come «slash command» (il formato con la barra iniziale, tipo /review-contract) e rappresentano l’interfaccia tra l’utente e le capacità del plugin. Ogni comando è un file di testo che descrive un workflow completo passo per passo. Non è un programma che viene eseguito: è un insieme di istruzioni che Claude segue per guidare la conversazione e produrre il risultato richiesto.

  • Le skill sono la base di conoscenza specialistica. Se i comandi sono il «cosa fare», le skill sono il «come farlo bene». Contengono la competenza di dominio vera e propria, ovvero criteri di valutazione, classificazioni, best practice, checklist dettagliate. Claude le consulta quando deve applicare il giudizio professionale richiesto dal comando. Una skill può essere composta da diverse migliaia di parole perché deve coprire in profondità un ambito specifico.

  • I connettori sono il collegamento con gli strumenti che il professionista già usa. Qui entra in gioco il Model Context Protocol (MCP), lo standard aperto che permette a Claude di interagire con servizi esterni come Slack, Google Drive, Jira e molti altri. La cosa interessante è come sono progettati: i plugin non fanno riferimento a prodotti specifici ma a categorie di strumenti. Il plugin Legal non dice “usa Google Drive” ma “usa un servizio di cloud storage“. Lo stesso plugin funziona con Google Drive o con Box, purché esista un connettore MCP per quel servizio. Se un connettore non è disponibile il plugin non si blocca: segnala cosa manca e suggerisce di fare quella verifica manualmente.

Chi ha familiarità con i server MCP potrebbe notare una somiglianza strutturale: anche quelli sono pacchetti modulari con un manifest, componenti organizzati in directory e uno scopo di estensione delle capacità di Claude. Il pattern organizzativo è lo stesso, ma la natura del contenuto è diversa. Un server MCP è codice eseguibile che gira come processo separato e compie azioni concrete (una query, una chiamata API, un’operazione su file). Un plugin è testo che istruisce Claude su come comportarsi e quali criteri applicare. La differenza è tra dare a qualcuno un programma da eseguire e dargli un manuale operativo da seguire. Non a caso i due sistemi lavorano insieme: i plugin si appoggiano ai server MCP, attraverso i connettori, quando devono tradurre la competenza descritta nelle skill in azioni sul mondo esterno.

Il plugin Legal: un caso concreto

Per capire come queste parti lavorano insieme vale la pena guardare più da vicino il plugin Legal. È pensato per team legali interni alle aziende e copre diversi profili professionali, dai consulenti commerciali agli specialisti di privacy e compliance.

I comandi disponibili

Il plugin offre cinque comandi:

  • /review-contract analizza un contratto clausola per clausola confrontandolo con le posizioni standard dell’organizzazione.
  • /triage-nda fa uno screening rapido degli accordi di riservatezza in arrivo e li classifica per livello di rischio.
  • /vendor-check verifica lo stato degli accordi esistenti con un fornitore.
  • /brief genera briefing contestuali di vario tipo, dal riassunto quotidiano alla ricerca su un tema specifico.
  • /respond produce risposte standardizzate per le richieste più comuni.

Come funziona la revisione di un contratto

Il workflow di /review-contract è il più articolato e rende bene l’idea di cosa fa un plugin nella pratica.

Quando un operatore dell’ufficio legale attiva il comando e carica un documento, Claude non parte subito con l’analisi. Prima raccoglie il contesto chiedendo da quale parte si trova l’organizzazione (è il fornitore o il cliente?), quali sono le scadenze e se ci sono aree di attenzione specifiche. Poi cerca il playbook dell’organizzazione, un file di configurazione locale dove il team legale ha definito le proprie posizioni standard per ogni tipo di clausola, dal cap di responsabilità accettabile all’indennizzo nella norma fino alle condizioni che fanno scattare un’escalation.

La revisione procede clausola per clausola coprendo tutti gli aspetti rilevanti: limitazione di responsabilità, indennizzo, proprietà intellettuale, protezione dati, riservatezza, garanzie, termini di risoluzione, legge applicabile. Per ogni clausola il sistema produce una classificazione a tre livelli. Verde indica che la clausola è in linea con le posizioni dell’organizzazione o migliore. Giallo segnala una deviazione dallo standard che rientra in un margine negoziabile. Rosso indica un rischio materiale che richiede l’intervento di un responsabile senior.

Per le clausole gialle e rosse il plugin non si limita a segnalare il problema. Genera un testo alternativo specifico pronto per essere proposto alla controparte, con una motivazione professionale, una posizione di fallback e una stima dell’impatto commerciale. Organizza anche le clausole per priorità negoziale su tre livelli (irrinunciabili, preferenze forti, concessioni possibili) con una strategia suggerita.

Un framework che parla americano (e perché serve personalizzarlo)

C’è un aspetto che non è evidente finché non si legge il contenuto delle skill. Il framework analitico del plugin Legal è costruito su concetti di common law angloamericano. Tra gli elementi da verificare nella clausola sulla risoluzione delle controversie ci sono il «jury waiver» e il «class action waiver», istituti specificamente statunitensi (in Italia non c’è la giuria nei processi civili e le azioni collettive funzionano in modo diverso). La sezione sulla proprietà intellettuale usa il concetto di «work-for-hire», una categoria del copyright americano senza equivalente diretto nel diritto italiano. L’unica eccezione è la sezione sulla protezione dei dati, che cita esplicitamente il GDPR e le sue scadenze perché quel regolamento ha portata extraterritoriale.

Senza personalizzazione il plugin dichiara di usare «standard commerciali generalmente accettati» come riferimento, che nella pratica significa standard commerciali anglosassoni. Per un contratto tra due aziende italiane soggetto al diritto italiano, parte dell’analisi risulterebbe fuori fuoco. Non sbagliata in senso assoluto (molte categorie di clausole sono trasversali, soprattutto nei contratti B2B internazionali) ma costruita su presupposti giuridici che non corrispondono al contesto di civil law.

Qui entra in gioco il playbook. Ogni organizzazione può definire in un file locale le proprie posizioni contrattuali standard, i margini accettabili e le soglie di escalation. Il playbook calibra le posizioni commerciali: quale cap di responsabilità è accettabile, quale indennizzo rientra nella norma, a quali condizioni scatta l’escalation. È il primo livello di personalizzazione, quello che trasforma un’analisi generica in un’analisi su misura per il proprio team.

La differenza è la stessa che c’è tra chiedere un parere a un avvocato che non conosce la tua azienda e chiederlo al tuo consulente interno che lavora con te da anni. Un modello linguistico che sa cos’è una clausola di indennizzo è utile; un modello che sa che la tua organizzazione accetta l’indennizzo unilaterale solo se è limitato a un certo tipo di violazioni e con un cap collegato al valore del contratto è un’altra cosa.

Per un adattamento più profondo, ad esempio riscrivere il framework analitico per il diritto italiano, servirebbe intervenire direttamente sulle skill. È un lavoro diverso dalla compilazione del playbook, richiede competenza giuridica specifica, ma è reso possibile dal fatto che i plugin sono file di testo aperti e modificabili. È esattamente il tipo di adattamento per cui l’architettura aperta dei plugin è stata pensata.

Una reazione di mercato che dice qualcosa

Un dettaglio di contesto: il giorno della pubblicazione del plugin Legal diverse testate finanziarie hanno riportato cali nelle azioni di aziende del settore legal tech. La reazione sembra eccessiva, anche perché il plugin stesso avvisa che non fornisce consulenza legale e che ogni analisi va verificata da professionisti qualificati. Ma il fatto che il mercato reagisca così dice qualcosa su quanto vengano prese sul serio queste automazioni.

L’ecosistema: undici plugin al lancio

Il Legal è uno degli undici plugin che Anthropic ha rilasciato come open source. Non li ho esplorati tutti, ma la struttura e le descrizioni danno un’idea dell’insieme.

Il plugin Marketing include comandi per la coerenza con il brand, la pianificazione di campagne, l’analisi competitiva e la creazione di contenuti per diversi canali. Il plugin Sales copre la preparazione alle call commerciali, la ricerca sui prospect, il briefing quotidiano e la creazione di materiali commerciali. Il plugin Data offre esplorazione di dataset, visualizzazioni, dashboard interattive e query SQL.

Ci sono poi Product Management per specifiche di prodotto e roadmap, Productivity con gestione attività e memoria di lavoro, Enterprise Search per cercare informazioni attraverso tutte le fonti collegate, Finance per analisi finanziarie, Customer Support e persino Biology Research, a dimostrazione che il modello si applica a domini molto diversi tra loro.

Plugin che lavorano insieme

Un aspetto dell’architettura che non è immediatamente evidente è che tutti i plugin installati sono attivi contemporaneamente. Non c’è un meccanismo di attivazione o disattivazione selettiva: le skill, i comandi e i connettori di ogni plugin sono disponibili nella stessa sessione di lavoro. Se sono installati il plugin Legal e il plugin Marketing, nella stessa conversazione si può chiedere a Claude di analizzare un contratto e poi di redigere una comunicazione per il team seguendo le linee guida del brand.

Questo funziona perché ogni plugin è isolato nella propria directory con i propri componenti, senza conflitti tra plugin diversi: il sistema li scopre e li carica automaticamente. La combinabilità apre la strada a workflow composti che attraversano più domini professionali. Un esempio concreto: si potrebbe sviluppare un plugin che contiene le proprie regole di scrittura (stile, registro, pubblico target) e usarlo insieme a un plugin specializzato nell’analisi di documenti tecnici. Claude applicherebbe la competenza analitica del secondo e lo stile comunicativo del primo nella stessa sessione, senza dover trasferire manualmente il contesto da una conversazione all’altra. È il tipo di integrazione che risulterebbe molto più difficile da ottenere con strumenti separati.

Open source e possibilità di modifica

Tutti gli undici plugin di Anthropic sono rilasciati con licenza Apache 2.0, una delle più permissive tra le licenze open source. Consente l’uso, la modifica e la redistribuzione anche a fini commerciali, con l’unico obbligo di mantenere l’attribuzione originale e dichiarare le modifiche apportate. In concreto questo significa che chiunque può prendere un plugin esistente, adattarlo alle proprie esigenze e ridistribuirlo. Va precisato che questa è la scelta di Anthropic per i plugin di lancio; chi svilupperà plugin in futuro potrà adottare licenze diverse, più o meno restrittive.

La possibilità di modifica apre scenari interessanti. Un plugin progettato per un certo dominio può essere adattato per usi diversi senza riscrivere tutto da zero: basta sostituire le skill e i comandi mantenendo l’architettura. Per esempio, la struttura del plugin Legal (comandi che guidano un workflow, skill che contengono criteri di valutazione, connettori che collegano strumenti esterni) potrebbe essere riutilizzata per costruire un plugin destinato a un ambito completamente diverso, dal project management alla ricerca accademica. In alternativa il meta-plugin Cowork Plugin Management guida la creazione di plugin completamente nuovi, partendo da zero, sempre tramite conversazione con Claude.

Cosa sono i plugin

Il modello che Anthropic propone si potrebbe riassumere come «competenza professionale trasformata in istruzioni per un modello linguistico». Non è un’idea del tutto nuova (chiunque abbia scritto un system prompt personalizzato per Claude è andato nella stessa direzione) ma i plugin la portano a un livello di organizzazione e riusabilità diverso. Un plugin può essere condiviso, installato con un click e personalizzato per la propria organizzazione senza modificare la struttura originale.

La differenza pratica rispetto a un assistente AI generico è tangibile. Non è la stessa cosa chiedere a Claude di revisionare un contratto «in generale» e chiedergli di farlo secondo le posizioni contrattuali specifiche del tuo team legale, con testi alternativi pronti e una strategia negoziale suggerita.

Cosa manca ancora

Cowork è in research preview e ci sono assenze che pesano, soprattutto per chi immagina di usarlo in modo strutturato nel lavoro quotidiano.

  • La prima è la mancanza di memoria tra le sessioni. Ogni chat di Cowork parte da zero, infatti Claude non ricorda nulla di quello che si è fatto nella conversazione precedente. Il plugin Productivity include un workaround basato su file (un sistema di memoria a due livelli che salva su disco persone, acronimi, progetti e preferenze) ma è un espediente a livello di plugin, non una funzionalità nativa. Per passare contesto da una conversazione all’altra il metodo più affidabile resta quello di salvare un documento esplicito e farlo leggere nella chat successiva.

  • La seconda è l’assenza dei progetti. Chi usa Claude Desktop conosce la possibilità di creare progetti con istruzioni condivise, documentazione di riferimento e più conversazioni che attingono automaticamente allo stesso contesto. In Cowork questa funzionalità non esiste ancora. Per un team legale che volesse organizzare il lavoro in progetti separati (uno per l’analisi contrattuale, uno per il contenzioso, uno per la compliance) non c’è al momento un modo nativo per farlo. È una mancanza significativa perché è esattamente il tipo di organizzazione che i plugin richiederebbero per dare il meglio.

  • La terza è che tutto è locale alla macchina. Le conversazioni, i plugin installati, le configurazioni vivono sul computer dove Cowork è installato. Chi usa lo stesso account Claude su due computer diversi non troverà le chat dell’uno sull’altro. Non c’è sincronizzazione tra dispositivi né, per ora, gestione centralizzata a livello aziendale. Anthropic ha dichiarato di voler aggiungere queste funzionalità, ma al momento non ci sono.

Per quanto riguarda i primi due punti la memoria di cartella, solo brevemente citata ma non spiegata nella documentazione ufficiale, potrebbe essere la soluzione tecnica per introdurre in Cowork sia i progetti che la memoria di progetto.

Resta comunque il punto generale: sono strumenti che assistono il professionista, non lo sostituiscono. Il disclaimer del plugin Legal vale come principio per tutti i domini.

Quello che c’è già

L’aspetto probabilmente più rilevante è che, nonostante le assenze, la barriera all’ingresso si è abbassata. Non serve saper programmare né per usare i plugin né per crearli. Serve sapere cosa si fa nel proprio lavoro e saperlo descrivere in modo strutturato. Per chi si chiede se le AI generative possano integrarsi nei propri flussi operativi, i plugin di Cowork sono un passaggio concreto e allo stesso tempo uno strumento utile.

Potrebbe interessarti

  • Cos’è MCP e come è diventato standard

    MCP è il protocollo aperto Anthropic per le AI. Un percorso in cinque tappe lo segue dalla definizione tecnica alla governance di una fondazione neutrale.

  • AI per studiare

    AI e mondo dello studio, un rapporto complesso, forse anche complicato. Come si stanno muovendo gli attori principali di questo mondo?

  • MCP – la prima libreria

    Proposta di una libreria minima di server MCP: Memory, Reasoner, Filesystem, Data Exploration