Come creare plugin di Claude Code: guida passo passo

Claude Code gestisce la maggior parte delle attività di sviluppo già di default, ma ogni team ha flussi di lavoro specifici che le impostazioni standard non coprono. Potresti voler creare un comando personalizzato che generi i componenti secondo la struttura preferita dalla tua azienda, eseguire il linting automatico prima di ogni commit, o avere accesso rapido alla documentazione di un framework che usi spesso.

I plugin di Claude Code ti permettono di aggiungere queste funzionalità da solo. Puoi installare plugin creati dalla community o sviluppare i tuoi.

Se sei alle prime armi con lo strumento di coding agentico di Anthropic, ti consiglio di iniziare con la Guida a Claude Code o il corso Introduzione ai modelli Claude. Questo tutorial presuppone che tu abbia installato Claude Code e che lo abbia già usato per attività di base.

Alla fine, saprai come:

• Trovare e installare plugin dalla directory di Anthropic e da fonti della community
• Capire i tre tipi di componenti che i plugin possono contenere
• Scegliere il tipo giusto per diversi casi d’uso
• Creare e condividere i tuoi plugin

Per una panoramica delle funzionalità dell’ultimo modello di Anthropic, dai un’occhiata alla nostra guida su Claude Sonnet 4.6

Cosa sono i plugin di Claude Code?

Un plugin è un pacchetto che raggruppa una o più estensioni di Claude Code per semplificare condivisione e installazione. Invece di copiare manualmente i file di configurazione tra macchine o colleghi, puoi racchiudere tutto in un plugin e distribuirlo come un’unica unità.

I plugin possono contenere tre tipi di componenti:

• Skills: Comandi personalizzati che avvii con /skill-name o prompt sensibili al contesto che Claude usa automaticamente quando rilevanti
• Server MCP: Connessioni a servizi esterni e API che danno a Claude accesso a dati altrimenti non disponibili
• Hook: Script shell che vengono eseguiti automaticamente su eventi specifici, ad esempio prima che un file venga modificato o dopo un commit

Un plugin può contenere solo uno di questi elementi, oppure combinarne diversi che lavorano insieme. Un plugin di “deployment” potrebbe includere una skill /deploy per i deployment manuali, un server MCP che controlla lo stato dell’ambiente di staging e un hook che esegue i test prima di qualsiasi comando di deployment.

Il file manifest plugin.json definisce il contenuto del plugin. Specifica quali skills, server MCP e hook installare, insieme a metadati come nome, versione e autore del plugin. Quando installi un plugin, Claude Code legge questo manifest e configura ogni componente nella posizione corretta.

Questo formato di packaging fa sì che tu non debba conoscere la struttura interna dei file delle estensioni di Claude Code. Installi il plugin e tutto finisce dove deve.

Trovare e installare plugin di Claude Code

La maggior parte dei plugin si trova in due luoghi. La directory ufficiale di Anthropic su plugins.claude.ai include plugin creati da Anthropic, contributi verificati della community e popolari estensioni di terze parti. Ogni scheda mostra quali componenti contiene il plugin, le informazioni di compatibilità e le istruzioni di installazione.

La seconda fonte è GitHub. Il repository awesome-claude-code mantiene una lista curata organizzata per categoria, e gli sviluppatori pubblicano i plugin nei propri repository.

Una volta trovato il plugin che vuoi, il comando di installazione dipende da dove si trova:

# From the official directory
claude plugin add @anthropic/deploy-helper
 
# From a GitHub repository
claude plugin add github:username/repo-name
 
# From a local directory (useful during development)
claude plugin add ./my-plugin

Dopo aver installato alcuni plugin, vorrai tenerne traccia. Il comando plugin gestisce elenco, aggiornamento e rimozione:

# List all installed plugins
claude plugin list
 
# Update a specific plugin to the latest version
claude plugin update @anthropic/deploy-helper
 
# Update all plugins
claude plugin update --all
 
# Remove a plugin
claude plugin remove @anthropic/deploy-helper

Una decisione che prenderai durante l’installazione è l’ambito. I plugin possono vivere in due posizioni: lo scope utente installa in ~/.claude/plugins/ e funziona in tutti i tuoi progetti, mentre lo scope progetto installa in .claude/plugins/ all’interno di un repository specifico.

L’impostazione predefinita è lo scope utente. Per installare un plugin solo per il progetto corrente, aggiungi il flag --project:

claude plugin add @anthropic/deploy-helper --project

I plugin con scope di progetto hanno senso quando l’estensione è legata a una specifica codebase. 

Un plugin che conosce il processo di deployment della tua azienda appartiene a quel progetto. Un plugin che formatta il codice secondo le tue preferenze personali invece ha senso a livello utente. Quando un plugin esiste in entrambi gli scope, la versione di progetto ha la precedenza, consentendo ai team di applicare configurazioni specifiche del progetto mentre gli sviluppatori mantengono attivi i propri plugin personali altrove.

