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

​
Cosa sono i plugin?

Un plugin è un insieme di skills — e facoltativamente di regole, hooks e server MCP — riunite in un unico pacchetto, così da poter essere installato e riutilizzato come unità. Mentre una skill si trova in una singola repo, un plugin è una sorgente portabile (una repo GitHub, un git URL, una sottocartella di una repo o un file .zip caricato) che puoi richiedere in tutta la tua org o Enterprise. I plugin gestiti consentono a un amministratore di installare i plugin centralmente dalla web app di Devin, in modo che si applichino a tutti gli utenti dell’org o dell’Enterprise — senza alcuna configurazione per utente. Questo include le sessioni cloud Devin e gli utenti di Devin CLI che hanno effettuato l’accesso all’account (la configurazione a livello di Enterprise/account si applica anche alla CLI — vedi sessioni cloud vs. CLI). Quando un plugin viene installato, le sue skill diventano automaticamente disponibili in Devin come comandi /<plugin>:<skill>. Questa pagina descrive il lato cloud (web app) dei plugin. Per il formato dei file dei plugin e il flusso di installazione per utente della CLI, consulta il Riferimento ai plugin CLI.

​
Dove configurarli

Vai a Settings → Marketplace. La pagina ha due schede:
  • Marketplace — esplora i plugin (il catalogo ufficiale di Devin più quelli aggiunti dalla tua org o dal tuo enterprise) e installali. L’installazione di un plugin lo aggiunge al manifest dell’ambito selezionato come plugin obbligatorio, quindi viene installato per tutti in quell’ambito.
  • Configurazione — modifica il manifest del plugin direttamente come JSON e carica il tuo plugin come cartella o file .zip (oppure creane uno nell’editor).
L’accesso è regolato dalle autorizzazioni:
  • Gli Org admins (con accesso alle Settings dell’organizzazione) gestiscono il manifest della org.
  • Gli Enterprise admins (con accesso alle impostazioni enterprise) gestiscono anche il manifest enterprise condiviso.

​
Il manifest

