Configura il tuo ecosistema di plugin

Questa guida spiega come creare il tuo ecosistema di plugin: una repo di plugin di proprietà della tua organizzazione, distribuita a ogni sessione Devin e a ogni utente CLI tramite un manifest gestito, con plugin obbligatori, facoltativi e vietati come controlli di governance. Questa guida include due repo modello:

plugin-template — un punto di partenza per creare un singolo plugin (o un paio di plugin).
team-marketplace-template — il modello completo dell’ecosistema: un monorepo di plugin più un meta-plugin il cui manifest definisce la tua base e la tua policy.

1. Crea i tuoi plugin

Un plugin è una directory con un file manifest .devin-plugin/plugin.json; tutto il resto è facoltativo:

my-plugin/
├── .devin-plugin/
│   └── plugin.json     # name, version, dependency + policy lists
├── AGENTS.md           # always-on rule
├── rules/              # triggered rules
├── agents/<name>.md   # subagent personalizzati (solo CLI/Desktop al momento); agents/<name>/AGENT.md funziona anche
├── hooks.json          # lifecycle hooks
├── .mcp.json           # MCP servers
└── skills/<name>/SKILL.md   # skills, exposed as /<plugin>:<skill>

Crea un fork di plugin-template per iniziare e consulta il riferimento sui plugin CLI per il formato completo. Mantieni AGENTS.md conciso — consuma contesto in ogni sessione per tutti coloro che usano il plugin.

2. Verifica e testa in locale

Entrambi i template includono un validatore (node scripts/validate-template.mjs) e un flusso di lavoro CI che lo esegue a ogni PR. Per una prova reale, installa da una cartella locale con Devin CLI:

devin plugins install --local ./plugins/my-plugin   # collegato, solo su questa machine: le modifiche vengono applicate alla sessione successiva
devin plugins list

Puoi anche caricare una cartella di plugin o un file .zip nel tuo ambito personale da Customize → Plugins e provarlo in una sessione cloud.

3. Ospitali in un’unica repo

Inserisci tutti i plugin della tua org in un’unica repo come sottocartelle (plugins/<name>/), ciascuno con la propria sorgente git-subdir. La repo può rimanere privata: le sessioni cloud la recuperano tramite la tua integrazione Git, mentre gli utenti della CLI la recuperano con le proprie credenziali git (quindi devono avere accesso anche alla repo). Fai un fork di team-marketplace-template per usare questa struttura e aggiorna gli URL git-subdir del suo meta-plugin in modo che puntino al tuo fork. Nel template il meta-plugin si trova nella radice della repo, quindi la repo stessa è l’unità installabile: richiedere your-org/your-marketplace installa l’intera base.

4. Definisci la base con un meta-plugin

Il pattern meta-plugin trasforma l’intero ecosistema in un’unica unità installabile. È un plugin con contenuti propri minimi o assenti — è il suo manifest a fare il lavoro. Posizionalo nella radice del repo in modo che il repo stesso sia il meta-plugin:

// .devin-plugin/plugin.json (radice del repo)
{
  "name": "team-starter-pack",
  "requiredPlugins": [
    // installato automaticamente per tutti, in modo ricorsivo
    { "source": "git-subdir", "url": "https://github.com/acme/plugins.git", "path": "plugins/engineering-baseline" },
    { "source": "git-subdir", "url": "https://github.com/acme/plugins.git", "path": "plugins/security-guardrails" }
  ],
  "optionalPlugins": [
    // approvato, non installato automaticamente; costituisce anche un'eccezione ai divieti di questo manifest
    { "source": "git-subdir", "url": "https://github.com/acme/plugins.git", "path": "plugins/frontend-standards" }
  ],
  "forbiddenPlugins": [
    "untrusted-vendor/*"
  ]
}

5. Distribuzione da Customize

Un admin installa la repo del marketplace da Customize → Plugins → Add plugin → From repository nell’ambito dell’organizzazione o dell’enterprise — consulta la guida ai Plugins. In questo modo viene aggiunta una entry al managed manifest dell’ambito:

{
  "requiredPlugins": ["acme/plugins"]
}

Richiedere il repo del marketplace installa il suo meta-plugin root, che a sua volta include ricorsivamente l’intera base. Customize indicizza quindi l’ambito ed elenca tutti i plugin inclusi, con le relative skill, MCP, hook e regole. Da questo momento tutti gli utenti nell’ambito ricevono la base automaticamente: nelle sessioni cloud, nella Devin CLI e in Devin Desktop. Scegli l’ambito con attenzione:

Il manifest enterprise raggiunge tutte le organizzazioni dell’enterprise.
Un manifest a livello di organizzazione raggiunge le sessioni cloud di quell’organizzazione e la CLI/Desktop dei membri per i quali è l’organizzazione principale.

