Plugin Claude Code: cosa sono e come usarli

Un plugin Claude Code è una cartella che distribuisce più tipi di estensione contemporaneamente. Dove una skill è un singolo file SKILL.md che insegna a Claude un comportamento, un plugin può raggruppare skill, subagent, hook, comandi slash e persino un server MCP, installando tutto con un singolo comando. È la differenza tra dare a qualcuno una ricetta e dargli una cucina attrezzata.

Anthropic ha aggiunto i plugin a Claude Code alla fine del 2025, risolvendo un problema reale: i team non installavano una skill alla volta, ma assemblavano configurazioni. Una configurazione da "ingegnere backend" potrebbe richiedere una skill di debugging, un subagent di code-review, un hook pre-commit e una connessione MCP al database. Prima dei plugin, ciò significava quattro installazioni separate e quattro punti in cui la configurazione poteva andare fuori sincrono. Un plugin rende tutto questo un'unica operazione.

Noi testiamo e cataloghiamo le skill di Claude su SkillProof, e i plugin sono il livello successivo rispetto a ciò che solitamente recensiamo: un formato di packaging, non un comportamento. Questa guida copre cosa c'è effettivamente all'interno di un plugin, come funziona il sistema di marketplace e la stessa domanda di fiducia che poniamo per le skill fin dall'inizio, ora applicata a qualcosa con una superficie di attacco molto più ampia.

Cosa impacchettano effettivamente i plugin

Quattro tipi di ingredienti possono comparire all'interno di un singolo plugin, e la maggior parte dei plugin reali ne usa più di uno:

• Skill — Istruzioni markdown che vengono caricate quando un task corrisponde, lo stesso formato trattato in cosa sono le skill di Claude.
• Subagent — Istanze Claude separate con il proprio system prompt e window di contesto, utili per delegare un task rumoroso o parallelo.
• Hook — Comandi shell che si attivano automaticamente su eventi come il salvataggio di un file, un commit o il completamento di una chiamata a uno strumento. Un hook di lint-on-save è l'esempio classico.
• Comandi Slash — Comandi personalizzati come /deploy o /standup che eseguono un prompt o uno script predefinito quando un membro del team li digita.
• Server MCP — Una connessione a uno strumento o a una fonte dati esterna, configurata una volta all'interno del plugin invece che manualmente in ogni progetto.

Un plugin non ha bisogno di tutti e cinque. Molti distribuiscono solo un paio di skill, o un singolo hook più il comando che lo attiva. Ciò che lo rende un plugin anziché una raccolta disordinata di file è che si installa come un'unica unità, con un manifest che descrive cosa contiene.

Plugin vs skill: l'analogia con i pacchetti npm

Il modo più pulito per pensarci: una skill è una funzione, un plugin è un pacchetto.

Una singola skill insegna a Claude un comportamento, che si tratti di formattare note di riunione o di revisionare una pagina SEO. Non ha dipendenze né configurazioni oltre al proprio markdown. Questo è intenzionale: una skill scritta per coprire diversi task non correlati tende a scatenarsi in modo inaffidabile su tutti, poiché la sua descrizione non può essere specifica su nessuno di essi.

Un plugin è l'unità di distribuzione attorno a quel comportamento. Nel mondo npm, una funzione non viene distribuita da sola; viene distribuita all'interno di un pacchetto con un package.json, un numero di versione e forse un paio di altre funzioni che appartengono insieme. Un plugin svolge lo stesso ruolo per Claude Code: è la cosa con un nome, una versione, un autore e un manifest, e le skill, gli hook e i comandi al suo interno sono gli "esport".

Questa distinzione è importante per una ragione pratica. Quando qualcosa si rompe, "il trigger della skill è troppo vago" e "l'hook del plugin sta eseguendo il comando shell sbagliato" sono bug diversi con correzioni diverse. Incolpare l'intero plugin per una singola skill al suo interno, o viceversa, fa perdere tempo. Leggi prima il manifest per vedere cosa è stato effettivamente distribuito prima di diagnosticare qualsiasi cosa.