Scegliere il tipo giusto di plugin per Claude Code

I tre tipi di componenti servono a scopi diversi e consumano risorse in modo differente. Capire questi compromessi mantiene sano il tuo contesto e ti aiuta a scegliere lo strumento giusto per ogni lavoro.

Skills vs server MCP: il compromesso sui token

I server MCP precaricano ogni definizione di tool nella finestra di contesto all’avvio della sessione. Ogni tool richiede nome, descrizione e schema completo dei parametri, che in genere occupano 100–300 token per tool. Una configurazione con cinque server consuma circa 55.000 token prima ancora che tu scriva un carattere:

• GitHub: 35 tool
•  Slack: 11 tool
• Sentry: 5 tool
• Grafana: 5 tool
• Splunk: 2 tool

Un’analisi ha rilevato configurazioni con 7+ server che consumano oltre 67.000 token, cioè un terzo della finestra di contesto da 200K andato prima ancora di iniziare la conversazione.

Le Skills adottano un approccio diverso tramite divulgazione progressiva. All’avvio della sessione, Claude vede solo il nome di ogni skill e una riga di descrizione dal frontmatter YAML, circa 100 token per skill. 

Le istruzioni complete vengono caricate solo quando Claude determina che la skill è pertinente al task corrente. I file di riferimento vengono caricati solo quando sono specificamente necessari. E gli script non entrano mai nella finestra di contesto: Claude li esegue esternamente e torna solo l’output.

Anthropic ha affrontato questo squilibrio a fine 2025 con Tool Search, una funzionalità che porta il lazy loading ai server MCP. 

Invece di caricare in anticipo ogni definizione di tool, ora Claude Code rileva quando le descrizioni dei tool supererebbero il 10% del contesto disponibile e passa al caricamento on-demand. 

Nei test interni l’uso del contesto è sceso da ~134.000 token a ~5.000 token per librerie di tool di grandi dimensioni. È migliorata anche l’accuratezza di selezione dei tool, con Opus 4 che è passato dal 49% al 74% e Opus 4.5 dal 79,5% all’88,1% nelle valutazioni MCP.

Quindi, quando usare ciascuno?

Le Skills sono ideali quando vuoi che Claude abbia accesso a conoscenze o flussi di lavoro applicabili con giudizio. Una skill che descrive la checklist di code review del tuo team viene caricata quando Claude fa la review, ma è Claude a decidere come applicare ogni punto in base al contesto. 

Le Skills hanno senso anche per operazioni che richiedono script per calcoli pesanti, dato che il codice degli script resta fuori dal contesto.

I server MCP sono ideali quando Claude ha bisogno di dati in tempo reale da servizi esterni come messaggi Slack, PR su GitHub o query su database. Sono anche la scelta giusta quando più agenti AI devono usare gli stessi strumenti, o quando servono funzionalità enterprise come audit log e permessi espliciti.

Molte configurazioni combinano entrambi: le skills forniscono il "come" e il "quando" tramite istruzioni in linguaggio naturale, mentre i server MCP gestiscono le chiamate API vere e proprie.

Skills popolari di Claude Code che vale la pena installare

• Superpowers: Oltre 20 workflow collaudati in produzione per TDD, debugging e pianificazione strutturata
• frontend-design: Istruisce Claude a evitare estetiche generiche e a prendere decisioni di design audaci
• mcp-builder: Guida alla creazione di server MCP per integrare API esterne
•  webapp-testing: Testa applicazioni web locali usando Playwright per la verifica UI
•  skill-creator: Strumento interattivo che ti guida nella creazione di nuove skill

Server MCP popolari che vale la pena collegare

• Context7: Ricerca di documentazione in tempo reale e specifica per versione
• GitHub: Ricerca nei repository, gestione PR, tracciamento issue
• Playwright: Automazione del browser usando gli alberi di accessibilità invece degli screenshot
• Supabase: Query al database con consapevolezza della Row Level Security
• Sentry: Tracciamento errori e monitoraggio delle performance direttamente nell’editor

Puoi anche leggere la nostra guida ai migliori server MCP remoti.

Hook: il livello deterministico

Gli hook stanno completamente al di fuori del dibattito skills vs MCP. Mentre sia le skills sia i server MCP sono rivolti a Claude (è Claude a decidere quando usarli), gli hook sono rivolti al sistema. Scattano su eventi come PreToolUse o PostToolUse, eseguendo script shell prima o dopo che Claude compia azioni specifiche. Claude non ha voce in capitolo sull’esecuzione di un hook.

Questo rende gli Hook la scelta giusta quando qualcosa deve accadere senza eccezioni: linting prima di ogni commit, blocco delle scritture su directory protette, log di ogni comando bash o esecuzione dei test prima di qualsiasi deployment.

