I plugin di Claude Cowork: il default assume un team che non hai

Ho installato i plugin ufficiali il giorno in cui sono usciti e il primo che ho aperto mi ha chiesto quale strumento di ticketing usa il mio team di supporto. Il mio team di supporto sono io. Il plugin non era rotto: era scritto per un'azienda con un reparto.

Questo è il punto che serve capire prima di installarne uno. Un plugin non è una funzione in più: è un pacchetto di procedure che qualcun altro ha scritto per un contesto che potrebbe non essere il tuo. Sono ottimi come punto di partenza e mediocri come punto di arrivo, e il repository ufficiale lo dice esplicitamente.

In questa guida trovi il catalogo com'è oggi, verificato riga per riga sul repository, i due modi per installarli, cosa c'è dentro quando apri la cartella, e come si costruisce il proprio.

Che problema risolvono davvero

Usare Cowork come una chat significa fare una cosa alla volta e riscrivere il contesto ogni sessione. L'agente è potente e cieco: non sa che strumenti usi, non conosce le tue procedure, non ha accesso ai tuoi dati.

Un plugin chiude quel buco su tre livelli.

Le skill sono istruzioni di dominio che Claude carica quando servono. Non sono prompt che incolli: sono file che stanno lì e che l'agente decide di leggere quando riconosce che il compito le riguarda. Il file SKILL.md del plugin marketing dedicato alla revisione di un testo contro le linee guida di brand comincia con una descrizione che elenca i casi d'uso ("quando controlli una bozza prima che esca, quando fai un audit di coerenza di voce"), e quella descrizione è esattamente il criterio con cui l'agente decide se aprire il file.

I connettori MCP danno accesso agli strumenti esterni. Nel plugin marketing il file di configurazione dichiara nove server: Slack, Canva, Figma, HubSpot, Amplitude nelle due versioni globale ed europea, Notion, Ahrefs, SimilarWeb. Sono endpoint HTTP con autenticazione OAuth, non credenziali scritte nel file.

I comandi sono le azioni che invochi con la barra. La cosa interessante, e che ho scoperto solo aprendo le cartelle, è che nei plugin attuali non esiste una directory separata per i comandi: la skill dichiara da sola il proprio nome invocabile, e dentro il corpo del file c'è una sezione che descrive il trigger. Scrivere il comando e scrivere la procedura sono la stessa operazione.

Il risultato pratico è un agente che sa già come lavori. Il modello concettuale è lo stesso delle skill che scrivi a mano, e se non hai mai messo mano a una ho spiegato il formato in una Claude Skill non è un prompt lungo.

Il catalogo, com'è oggi

Il codice sta tutto in chiaro nel repository anthropics/knowledge-work-plugins, licenza aperta, 23.000 stelle al momento in cui scrivo. Ho verificato i numeri interrogando direttamente il manifesto del marketplace, perché la documentazione di lancio è vecchia di mesi e il catalogo è cresciuto parecchio.

Il repository è nato il 23 gennaio 2026 e il primo commit con dentro i plugin porta la data del 29 gennaio. Una seconda ondata è arrivata il 24 febbraio, con il commit che ha aggiunto tra gli altri il plugin per l'ingegneria. Da allora non si è fermato.

Oggi il manifesto elenca 93 voci. Diciassette portano la firma di Anthropic e vivono dentro il repository:

• productivity, gestione di attività, calendario e contesto personale
• enterprise-search, ricerca trasversale su mail, chat, documenti e wiki
• sales, ricerca prospect, preparazione call, pipeline, battlecard
• marketing, contenuti, campagne, voce di brand, report di performance
• customer-support, triage ticket, bozze di risposta, escalation, knowledge base
• product-management, specifiche, roadmap, sintesi di ricerca utente
• engineering, standup, code review, decisioni architetturali, incident
• design, critique, gestione del design system, scrittura UX, accessibilità
• data, SQL, analisi statistica, dashboard, validazione prima di condividere
• finance, scritture contabili, riconciliazioni, bilanci, analisi scostamenti
• legal, revisione contratti, triage NDA, compliance, valutazione del rischio
• human-resources, selezione, onboarding, valutazioni, compensation
• operations, fornitori, documentazione di processo, change management
• small-business, flussi già pronti per la piccola impresa
• bio-research, ricerca preclinica, letteratura scientifica, genomica
• pdf-viewer, lettura di documenti
• cowork-plugin-management, il meta-plugin che serve a costruire gli altri