Significa anche che le due unità vengono valutate diversamente. Una skill vive o muore per la qualità del trigger e se il suo output batte quello predefinito di Claude. Un plugin vive o muore per la cooperazione delle sue parti: l'hook si attiva prima o dopo che la skill ha bisogno del suo output, il comando chiama un server MCP effettivamente configurato, l'installazione entra in conflitto con qualcosa che hai già.

Anatomia di un plugin

Ogni plugin necessita di una directory .claude-plugin alla sua radice contenente plugin.json, il manifest. Tutto il resto (skills/, agents/, hooks/, commands/, .mcp.json) si trova accanto ad esso come cartelle semplici che Claude Code cerca per convenzione.

Ecco un plugin piccolo ma completo, annotato:

team-standards/
├── .claude-plugin/
│   └── plugin.json
├── skills/
│   └── code-review/
│       └── SKILL.md
├── hooks/
│   └── hooks.json
└── commands/
    └── deploy.md

// .claude-plugin/plugin.json
{
  "name": "team-standards",
  "version": "1.2.0",
  "description": "Our lint hook, review skill, and deploy command in one install.",
  "author": "platform-team"
}

Il manifest è deliberatamente scarno. Identifica il plugin e la sua versione; non elenca ogni file al suo interno, poiché Claude Code scopre automaticamente skills/, hooks/ e commands/ dai nomi delle loro cartelle.

// hooks/hooks.json
{
  "PreToolUse": [
    {
      "matcher": "Bash",
      "hooks": [{ "type": "command", "command": "./scripts/check-branch.sh" }]
    }
  ]
}

Questo hook si attiva prima di qualsiasi chiamata a strumenti Bash e può bloccarla, il che è il modo in cui un plugin impone qualcosa come "non eseguire mai comandi git distruttivi su main" senza fare affidamento sulla memoria di Claude di controllare.

<!-- commands/deploy.md -->
---
description: Run our deploy checklist against staging
---

Verify the branch is not main, confirm migrations are applied,
then run `./deploy.sh staging`. Report the deploy log summary.

Digitare /deploy esegue esattamente questo, ogni volta, formulato in modo identico per ogni membro del team che installa il plugin. Quella coerenza è l'intera proposta: tre componenti, un numero di versione, un comando di installazione e nessuno con la configurazione locale che diverge da quella degli altri.

Un file separato, marketplace.json, non fa parte del plugin stesso. È l'indice che un repository di marketplace pubblica in modo che Claude Code sappia quali plugin si trovano lì e da dove recuperare ciascuno. Il marketplace.json di un repository può elencare dozzine di plugin non correlati; pensalo come il registro, con plugin.json come pacchetto individuale al suo interno.

Installazione dai marketplace

Ottenere un plugin sulla tua macchina richiede due comandi. Prima, punta Claude Code a un marketplace:

/plugin marketplace add anthropic/plugins

Questo legge il marketplace.json di quel repository e aggiunge ogni plugin che elenca a ciò che puoi sfogliare. Poi installane uno:

/plugin install code-standards@anthropic

La parte @anthropic specifica da quale marketplace scaricare, poiché puoi averne diversi aggiunti contemporaneamente e lo stesso nome di plugin potrebbe teoricamente esistere in più di uno. Claude Code scarica i file del plugin, registra le sue skill e i suoi comandi, e collega eventuali hook o server MCP che dichiara.

Ecco la parte che dovrebbe suonarti familiare se hai letto qualsiasi altra cosa abbiamo scritto: nessuno li revisiona. Aggiungere un marketplace significa fidarsi di chiunque mantenga quel repository, e installare un plugin da esso significa fidarsi di ogni file che il plugin porta, inclusi gli hook che eseguono comandi shell e i server MCP che ottengono accesso alla rete. Questo è esattamente il problema di fiducia che abbiamo documentato per le skill, solo che un plugin ha più parti in movimento, il che significa più posti dove qualcosa di male può nascondersi. Una skill può solo essere testo persuasivo caricato nel contesto. Un plugin può anche essere un hook che si esegue ad ogni commit, indipendentemente dal fatto che tu stia guardando o meno.

