Plugin

I plugin sono in beta chiusa. Per richiedere l’accesso, contatta support@cognition.ai. Il comportamento e la configurazione potrebbero cambiare nelle release future.

Un plugin è un pacchetto di skill e regole, hook, server MCP o subagenti personalizzati opzionali che puoi installare da una repo GitHub, un URL git, una sottocartella di una repo o una cartella locale. I plugin funzionano nelle sessioni cloud di Devin, nella Devin CLI e in Devin Desktop, nel rispetto delle limitazioni specifiche di ciascuna funzionalità descritte di seguito. Quando installi un plugin, le sue skill diventano disponibili come slash command /<plugin>:<skill>. Il plugin è l’unità di installazione. L’installazione di un plugin installa tutte le sue skill e i relativi requiredPlugins; non puoi installare singole skill da un plugin. Per offrire le skill separatamente, suddividile in plugin distinti. Un plugin è semplicemente una sorgente che contiene:

my-plugin/
├── .devin-plugin/
│   └── plugin.json     # Il manifest del plugin
├── AGENTS.md           # Regola sempre attiva opzionale
├── rules/              # Regole attivate opzionali
├── agents/
│   └── reviewer.md     # Subagent personalizzato opzionale (reviewer/AGENT.md funziona anche)
├── hooks.json          # Hook del ciclo di vita opzionali
├── mcp_config.json     # Server MCP opzionali
└── skills/
    └── review/
        └── SKILL.md    # Una skill ordinaria

La directory skills/ contiene skill standard: i plugin non introducono alcun nuovo formato di skill. Vedi Creazione di skill per il formato SKILL.md. Una repo (o una sottocartella git-subdir) corrisponde a un plugin. Una singola repo può ospitare molti plugin come sottocartelle, ciascuno referenziato con la propria sorgente git-subdir. Oltre alle skill, un plugin può includere:

Regole — un file AGENTS.md nella directory radice del plugin viene iniettato come regola sempre attiva in ogni sessione, insieme alle regole del tuo progetto. Anche i file Markdown in una cartella rules/ vengono caricati, con lo stesso frontmatter trigger e gli stessi tipi di attivazione delle regole di Windsurf.
Subagenti personalizzati — profili agents/<name>.md o agents/<name>/AGENT.md (lo stesso formato dei subagenti personalizzati dei subagent di progetto), disponibili come <plugin>:<name>. I subagent dei plugin attualmente vengono caricati solo negli agenti Devin locali — la CLI e Devin Desktop — non nelle sessioni cloud Devin.
Hook — un file hooks.json nella directory radice del plugin registra Hook del ciclo di vita eseguiti in ogni sessione in cui il plugin è installato. Nelle sessioni cloud, gli hook command vengono eseguiti sulla macchina della sessione e si attivano solo quando tale macchina è in funzione. Supportano ogni evento tranne SessionStart e SessionEnd — inclusi PreToolUse, PostToolUse, PermissionRequest, UserPromptSubmit, Stop e PostCompaction; gli hook di tipo prompt sono disponibili solo nella CLI/in locale.
Server MCP — un file mcp_config.json nella directory radice del plugin dichiara server MCP ("mcpServers": { "<name>": { … } }) che si avviano con la sessione. I server MCP dei plugin non vengono ancora visualizzati nell’interfaccia Settings MCP, ma i relativi strumenti sono disponibili per Devin. Una configurazione MCP di un plugin può impostare un ID client OAuth e ambiti, ma mai un client secret: una configurazione del server che ne contiene uno viene rifiutata all’attivazione. Anche il file .mcp.json nella radice dei plugin Claude e il campo mcpServers del manifest vengono presi in considerazione.

Formati compatibili

Il layout sopra riportato è il formato di plugin proprietario di Devin. Devin carica anche plugin pacchettizzati secondo altri due layout, con la seguente precedenza dei manifest: .devin-plugin/plugin.json > .claude-plugin/plugin.json > plugin.json nella radice:

Plugin Claude — se .devin-plugin/plugin.json non è presente, Devin usa .claude-plugin/plugin.json. Vengono rispettati il file .mcp.json nella radice dei plugin Claude e il campo mcpServers del manifest; ${CLAUDE_PLUGIN_ROOT} nelle configurazioni dei server viene espanso nella radice del plugin.
Plugin Agent — vengono caricati anche i plugin pacchettizzati secondo la spec Agent Plugins 1.0.0 (un manifest plugin.json nella radice del plugin, server MCP in un file mcp.json nella radice, skills in skills/). Per questi plugin, il file mcp.json nella radice viene letto come sorgente MCP convenzionale (dopo .mcp.json, che ha la precedenza in caso di conflitto tra nomi di server) — i plugin legacy con layout Devin/Claude non lo leggono mai, a meno che il relativo manifest non lo dichiari esplicitamente. Le voci MCP possono dichiarare il transport tramite il campo type della spec (stdio, streamable-http o sse) anziché transport; ${PLUGIN_ROOT} nelle configurazioni dei server viene espanso nella radice del plugin, come ${CLAUDE_PLUGIN_ROOT}. Viene emesso un avviso per una versione $schema non riconosciuta, ma il plugin viene comunque caricato al meglio. I server MCP dei Plugin Agent adottano anche le convenzioni di runtime della spec (si applicano solo ai plugin il cui manifest è il file plugin.json nella radice; i layout Devin e Claude si comportano esattamente come prima):
- ${PLUGIN_DATA} in args, nei valori di env e in cwd viene espanso in una directory dati persistente e scrivibile per ciascun plugin. La directory è associata all’ identità del plugin, non alla versione, quindi il suo contenuto viene mantenuto dopo gli aggiornamenti del plugin e viene eliminata quando il plugin viene disinstallato.
- I processi dei server stdio ricevono le variabili d’ambiente PLUGIN_ROOT e PLUGIN_DATA oltre a qualsiasi valore di env impostato dalla configurazione.
- Un server può impostare cwd (relativo alla radice del plugin); per impostazione predefinita corrisponde alla radice del plugin. Un command con prefisso ./ viene risolto rispetto alla radice del plugin, in modo che i plugin possano includere i propri eseguibili. Entrambi vengono convalidati per garantire che rimangano all’interno della radice del plugin o della directory dati.

Installare un plugin

La sorgente di un plugin può essere un owner/repo GitHub, un URL git o un percorso locale:

# Da GitHub
devin plugins install acme/review-tools

# Da qualsiasi host git
devin plugins install https://gitlab.com/acme/review-tools.git

# Da una cartella locale (ideale per la creazione di plugin)
devin plugins install ./my-plugin

Prima dell’installazione, Devin mostra cosa aggiunge il plugin — le skills che mette a disposizione, gli eventuali plugin richiesti che verranno installati automaticamente e qualsiasi policy che introduce (ad esempio, se vieta altri plugin). Usa -y / --yes per saltare la richiesta di conferma. I plugin vengono installati a livello di utente e sono disponibili in tutti i tuoi progetti.

Gestire i plugin

# Elenca i plugin installati, le loro versioni e se qualcuno è bloccato dalla policy
devin plugins list

# Mostra le skill di un plugin e i relativi elenchi required/optional/forbidden
devin plugins info review-tools

# Esegue nuovamente il fetch di un plugin (o di tutti i plugin) all'ultima versione
devin plugins update review-tools
devin plugins update

# Rimuove un plugin (i plugin required installati automaticamente vengono mantenuti)
devin plugins remove review-tools

I plugin locali sono collegati direttamente alla cartella sorgente, quindi le modifiche sono immediate: devin plugins install ./my-plugin → modifica skills/<name>/SKILL.md → le modifiche si applicano alla sessione successiva, senza dover eseguire update.

Il manifest

.devin-plugin/plugin.json descrive il plugin. Solo name è obbligatorio e deve essere univoco tra i plugin installati (corrisponde allo spazio dei nomi /<name>:…). I nomi sono composti da caratteri alfanumerici minuscoli con singoli separatori - o . (ad es. review-tools, acme.tools).

{
  "name": "review-tools",
  "version": "1.0.0",
  "description": "Code-review skills for our team",
  "requiredPlugins": [
    "acme/secure-base",
    { "source": "github", "repo": "acme/audit-logging" }
  ],
  "optionalPlugins": [
    "acme/deploy-tools",
    { "source": "url", "url": "https://gitlab.com/acme/extra.git" }
  ],
  "forbiddenPlugins": ["sketchy-org/bad-plugin", "acme/*", "*"]
}