Questa sviluppatrice consiglia gli hook “block-at-submit” rispetto ai “block-at-write”. Bloccare Claude a metà attività confonde l’agente e produce risultati peggiori. Il suo team usa un hook PreToolUse che incapsula Bash(git commit) e controlla la presenza di un file temporaneo che esiste solo se i test passano. Niente file, niente commit. L’agente finisce il lavoro, poi la validazione avviene alla fine.

Gli hook non aggiungono overhead di token poiché vengono eseguiti come script shell al di fuori della finestra di contesto.

Hook di Claude utili da configurare

• ESLint/Prettier alla modifica: Formatta automaticamente i file dopo che Claude li scrive
• Gate di test al commit: Blocca i commit a meno che i test non passino
• Percorsi protetti: Impedisci scritture su directory di migrazioni, configurazioni o vendor
• Notifica al completamento: Invia avvisi Slack o desktop quando terminano attività lunghe
• Backup della trascrizione: Salva la cronologia della conversazione prima che avvenga la compattazione

Come creare i tuoi plugin di Claude Code

Quando una skill vive nella tua directory personale .claude/, solo tu puoi usarla. Impacchettarla come plugin ti permette di condividerla con i colleghi o riutilizzarla tra progetti.

Creeremo un plugin chiamato session-logger che aggiunge il comando /session-logger:summarize. Quando viene invocato, Claude rivede la conversazione e aggiunge un riepilogo strutturato a SESSION_LOG.md.

Crea la struttura del plugin

I plugin possono vivere ovunque nel tuo filesystem. Per questo tutorial, ne creeremo uno nella tua home directory:

cd ~
mkdir -p session-logger/.claude-plugin
mkdir -p session-logger/skills/summarize

Questo crea:

~/session-logger/
├── .claude-plugin/
│   └── plugin.json  	# manifest goes here, nowhere else
└── skills/
	└── summarize/   	# folder name becomes the command name
    	└── SKILL.md 	# must be named exactly this

Scrivi il manifest

Crea ~/session-logger/.claude-plugin/plugin.json:

{
  "name": "session-logger",
  "description": "Log session summaries to a markdown file",
  "version": "1.0.0"
}

Il campo name diventa il prefisso dello spazio dei nomi. Tutti i comandi in questo plugin inizieranno con /session-logger:.

Scrivi la skill

Crea ~/session-logger/skills/summarize/SKILL.md:

---
description: Log a summary of the current session to SESSION_LOG.md
disable-model-invocation: true
---
 
When invoked, review the conversation and create a summary with these sections:
 
- **Date/time**: Current timestamp
- **Tasks completed**: What was accomplished
- **Files modified**: List of files created or changed
- **Decisions made**: Architectural or implementation choices
- **Open questions**: Unresolved items for future sessions
 
Append the summary to SESSION_LOG.md in the project root. Create the file if it doesn't exist.

La riga disable-model-invocation: true indica a Claude che solo tu puoi attivare questa skill. Senza questo flag, Claude potrebbe decidere di eseguire il comando autonomamente se ritiene che aiuti la conversazione. Per un logger o uno strumento di deployment, di solito vuoi il controllo manuale.

Test locale

Vai a qualsiasi progetto in cui vuoi usare il plugin, poi avvia Claude Code con il flag --plugin-dir puntato al tuo plugin:

cd ~/your-project
claude --plugin-dir ~/session-logger

Digita /session-logger:summarize per invocare il comando. Nota che i comandi dei plugin non compaiono nei suggerimenti di completamento automatico finché non scrivi il nome completo. Il testo diventa blu quando Claude Code lo riconosce come comando valido.

Dopo aver fatto un po’ di lavoro nella sessione, esegui il comando. Claude rivede la conversazione e aggiunge una voce a SESSION_LOG.md nella directory del progetto corrente.

Condividi con altri

Pubblica il tuo plugin su GitHub. Per distribuirlo oltre il clone manuale, aggiungilo a un marketplace di plugin. La guida al marketplace spiega come crearne uno tuo o come inviare il plugin a quelli esistenti.

Conclusione

I plugin trasformano Claude Code da assistente generico in qualcosa modellato sul tuo flusso di lavoro specifico. Il session logger che abbiamo creato ha richiesto circa cinque minuti e tre file. La maggior parte dei plugin utili non è molto più complessa di così.

Se hai seguito i passaggi, ora hai un plugin funzionante sulla tua macchina. Prova a modificarlo. Cambia il formato del riepilogo, aggiungi nuove sezioni o sostituiscilo con qualcosa di cui il tuo team ha davvero bisogno. La struttura resta la stessa, sia che tu stia costruendo un rapido strumento personale sia qualcosa da distribuire a centinaia di sviluppatori.

Quando puoi, esplora i repository della community. Vedere come gli altri strutturano i loro plugin ti insegna schemi che la documentazione da sola non può. E quando costruisci qualcosa di utile, pubblicalo. L’ecosistema cresce un plugin condiviso alla volta.