La nostra checklist di sicurezza per le skill si applica qui con un'aggiunta. Prima di installare un plugin:

1. Leggi il manifest e ogni file a cui fa riferimento prima di eseguire il comando di installazione, non dopo. Un plugin.json che dichiara di essere un "aiuto per il deploy" che dichiara anche un server MCP puntato a un dominio sconosciuto è un segnale degno di attenzione.
2. Blocca la versione. Installa code-standards@1.2.0, non qualunque cosa latest risolva la prossima settimana. Un plugin che cambia il suo comportamento di hook dopo che ti sei già fidato di esso è peggio di uno che era cattivo fin dal primo giorno, perché non lo cercherai.
3. Controlla specificamente quali hook e comandi vengono distribuiti. Gli hook si eseguono automaticamente, senza che tu digiti nulla, su eventi come chiamate a strumenti e salvataggi di file. Quella è la componente più degna di lettura completa, poiché è quella che agisce senza un prompt da parte tua nel momento.
4. Tratta un server MCP raggruppato in un plugin come qualsiasi altro server MCP: ottiene accesso reale alla rete e spesso credenziali reali. Raggrupparlo all'interno di un plugin non lo rende più sicuro, lo rende solo più facile da installare senza notare che è lì.

Copriamo il modello di minaccia completo, incluso cosa assomiglia effettivamente un hook o una skill malevola in pratica, nella nostra guida alla sicurezza delle skill. Tutto ciò che riguarda il trattamento delle istruzioni di terze parti come una dipendenza che non hai ancora verificato si applica ai plugin, solo con un raggio d'azione più ampio.

Quando impacchettare la configurazione del tuo team come plugin

Il segnale più chiaro che sei pronto per un plugin: hai scritto le stesse istruzioni di configurazione in un README, un pin di Slack e un documento di onboarding, e sono già fuori sincrono in due dei tre posti.

Prendi un caso concreto. Un team di piattaforma vuole che ogni sessione Claude Code degli ingegneri imponga gli stessi standard: nessun commit diretto su main, un passaggio di code-review coerente prima del merge e un deploy con un comando unico allo staging. Raggruppato separatamente, questo è un hook che qualcuno deve ricordarsi di aggiungere a settings.json, una skill che qualcuno deve ricordarsi di installare e un comando di cui qualcuno deve ricordarsi l'esistenza. Raggruppato come plugin team-standards, è una riga:

/plugin install team-standards@our-org

e ogni nuovo assunto ottiene l'hook di protezione del branch, la skill checklist di code review e il comando /deploy in un unico passaggio, versionati insieme in modo che un aggiornamento allo script di deploy e un aggiornamento ai criteri di revisione vengano distribuiti nella stessa release invece di divergere.

Anche il segnale inverso è importante: se la tua configurazione è una singola skill senza hook, comandi o dipendenze MCP, impacchettarla come plugin aggiunge un manifest e un elenco di marketplace senza alcun beneficio. Pubblicarla come skill da sola, come trattiamo in cosa sono le skill di Claude, e ricorrere a un plugin solo quando ci sono più parti in movimento da tenere in sincronia. Se il server MCP è la parte complicata della tua configurazione, le nostre note sulla sua creazione si trovano in MCP Builder, che vale la pena consultare prima di decidere se un plugin necessita del proprio server o se puntare a uno già esistente.

La nostra guida Guida alla configurazione di Claude Code in 30 minuti illustra la costruzione di questo livello passo dopo passo per un individuo; un plugin di team è lo stesso esercizio di stratificazione, solo versionato e condiviso invece che assemblato manualmente su ogni laptop.

L'ecosistema nel 2026, onestamente