Campi di metadati supportati: name, version, description, author ({ name, email }), homepage, repository, license e keywords. Altri due campi facoltativi controllano da dove vengono caricati gli asset: skills — un percorso o un array di percorsi a directory di skill, che sostituisce il valore predefinito skills/ — e mcpServers — percorsi di file di dichiarazione MCP o una mappa inline di server, letti in aggiunta alle conventions radice. Una voce di dipendenza è una sorgente — una stringa in forma abbreviata oppure un oggetto:

Forma	Significato
`"owner/repo"`	repository GitHub
`"https://…"`, `"git@…"`, `"ssh://…"`	qualsiasi URL git
`{ "source": "github", "repo": "owner/repo" }`	GitHub, formato oggetto
`{ "source": "url", "url": "https://gitlab.com/team/plugin.git" }`	URL git, formato oggetto
`{ "source": "git-subdir", "url": "…", "path": "sub/dir" }`	un plugin che si trova in una sottocartella di una repo condivisa

Tutte le forme GitHub per la stessa repo (owner/repo, l’URL HTTPS, l’URL .git, il formato SSH) si riferiscono alla stessa identità del plugin.

Dipendenze e governance

Un plugin può dichiarare tre elenchi, consentendo a un singolo plugin di fungere da raccolta curata e sottoposta a governance di altri plugin.

`requiredPlugins`

Installati automaticamente (in modo ricorsivo) quando viene installato il plugin. Se un plugin richiesto è bloccato da una policy, l’intera installazione fallisce — non è prevista un’installazione parziale.

`optionalPlugins`

Un’allow-list di plugin che questo plugin autorizza. Non vengono installati automaticamente; l’elenco serve solo come eccezione a una voce vietata (vedi sotto).

`forbiddenPlugins`

Una deny-list di identità di plugin e pattern glob. Le voci di forbiddenPlugins vengono confrontate con le identità dei plugin:

Un’identità esatta, scritta come owner/repo o come URL Git. Tutte le forme GitHub della stessa repo (owner/repo, l’URL HTTPS, l’URL .git, la forma SSH) si riferiscono alla stessa identità.
Un pattern glob — qualsiasi voce che contenga *. * corrisponde a qualsiasi sequenza di caratteri, incluso /: acme/* corrisponde a tutte le repo GitHub di acme, */secrets corrisponde a una repo chiamata secrets con qualsiasi owner e https://gitlab.com/acme/* corrisponde a qualsiasi repo in quel percorso.
Il solo "*", che corrisponde a tutto il resto (un blocco totale).

Le liste si combinano secondo il principio deny-wins:

Prevale deny. Un plugin è bloccato se un qualsiasi manifest attivo o plugin installato lo vieta. Se nulla vieta nulla, non viene bloccato nulla.
Auto-override. I requiredPlugins e optionalPlugins di un manifest (o di un plugin) — e, nel caso di un plugin, il plugin stesso — sono esenti dalla propria lista di elementi vietati, quindi "forbiddenPlugins": ["*"] più "optionalPlugins": ["acme/approved"] significa “consenti solo ciò che questo manifest elenca; vieta tutto il resto”. L’eccezione copre solo quelle voci dirette, non le dipendenze transitive di un plugin richiesto: in caso di blocco totale, elencale esplicitamente.
Nessuna nuova autorizzazione tra ambiti diversi. La allow-list di un manifest o plugin non può riabilitare ciò che un altro vieta. Un blocco totale con "forbiddenPlugins": ["*"] non può essere aggirato da un ambito inferiore.

L’applicazione avviene in due momenti:

Al momento dell’installazione — l’installazione di un plugin bloccato (o di uno i cui plugin richiesti non possono essere soddisfatti, o il cui nome entra in conflitto con un plugin installato) viene rifiutata.
Al momento del caricamento — un plugin bloccato dopo essere già stato installato resta sul disco, ma le sue skills vengono saltate all’avvio della sessione con un avviso che indica chi lo vieta.

Un’identità vietata può anche essere un percorso locale (per plugin installati da una cartella locale), oltre alle forme owner/repo e URL git sopra indicate.

Ereditarietà e livelli

I plugin non vengono dichiarati in un unico punto. Oltre alle installazioni che effettui tu, i plugin possono essere richiesti, raccomandati o vietati dalla tua repo e dall’admin della tua organizzazione. Ogni sorgente è un livello e i livelli sono ordinati per autorità, dalla più alta alla più bassa:

Enterprise — il manifest gestito a livello di account, configurato da un admin.
Org — un manifest gestito a livello di org, posto al di sotto del relativo account (un’org può aggiungere a quanto dichiarato dal proprio account, ma non può contraddirlo). Questo vale solo per le sessioni cloud Devin: la CLI si autentica a livello di account e non ha alcun contesto di org, quindi i plugin richiesti e vietati a livello di org non si applicano agli utenti della CLI. Inserisci nel manifest enterprise/account tutto ciò che deve essere imposto nella CLI.
Repo — i requiredPlugins / optionalPlugins / forbiddenPlugins nel file .devin/config.json di un checkout, individuati risalendo dalla tua directory di lavoro.
Utente — i plugin che installi tu stesso con devin plugins install.

Ogni livello dichiara gli stessi tre elenchi e, all’interno di un livello, si combinano secondo le stesse regole «deny-wins» e «self-override» di un singolo manifest. La regola aggiuntiva introdotta dai livelli è una sola: prevale l’autorità superiore.

Prevale l’autorità superiore

Un livello inferiore non può mai riautorizzare ciò che un livello superiore vieta.
Un livello inferiore non può mai vietare ciò che un livello superiore richiede: il divieto viene ignorato e il plugin viene comunque caricato.

Quindi un amministratore può imporre un plugin a cui nessun repo o utente può sottrarsi e vietare un plugin che nessun livello inferiore può ripristinare.

Una denylist viene sovrascritta solo al proprio livello

Poiché le allow-list non si estendono tra livelli diversi, l’unico modo per creare un’eccezione a una denylist è farlo allo stesso livello in cui è stata dichiarata. Il forbiddenPlugins di un livello viene sovrascritto solo dagli optionalPlugins (o requiredPlugins) dello stesso manifest, mai da una lista di un livello inferiore. Per esempio, un manifest gestito a livello Enterprise può limitare l’account a un singolo plugin approvato:

// Manifest gestito a livello enterprise
{
  "forbiddenPlugins": ["*"],
  "optionalPlugins": ["acme/approved"]
}

Questo significa “nell’intero account, consenti solo acme/approved e vieta qualsiasi altro plugin.” Nessuna org, repo o utente può ampliare questa lista di elementi consentiti — né installando un plugin, né aggiungendolo a optionalPlugins a un livello inferiore. L’eccezione copre inoltre solo le voci che questo manifest elenca direttamente; le dipendenze transitive di un plugin obbligatorio non sono esenti, quindi elencale esplicitamente in caso di lockdown.

Conflitti e dipendenze

Un requisito e un divieto per lo stesso plugin allo stesso livello, ma da manifest diversi (per esempio due plugin a livello di utente installati separatamente), si risolvono a favore del divieto: un’allow-list esenta solo le voci del proprio manifest, quindi non può “salvare” un plugin che un altro manifest vieta. (All’interno di un singolo manifest, i propri elementi obbligatori/opzionali restano esenti dai propri divieti, come sopra.)
Un plugin bloccato dalla governance va in soft-fail: all’inizio della sessione le sue skill vengono saltate con un avviso che indica chi ha imposto il divieto, invece di interrompere la sessione.
Il fatto di essere una dipendenza non conferisce alcuna esenzione. Un plugin incluso solo come dipendenza transitiva è comunque soggetto a ogni divieto applicabile e eredita il livello di autorità più alto di qualsiasi plugin che lo richieda.

Per iniziare

Integrazioni dell'Editor

Estensibilità

Enterprise

Riferimento

Changelog

Formati compatibili

Installare un plugin

Gestire i plugin

Il manifest

Dipendenze e governance

`requiredPlugins`

`optionalPlugins`

`forbiddenPlugins`

Ereditarietà e livelli

Prevale l’autorità superiore

Una denylist viene sovrascritta solo al proprio livello

Conflitti e dipendenze

​Formati compatibili

​Installare un plugin

​Gestire i plugin

​Il manifest

​Dipendenze e governance

​requiredPlugins

​optionalPlugins

​forbiddenPlugins

​Ereditarietà e livelli

​Prevale l’autorità superiore

​Una denylist viene sovrascritta solo al proprio livello

​Conflitti e dipendenze

Formati compatibili

Installare un plugin

Gestire i plugin

Il manifest

Dipendenze e governance

`requiredPlugins`

`optionalPlugins`

`forbiddenPlugins`

Ereditarietà e livelli

Prevale l’autorità superiore

Una denylist viene sovrascritta solo al proprio livello

Conflitti e dipendenze