Cinque sono costruiti da partner ma stanno nello stesso repository: Slack, Apollo, Common Room, Zoom e il plugin sulla voce di brand. Le restanti 71 voci puntano a repository esterni: Tavily, Vanta, Miro, PlanetScale, Sanity, ZoomInfo, Zapier, Intercom, Prisma, Cloudinary e altri.

Vale la pena tenere presente la differenza. Un plugin firmato Anthropic dentro il repository lo leggi tutto prima di installarlo. Uno che punta a un repository esterno è codice di terzi con accesso ai tuoi strumenti, e la fiducia va valutata come valuteresti qualunque dipendenza. Sui rischi concreti dell'ecosistema dei server MCP ho scritto separatamente in 30 CVE in 60 giorni.

Installazione, i due percorsi

Da Cowork, l'interfaccia grafica: apri il catalogo su claude.com/plugins, scegli il plugin, installi. Nessun comando, nessun file da toccare. È il percorso pensato per chi lavora dentro l'app desktop e non ha voglia di aprire un terminale.

Da Claude Code, la riga di comando: prima aggiungi il marketplace, poi installi il singolo plugin.

claude plugin marketplace add anthropics/knowledge-work-plugins
claude plugin install sales@knowledge-work-plugins

La sintassi del secondo comando è sempre nome-plugin@nome-marketplace. Il nome del marketplace è quello dichiarato nel manifesto del repository, non l'indirizzo GitHub.

Una volta installato non devi attivare niente. Le skill si accendono quando il compito le riguarda, i comandi compaiono nella sessione, i connettori chiedono l'autorizzazione la prima volta che servono. Se ti serve il quadro completo di come funziona l'agente desktop attorno a questi pezzi, l'ho messo in Claude Cowork: guida all'agente desktop, e per la versione da terminale in Claude Code: guida completa.

Cosa c'è dentro, quando apri la cartella

Questa è la parte che conta, perché è quella che ti mette in condizione di modificarli. La struttura è la stessa per tutti:

marketing/
├── .claude-plugin/
│   └── plugin.json      # manifesto: nome, versione, descrizione, autore
├── .mcp.json            # server MCP a cui il plugin si collega
├── CONNECTORS.md        # cosa serve autorizzare e cosa succede se manca
├── README.md
└── skills/
    ├── brand-review/
    │   └── SKILL.md
    ├── campaign-plan/
    ├── competitive-brief/
    └── ...

