Configure seu ecossistema de plugins

Os plugins estão em beta fechado. Para solicitar acesso, entre em contato com support@cognition.ai. O comportamento e a configuração podem mudar em versões futuras.

Este guia mostra como montar seu próprio ecossistema de plugins: um repo de plugins de propriedade da sua organização, distribuído a todas as sessões do Devin e aos usuários da CLI por meio de um manifest gerenciado, com plugins obrigatórios, opcionais e proibidos como controles de governança. Dois repos de template acompanham este guia:

plugin-template — um ponto de partida para criar um único plugin (ou alguns deles).
team-marketplace-template — o padrão completo do ecossistema: um monorepo de plugins mais um meta-plugin cujo manifest define sua base e política.

1. Crie seus plugins

Um plugin é um diretório com um arquivo de manifest .devin-plugin/plugin.json; todo o restante é opcional:

my-plugin/
├── .devin-plugin/
│   └── plugin.json     # name, version, dependency + policy lists
├── AGENTS.md           # always-on rule
├── rules/              # triggered rules
├── agents/<name>.md   # subagentes personalizados (somente CLI/Desktop por enquanto); agents/<name>/AGENT.md também funciona
├── hooks.json          # lifecycle hooks
├── mcp_config.json     # MCP servers
└── skills/<name>/SKILL.md   # skills, exposed as /<plugin>:<skill>

Faça um fork de plugin-template para começar e consulte a referência de plugins da CLI para conhecer o formato completo. Mantenha AGENTS.md curto — ele consome contexto em todas as sessões de quem tiver o plugin.

2. Validar e testar localmente

Ambos os templates incluem um validador (node scripts/validate-template.mjs) e um workflow de CI que o executa em cada PR. Para um teste em tempo real, instale a partir de uma pasta local com a Devin CLI:

devin plugins install ./plugins/my-plugin   # vinculado: as edições são aplicadas na próxima sessão
devin plugins list

3. Hospede-os em um único repo

Coloque todos os plugins da sua organização em um único repo, como subpastas (plugins/<name>/), cada um referenciado com sua própria origem git-subdir. O repo pode continuar privado: as sessões em nuvem o buscam por meio da sua integração com o Git, e os usuários da CLI o buscam com suas próprias credenciais do git (então também precisam de acesso ao repo). Faça um fork de team-marketplace-template para usar esse layout — e atualize as URLs git-subdir do meta-plugin para apontarem para o seu fork. No template, o meta-plugin fica na raiz do repo, então o próprio repo é a unidade instalável: exigir your-org/your-marketplace instala toda a base.

4. Defina sua base com um meta-plugin

O padrão de meta-plugin transforma todo o seu ecossistema em uma única unidade instalável. É um plugin com pouco ou nenhum conteúdo próprio — o trabalho fica por conta do seu manifest. Coloque-o na raiz do repo para que o próprio repo seja o meta-plugin:

// .devin-plugin/plugin.json (raiz do repo)
{
  "name": "team-starter-pack",
  "requiredPlugins": [
    // instalado automaticamente para todos, recursivamente
    { "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": [
    // aprovado, não instalado automaticamente; também uma exceção aos itens proibidos deste manifest
    { "source": "git-subdir", "url": "https://github.com/acme/plugins.git", "path": "plugins/frontend-standards" }
  ],
  "forbiddenPlugins": [
    "untrusted-vendor/*"
  ]
}

5. Distribua em Configurações → Marketplace

Um administrador adiciona uma entrada ao manifest gerenciado na página Marketplace em Configurações — consulte o guia do marketplace de plugins:

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

Exigir o repo do marketplace instala o meta-plugin raiz dele, que puxa recursivamente toda a base. Agora, todos dentro do escopo passam a receber a base automaticamente. Escolha o escopo com critério:

O manifest enterprise/account se aplica a sessões em nuvem e a usuários da CLI com login na conta.
O manifest org se aplica apenas a sessões em nuvem — a CLI não tem contexto de org.

6. Governança

As três listas formam a linguagem de políticas em todos os níveis (manifests gerenciados, configuração do repo, manifests de plugin). Prevalece o nível de maior autoridade — Enterprise/conta acima de org, acima de repo, acima de usuário — e um nível inferior nunca pode voltar a permitir o que um nível superior proíbe, nem proibir o que ele exige. Para restringir uma conta a apenas um conjunto aprovado:

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

As próprias entradas required/optional do manifest ficam isentas do próprio forbid "*"; mais nada fica, e nenhum nível inferior pode ampliar essa exceção. A isenção cobre apenas entradas listadas diretamente — as dependências transitivas de um plugin required não ficam isentas — portanto, em um lockdown, liste explicitamente tudo o que o meta-plugin inclui (aqui engineering-baseline e security-guardrails). Consulte as regras de governança para ver a semântica completa.

7. Evolua

Fazer merge na branch padrão do repo do seu plugin é a própria release: novas sessões incorporam isso automaticamente — veja como as atualizações são implementadas.
Teams adicionam plugins por PR ao repo do marketplace; a CI do template valida a estrutura em cada PR.
Plugins existentes do Claude são instalados sem modificações (o Devin usa .claude-plugin/plugin.json como fallback), então você pode recomendar plugins da comunidade em optionalPlugins sem incorporá-los ao repositório.

Limitações atuais

Os plugins são carregados em sessões em nuvem, no Devin CLI e no Devin Desktop (ao usar Devin Local); eles não se aplicam ao agente Cascade clássico.
Subagentes (agents/<name>.md or agents/<name>/AGENT.md) são carregados apenas em agentes locais do Devin (CLI e Devin Desktop), não em sessões em nuvem.
Hooks: sessões em nuvem executam hooks de command para cada evento, exceto SessionStart e SessionEnd; hooks do tipo prompt são exclusivos da CLI/ambiente local.
MCP disponibilizado por plugin é carregado na sessão, mas ainda não aparece na UI de configurações do MCP.
Manifests em nível de org não chegam aos usuários da CLI; use o manifest de enterprise/conta para impor isso na CLI.

Saiba mais

Marketplace de plugins — a parte do app web: manifests, escopos, importações
Referência de plugins da CLI — formato de arquivo, criação e instalações por usuário
Skills — os procedimentos SKILL.md que os pacotes de plugins incluem

Introdução

Diretrizes fundamentais

Integração do Devin

Trabalhando com o Devin

Guias do produto

Integrações

Admin

Notas de versão

Configure seu ecossistema de plugins

1. Crie seus plugins

2. Validar e testar localmente

3. Hospede-os em um único repo

4. Defina sua base com um meta-plugin

5. Distribua em Configurações → Marketplace

6. Governança

7. Evolua

Limitações atuais

Saiba mais

​1. Crie seus plugins

​2. Validar e testar localmente

​3. Hospede-os em um único repo

​4. Defina sua base com um meta-plugin

​5. Distribua em Configurações → Marketplace

​6. Governança

​7. Evolua

​Limitações atuais

​Saiba mais

1. Crie seus plugins

2. Validar e testar localmente

3. Hospede-os em um único repo

4. Defina sua base com um meta-plugin

5. Distribua em Configurações → Marketplace

6. Governança

7. Evolua

Limitações atuais

Saiba mais