Skip to main content
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:
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:
Você também pode importar uma pasta de plugin ou um .zip para o seu escopo pessoal em Customize → Plugins e testá-lo em uma sessão em nuvem.

​
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:

​
5. Distribuir a partir do Customize

Um admin instala o repo do marketplace em Customize → Plugins → Add plugin → From repository no scope da organização ou do enterprise — consulte o guia de Plugins. Isso adiciona uma entry ao manifest gerenciado do scope:
Exigir o repo do marketplace instala seu meta-plugin root, que puxa toda a base recursivamente. Em seguida, o Customize indexa o scope e lista todos os plugins que ele trouxe, com suas skills, MCPs, hooks e rules. Todos dentro do scope passam a receber a base automaticamente — em sessão em nuvem, no Devin CLI e no Devin Desktop. Escolha o scope com cuidado:
  • O manifest da enterprise alcança todas as organizações da enterprise.
  • Um manifest de organização alcança as sessão em nuvem daquela organização e o CLI/Desktop dos membros que a têm como organização primária.
Se a base incluir MCP servers que precisam de credenciais, conclua a configuração na aba MCPs após a indexação. Para servers OAuth com acesso de Organization, conecte um service account para os membros compartilharem; com acesso Personal, cada membro conecta a própria conta. Se o conteúdo da base não aparecer, siga Resolver problemas de indexação.

​
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:
As próprias entradas obrigatório/opcional 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 obrigatório 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 dependências e 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.
  • Atualmente, os Hooks funcionam com melhor esforço e falha aberta — um hook que não consegue carregar ou executar não interrompe a sessão — portanto, ainda não dependa deles para guardrails cruciais. Consulte a referência de hooks da CLI para configuração local.
  • A governança tem falha aberta: se um manifest gerenciado não puder ser obtido no início da sessão, os plugins daquele nível não são instalados e seus forbids não são aplicados naquela sessão.
  • O conteúdo de plugin de um repo private aparece em Customize apenas para organizações cuja integração Git consegue alcançar o repo; nos demais casos, ele fica retido até que o repo seja concedido em Configurações → Repositories.

​
Saiba mais