Il manifesto è minimo. Quello del plugin marketing contiene quattro campi: nome, versione (1.2.0 quando l'ho letto), descrizione e autore. Nient'altro.

Il file dei connettori dichiara i server MCP in forma di oggetto: tipo di trasporto, indirizzo, e per quelli che lo richiedono i parametri OAuth. Nessun token nel file.

Accanto c'è un CONNECTORS.md, ed è il file che ti conviene leggere per primo. Serve a spiegare cosa succede quando un connettore non è collegato, e le skill lo citano esplicitamente nel loro testo: la prima riga della procedura di revisione brand rimanda proprio lì per capire quali strumenti sono attivi. È il modo in cui il plugin degrada con grazia invece di fallire.

Le skill sono cartelle, una per procedura, ognuna con dentro un SKILL.md. Il file si apre con un frontmatter che dichiara il nome, la descrizione e un suggerimento sugli argomenti attesi, e prosegue in Markdown normale con la procedura vera: quando si attiva, quali input accetta, i passaggi da seguire, i criteri di valutazione.

Il numero di skill dà la misura della densità. Il plugin marketing ne ha otto: revisione di brand, piano di campagna, brief competitivo, creazione contenuti, bozze, sequenze email, report di performance, audit SEO. Il legale ne ha nove, tra cui il triage degli NDA e la valutazione del rischio. L'ingegneria ne ha dieci, da code review a incident response, da debito tecnico a strategia di test.

Tutto questo è Markdown e JSON. Nessun codice da compilare, nessuna infrastruttura da mantenere, nessun passo di build. È il motivo per cui modificarli è alla portata di chiunque sappia scrivere un documento.

La parte che nessuno ti dice: i default vanno cambiati

Torno al punto di partenza, perché è la cosa più utile che ho da darti.

I plugin ufficiali sono scritti per un contesto aziendale medio, e quel contesto ha caratteristiche precise: un team, un reparto che gestisce gli incident, uno strumento di ticketing, qualcuno reperibile la notte. Se lavori da solo o in tre, buona parte di quelle procedure descrive un mondo che non abiti.

Nel mio caso ho tenuto un profilo scritto di cosa devo sostituire ogni volta che installo un plugin nuovo. La regola che mi sono dato è secca: mai usare i default. Ogni plugin che entra passa da una revisione in cui tolgo i riferimenti a ruoli che non esistono, sostituisco gli strumenti con quelli veri e aggiungo il contesto del cliente o del progetto.

Il repository stesso è d'accordo. La documentazione li definisce punti di partenza generici e indica tre leve per adattarli: cambiare il file dei connettori per collegare i tuoi strumenti, aggiungere contesto aziendale ai file delle skill, modificare i flussi perché corrispondano a come lavorate davvero.

Il test che uso per capire se un plugin sta funzionando: dopo due settimane, riesco a dire quale decisione ha cambiato? Se la risposta è no, l'ho installato perché era disponibile, non perché serviva. Quel plugin va disinstallato, e la disinstallazione è gratis.

Costruire il proprio, in pratica

Se hai una procedura che ripeti e che nessun plugin del catalogo copre, il percorso più corto è partire da una cartella vuota.

Il primo passo è scegliere cosa mettere dentro, e qui il criterio è quello che uso per ogni automazione: una procedura merita di diventare skill quando la ripeti, quando sbagliarla costa, e quando il modo giusto di farla non è ovvio. Se la fai una volta al mese e ogni volta è diversa, un file non ti aiuta.

Il secondo passo è il manifesto. Crea .claude-plugin/plugin.json con nome, versione, descrizione e autore. È il minimo sindacale e basta.

Il terzo passo sono le skill. Una cartella per procedura, dentro un SKILL.md. Il frontmatter va scritto con cura, perché la descrizione è il meccanismo con cui l'agente decide di aprire il file: descrivi i casi d'uso, non il contenuto. "Usa quando controlli una bozza prima che esca" funziona; "gestisce la revisione dei contenuti" no.

Il corpo della skill è la procedura, e vale la stessa disciplina che metteresti in un documento operativo per una persona nuova: cosa la attiva, quali input servono, cosa fare quando un input manca, i passaggi in ordine, come si capisce che è andata bene. La skill di revisione brand che ho letto dedica un intero blocco al caso in cui le linee guida non esistono, e propone una domanda da fare all'utente invece di inventarsele. Quel dettaglio è la differenza tra una procedura e un prompt.

Il quarto passo, se ti serve, è il file dei connettori MCP. Se il plugin lavora solo su file locali puoi saltarlo del tutto: il meta-plugin di Anthropic per la gestione dei plugin non ne ha uno. Se invece devi collegare un servizio, il formato è quello che hai visto sopra, e il funzionamento del protocollo l'ho spiegato in MCP e Claude: guida pratica.

Come scorciatoia esiste anche il plugin cowork-plugin-management, che è fatto apposta per creare e personalizzare gli altri. Installalo e chiedi a Claude di generarti lo scheletro: risparmi la parte meccanica e ti concentri sul contenuto, che è l'unica parte che non può scrivere al posto tuo.

Cosa aspettarsi nelle prime due settimane

La prima settimana serve a scoprire cosa non funziona. I connettori chiedono autorizzazioni, alcune procedure fanno domande che non hanno senso nel tuo contesto, un paio di skill non si attivano mai perché la loro descrizione non corrisponde a come formuli le richieste.

La seconda settimana è quella in cui il valore arriva, e arriva dalle modifiche che hai fatto, non dal pacchetto originale. Il guadagno vero non è "ho installato dei plugin". È che il contesto che riscrivevi ogni volta adesso sta in un file, e quel file lo puoi versionare, condividere e correggere quando la procedura cambia.

Se vuoi il metodo completo per progettare procedure che l'agente esegue davvero, con i template che uso in produzione, sta in Claude Mastery, dieci moduli a 19 euro. Se invece hai un processo aziendale specifico e preferisci che il primo plugin lo costruiamo insieme sul tuo stack, la call di scoping dura trenta minuti e serve esattamente a scegliere da dove partire.