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 che puoi installare da una repo GitHub, un URL git o una cartella locale e riutilizzare in più progetti. Quando installi un plugin, le sue skill diventano disponibili come slash command /<plugin>:<skill> e possono includere automaticamente anche altri plugin da cui dipendono. 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. 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.
Server MCP — un file mcp_config.json nella directory radice del plugin dichiara server MCP ("mcpServers": { "<name>": { … } }) che si avviano con la sessione. Anche il file .mcp.json nella radice dei plugin Claude e il campo mcpServers del manifest vengono presi in considerazione.

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>:…).

{
  "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

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

​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

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