Se la base include server MCP che richiedono credenziali, completa la configurazione nella scheda MCP dopo l’indicizzazione. Per i server OAuth con accesso Organization, collega un service account condiviso tra i membri; con accesso Personal, ogni membro collega il proprio account. Se manca il contenuto della base, segui Risolvere i problemi di indicizzazione.

6. Governare

I tre elenchi costituiscono il linguaggio delle policy a tutti i livelli (manifest gestiti, configurazione della repo, manifest dei plugin). Prevale il livello con autorità superiore — enterprise/account su org su repo su utente — e un livello inferiore non può mai tornare a consentire ciò che un livello superiore vieta, né vietare ciò che quest’ultimo richiede. Per limitare un account esclusivamente a un insieme approvato:

{
  "forbiddenPlugins": ["*"],
  "requiredPlugins": [
    "acme/plugins",
    { "source": "git-subdir", "url": "https://github.com/acme/plugins.git", "path": "plugins/engineering-baseline" },
    { "source": "git-subdir", "url": "https://github.com/acme/plugins.git", "path": "plugins/security-guardrails" }
  ],
  "optionalPlugins": [
    { "source": "git-subdir", "url": "https://github.com/acme/plugins.git", "path": "plugins/frontend-standards" }
  ]
}

Le voci obbligatorie/facoltative del manifest stesso sono escluse dal proprio divieto "*"; nessun’altra lo è e nessun livello inferiore può ampliare questa eccezione. L’esenzione copre solo le voci elencate direttamente — le dipendenze transitive di un plugin obbligatorio non sono esenti — quindi, in caso di lockdown, elenca esplicitamente tutto ciò che il meta-plugin include (qui engineering-baseline e security-guardrails). Consulta dipendenze e governance per la semantica completa.

7. Evoluzione

Il merge nel branch predefinito del repo del tuo plugin è il rilascio: le nuove sessioni lo recepiscono automaticamente — vedi come vengono distribuiti gli aggiornamenti.
I team aggiungono plugin tramite PR al repo del marketplace; la CI del template convalida la struttura a ogni PR.
I plugin Claude esistenti si installano così come sono (Devin usa .claude-plugin/plugin.json come fallback), quindi puoi includere plugin della community in optionalPlugins senza doverli incorporare nella repo.

Limitazioni attuali

I plugin vengono caricati nelle sessioni cloud, nel Devin CLI e in Devin Desktop (quando si usa Devin Local); non si applicano però all’agente Cascade classico.
I Subagents (agents/<name>.md o agents/<name>/AGENT.md) vengono caricati solo negli agenti Devin locali (CLI e Devin Desktop), non nelle sessioni cloud.
Gli Hooks operano attualmente al meglio e senza bloccare in caso di errore: un hook che non riesce a caricarsi o a essere eseguito non interrompe la sessione; pertanto, non fare ancora affidamento su di essi per barriere di sicurezza cruciali. Consulta il riferimento agli hook della CLI per la configurazione locale.
La governance non blocca in caso di errore: se non è possibile recuperare un manifest gestito all’avvio della sessione, i plugin di quel livello non vengono installati e i relativi divieti non vengono applicati per quella sessione.
Il contenuto dei plugin proveniente da un repo privato compare in Customize solo per le organizzazioni la cui integrazione Git è in grado di raggiungere il repo; altrimenti viene nascosto fino a quando il repo non viene autorizzato in Settings → Repositories.

Per saperne di più

Guida ai plugin — il lato app web: Customize, ambiti, indicizzazione, MCP
Riferimento sui plugin CLI — formato dei file, creazione, installazioni per utente
Skills — le procedure SKILL.md incluse nei bundle dei plugin

Introduzione

Guide fondamentali

Introduzione a Devin

Lavorare con Devin

Guide sul prodotto

Integrazioni

Admin

Note di rilascio

Configura il tuo ecosistema di plugin

1. Crea i tuoi plugin

2. Verifica e testa in locale

3. Ospitali in un’unica repo

4. Definisci la base con un meta-plugin

5. Distribuzione da Customize

6. Governare

7. Evoluzione

Limitazioni attuali

Per saperne di più

​1. Crea i tuoi plugin

​2. Verifica e testa in locale

​3. Ospitali in un’unica repo

​4. Definisci la base con un meta-plugin

​5. Distribuzione da Customize

​6. Governare

​7. Evoluzione

​Limitazioni attuali

​Per saperne di più

1. Crea i tuoi plugin

2. Verifica e testa in locale

3. Ospitali in un’unica repo

4. Definisci la base con un meta-plugin

5. Distribuzione da Customize

6. Governare

7. Evoluzione

Limitazioni attuali

Per saperne di più