I plugin sono giovani, e si vede. Il formato del marketplace si è stabilizzato solo pochi mesi fa, il che significa che la maggior parte dei file marketplace.json in circolazione sono stati scritti contro una bozza iniziale della specifica e non sono stati più toccati da allora. La qualità della documentazione varia enormemente: alcuni repository di plugin hanno un README chiaro con una cronologia delle versioni, altri sono un singolo commit senza alcuna spiegazione di cosa faccia effettivamente l'hook raggruppato.

La frammentazione è il problema più grande. Poiché un plugin può dichiarare le proprie skill invece di fare riferimento a quelle che hai già installato, lo stesso comportamento viene reinventato in una dozzina di plugin diversi con una dozzina di barre di qualità diverse. Abbiamo visto una skill di code-review raggruppata all'interno di tre plugin non correlati, nessuno consapevole dell'esistenza degli altri, ognuno scritto secondo uno standard diverso.

Ciò produce la stessa lotteria di qualità che abbiamo documentato per le skill della community in generale: circa la metà di ciò che testiamo fallisce al primo tentativo, sia da uno script di installazione che presuppone una struttura di directory che l'autore non ha mai verificato su una macchina pulita, sia da un hook che silenziosamente non fa nulla perché è stato scritto contro una versione precedente dell'API degli hook. Un plugin non risolve quel tasso di fallimento. Semplicemente raggruppa più componenti che possono ognuno fallire indipendentemente, e un plugin funziona solo se ogni pezzo al suo interno lo fa.

Nessuna di queste cose significa saltare i plugin. Significa applicare lo stesso scetticismo che applicheresti a qualsiasi dipendenza: controlla chi la mantiene, controlla quando è stata aggiornata l'ultima volta, e non installare qualcosa con tre componenti quando ne hai bisogno solo di uno. Il formato di packaging è veramente utile per mantenere un team in sincronia. Non è un sostituto della lettura di ciò che stai installando.

FAQ

Qual è la differenza tra un plugin Claude Code e una skill?

Una skill è un comportamento in un file markdown. Un plugin è un'unità di distribuzione che può raggruppare diverse skill insieme a subagent, hook, comandi slash e un server MCP, tutti installati insieme con un comando e un numero di versione. Le skill di ogni plugin sono ancora skill sotto; il plugin è solo il packaging attorno ad esse.

Come installo un plugin Claude Code?

Aggiungi prima il marketplace con /plugin marketplace add <repo>, poi installa un plugin specifico da esso con /plugin install <plugin-name>@<marketplace>. Blocca una versione invece di installare ciò che il marketplace punta attualmente come latest, in modo che un aggiornamento non cambi silenziosamente il comportamento che hai già revisionato.

I plugin Claude Code sono sicuri da installare?

Trattali come tratteresti qualsiasi dipendenza di terze parti, e più attentamente di una semplice skill, poiché un plugin può anche distribuire hook che eseguono comandi shell automaticamente e server MCP con accesso reale alla rete. Leggi il manifest e ogni file raggruppato prima di installare, non dopo. La nostra guida alla sicurezza delle skill copre il modello di minaccia sottostante in dettaglio.

Posso inserire il mio server MCP in un plugin?

Sì. Un plugin può dichiarare un .mcp.json che configura un server MCP come parte dell'installazione, in modo che i membri del team ottengano la connessione configurata automaticamente invece di configurarla manualmente in ogni progetto. Se stai costruendo il server stesso piuttosto che solo collegarlo, consulta MCP Builder per il lato di costruzione di questo.

Dove trovo plugin Claude Code da installare?

Anthropic mantiene un marketplace ufficiale, e i marketplace della community sono cresciuti rapidamente da quando il formato è stato lanciato. La qualità varia tanto quanto quella delle skill della community in generale, quindi controlla il manifest, controlla quando è stato aggiornato l'ultima volta, e preferisci i plugin dai maintainer che documentano cosa c'è effettivamente all'interno prima di aggiungere il loro marketplace.