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 raggruppa skills — e facoltativamente regole, hooks, server MCP e subagent — così da poter essere installato e riutilizzato come unità. Consulta il riferimento ai plugin per il formato dei file e per sapere cosa può includere un plugin. 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 web app dei plugin: manifest gestiti, ambiti e caricamenti.

Dove configurarli

Vai a Settings → Resources → Plugins. 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.
Il manifest viene memorizzato testualmente; l’agente verifica la sorgente completa al momento dell’installazione. Consulta il riferimento ai plugin per le forme di sorgente che ogni voce può assumere e la semantica completa di dipendenze e governance.

Aggiungere i propri plugin

A seconda di dove si trova il plugin, aggiungilo in uno di questi modi:

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 → Resources → Plugins) 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.

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 Enterprise admin possono scegliere di installare un plugin nell’ambito enterprise (si applica ovunque), oppure un Org admin può installarlo solo nella propria org.
Questi si trovano al vertice della gerarchia complessiva dei plugin, sopra la configurazione dei plugin a livello di repo e di utente. Consulta ereditarietà e livelli per gli altri livelli e le regole di autorità.

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