Il manifest è un unico documento JSON composto da tre elenchi:
  • requiredPlugins — installati per tutti nel relativo ambito (in modo ricorsivo, inclusi eventuali plugin da cui dipendono).
  • optionalPlugins — una allow-list che approva i plugin senza installarli automaticamente; usata per definire eccezioni a un elemento vietato.
  • forbiddenPlugins — una deny-list di identificatori di plugin o pattern glob (ad es. acme/*, oppure "*" per un blocco completo).
Ogni voce in requiredPlugins / optionalPlugins è una sorgente — una stringa in forma abbreviata oppure un oggetto: 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. Il manifest viene memorizzato testualmente; l’agente verifica la sorgente completa al momento dell’installazione.

​
Regole di governance

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.
Oltre a queste regole, i manifest gestiti sono organizzati per livelli — enterprise/account sopra org, che a sua volta è sopra la configurazione dei plugin a livello di repo e di utente. Prevale il livello di autorità più alto: un livello inferiore non può mai vietare un plugin richiesto da un livello superiore, né può mai riabilitarne uno vietato da un livello superiore. Quindi un divieto a livello di org non può bloccare un plugin richiesto a livello enterprise, ma un divieto a livello enterprise prevale su un requisito a livello di org.

​
Aggiungere i propri plugin

Un plugin non è altro che una directory contenente un manifest .devin-plugin/plugin.json e una cartella skills/ con normali skills:
Oltre alle skill, un plugin può includere:
  • Regole — un file AGENTS.md nella radice del plugin viene iniettato come regola always-on in ogni sessione — sia nelle sessioni cloud sia nella CLI. Anche i file Markdown in una cartella rules/ vengono caricati, nel rispetto del loro frontmatter trigger — consulta il Riferimento ai plugin CLI.
  • Hook — un file hooks.json nella radice del plugin registra Hook del ciclo di vita che vengono eseguiti nella sessione. Le sessioni cloud eseguono gli hook command per tutti gli eventi tranne SessionStart e SessionEnd — quindi PreToolUse, PostToolUse, PermissionRequest, UserPromptSubmit, Stop e PostCompaction funzionano tutti; gli hook di tipo prompt sono disponibili solo nella CLI/in locale.
  • server MCP — un file mcp_config.json nella radice del plugin dichiara server MCP ("mcpServers": { "<name>": { … } }) che vengono caricati in ogni sessione in cui il plugin è installato. Non compaiono ancora nell’interfaccia Settings di MCP, ma i loro strumenti sono disponibili per Devin. La configurazione MCP di un plugin può impostare un Client ID OAuth e gli ambiti, ma mai un client secret OAuth — una configurazione del server che ne contiene uno viene rifiutata all’attivazione.
  • subagente personalizzato — profili agents/<name>.md (o agents/<name>/AGENT.md). Attualmente vengono caricati solo negli agenti Devin locali — il Devin CLI e Devin Desktop — non nelle sessioni cloud.
Il plugin è l’unità di installazione: installandolo vengono installate tutte le sue skill (più tutto ciò che è incluso in requiredPlugins) — non puoi installare singole skill da un plugin. Per offrire le skill separatamente, suddividile in plugin distinti. Consulta il Riferimento ai plugin CLI per il formato completo di plugin.json e il flusso di creazione locale. A seconda di dove si trova il plugin, aggiungilo in uno di questi modi: Un repo (o una sottocartella git-subdir) corrisponde a un plugin. Un singolo repo può ospitare molti plugin come sottocartelle, ciascuno referenziato con una propria voce git-subdir.

​
Caricamento di un bundle di plugin

Nella scheda Configurazione, la sezione Plugin caricato consente di caricare un plugin come cartella o file .zip, oppure di crearne uno direttamente nell’Editor. Quando lo salvi, viene aggiunto al manifest come plugin obbligatorio (installandolo per tutti nell’ambito); quando lo elimini, il riferimento viene rimosso. Questa è una buona opzione per un plugin che non vuoi (o non puoi) ospitare in una repo Git.

​
Utilizzare un repo privato per le skills

Punta il manifest direttamente al repo privato: in genere non è necessario includerlo nel tuo snapshot dell’ambiente. Qualsiasi repo privato che Devin può già raggiungere tramite la tua integrazione Git viene installato automaticamente. Usa il formato git URL oppure git-subdir per installare un plugin da una sottocartella di un repo condiviso. (Gli utenti CLI che usano lo stesso manifest lo recuperano con le proprie credenziali Git locali, quindi avranno bisogno anche dell’accesso al repo.) Se il repo non è raggiungibile tramite la tua integrazione Git, caricalo come bundle (sopra) oppure clonalo durante la configurazione dell’ambiente e fai riferimento a un percorso locale.

​
Come vengono distribuiti gli aggiornamenti

  • Le modifiche al manifest (Settings → Marketplace) si applicano alla sessione successiva.
  • Le modifiche al plugin — quando viene eseguito un merge nel branch seguito da un plugin, questo raggiunge automaticamente le nuove sessioni nel giro di poche ore. Blocca il plugin su un commit SHA per gestire tu stesso gli aggiornamenti; nella CLI, devin plugins update aggiorna immediatamente.
  • Le sessioni già in esecuzione mantengono ciò che hanno caricato all’avvio: gli aggiornamenti non modificano mai una sessione mentre è in corso.

​
Compatibilità

Anche i plugin di Claude funzionano: se non è presente .devin-plugin/plugin.json, Devin ripiega su .claude-plugin/plugin.json. Quando sono presenti entrambi i manifest, prevale quello di Devin.

​
Ambito ed ereditarietà

I manifest gestiti possono esistere su un massimo di due livelli:
  • Gli account standalone hanno un unico manifest di account che si applica a tutti.
  • Gli account Enterprise hanno un manifest enterprise condiviso che viene ereditato da ogni org figlia, più un manifest per-org posto a un livello inferiore. La vista Marketplace mostra entrambi, e gli amministratori enterprise possono scegliere di installare un plugin nell’ambito enterprise (si applica ovunque), oppure un amministratore di org può installarlo solo nella propria org.
Questi si trovano al vertice della gerarchia complessiva dei plugin, sopra qualsiasi configurazione dei plugin a livello di repo o di utente:
  1. Manifest Enterprise / account (questa pagina)
  2. Manifest Org (questa pagina)
  3. Configurazione del plugin a livello di repo (il .devin/config.json di una repo)
  4. Plugin a livello di utente — le installazioni CLI personali di un utente, che si applicano solo al suo agente Devin locale e non vengono mai caricati nelle sessioni cloud
Prevale il livello di autorità superiore: un livello inferiore non può mai consentire un plugin che un livello superiore vieta, né vietarne uno che un livello superiore richiede (vedi regole di governance).

​
Sessioni cloud vs. CLI

Sia le sessioni cloud di Devin sia il Devin CLI applicano il manifest enterprise/account: i plugin richiesti vengono installati e i divieti vengono applicati anche agli utenti di Devin CLI che hanno effettuato l’accesso all’account. Il manifest org si applica solo alle sessioni cloud. Devin CLI si autentica a livello di account e non ha un contesto org, quindi i requisiti e i divieti a livello di org non si applicano agli utenti di Devin CLI. Inserisci nel manifest enterprise/account tutto ciò che deve essere applicato in Devin CLI (o a livello di account) e usa il manifest org per le aggiunte specifiche dell’org nelle sessioni cloud.

​
Scopri di più

  • Skills — le procedure SKILL.md incluse nei plugin
  • Riferimento ai plugin CLI — formato dei file dei plugin, creazione e installazione per utente
  • Playbooks — modelli di prompt riutilizzabili allegati alle sessioni