Configura il tuo ecosistema di 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.

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_config.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 ./plugins/my-plugin   # collegato: le modifiche vengono applicate alla sessione successiva
devin plugins list

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 Settings → Marketplace

Un amministratore aggiunge una voce al manifest gestito nella pagina Marketplace di Settings — vedi la guida al Marketplace dei plugin:

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

Richiedere la repo del Marketplace installa il suo meta-plugin radice, che include ricorsivamente l’intera base. Tutti quelli inclusi nell’ambito ora ricevono automaticamente la base. Scegli con attenzione l’ambito:

Il manifest enterprise/account viene applicato alle sessioni cloud e agli utenti della CLI che hanno effettuato l’accesso all’account.
Il manifest org viene applicato solo alle sessioni cloud — la CLI non ha alcun contesto org.

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 le regole di 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.
Hooks: le sessioni cloud eseguono gli hook command per ogni evento tranne SessionStart e SessionEnd; gli hook di tipo prompt sono disponibili solo in CLI/in locale.
L’MCP servito dal plugin viene caricato nella sessione, ma non compare ancora nell’interfaccia Settings di MCP.
I manifest a livello di org non sono disponibili per gli utenti della CLI; per l’applicazione nella CLI, usa il manifest enterprise/account.

Per saperne di più

Marketplace dei plugin — il lato app web: manifest, ambiti, caricamenti
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 Settings → Marketplace

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 Settings → Marketplace

​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 Settings → Marketplace

6. Governare

7. Evoluzione

Limitazioni attuali

Per saperne di più