Marketplace de plugins

Instale e torne obrigatórios pacotes de skills para todos na sua org ou Enterprise pelo web app do Devin

Plugins estão em beta fechada. Para solicitar acesso, entre em contato com [e-mail]. O comportamento e a configuração podem mudar em versões futuras.

​

O que são plugins?

Um plugin é um conjunto de skills — e, opcionalmente, regras, hooks e servidores MCP — empacotadas para poder ser instalado e reutilizado como uma unidade. Enquanto uma skill fica em um único repo, um plugin é uma origem portátil (um repo do GitHub, uma URL do git, uma subpasta de um repo ou um .zip importado) que você pode tornar obrigatória em toda a sua org ou Enterprise.

Plugins gerenciados permitem que um admin instale plugins de forma centralizada, pelo web app do Devin, para que se apliquem a todos na org ou Enterprise — sem configuração por usuário. Isso cobre sessões em nuvem do Devin e usuários do Devin CLI conectados à conta (a configuração no nível de Enterprise/conta também se aplica ao CLI — consulte sessões em nuvem vs. o CLI). Quando um plugin é instalado, suas skills ficam automaticamente disponíveis para o Devin como comandos /<plugin>:<skill>.

Esta página aborda o lado da nuvem (web app) dos plugins. Para o formato de arquivo do plugin e o fluxo de instalação por usuário do CLI, consulte a referência de plugins da CLI.

​

Onde configurá-los

Acesse Configurações → Marketplace. A página tem duas abas:

• Marketplace — navegue pelos plugins (o catálogo oficial do Devin e quaisquer plugins que sua org ou Enterprise tenha adicionado) e instale-os. Instalar um plugin o adiciona ao manifest do escopo escolhido como plugin obrigatório, então ele é instalado para todos nesse escopo.
• Configuração — edite o manifest bruto do plugin em JSON e importe seu próprio plugin como uma pasta ou arquivo .zip (ou crie um no editor).

O acesso é controlado por permissões:

• Admins da org (acesso às configurações da organização) gerenciam o manifest da org.
• Admins do Enterprise (acesso às configurações do Enterprise) também gerenciam o manifest compartilhado do Enterprise.

​

O manifest

O manifest é um único documento JSON com três listas:

{
  "requiredPlugins": [
    // proprietário/repo do GitHub
    "acme/review-tools",

    // qualquer URL do git
    "https://gitlab.com/acme/secure-base.git",

    // forma de objeto
    { "source": "github", "repo": "acme/audit-logging" },

    // um plugin em uma subpasta
    {
      "source": "git-subdir",
      "url": "https://github.com/acme/vendor-plugins.git",
      "path": "plugins/stripe"
    }
  ],

  "optionalPlugins": [],

  "forbiddenPlugins": [
    "sketchy-org/bad-plugin",
    "acme/*"
  ]
}

• requiredPlugins — instalados para todos dentro do escopo (recursivamente, incluindo todos os plugins dos quais dependem).
• optionalPlugins — uma lista de permissões que autoriza plugins sem instalá-los automaticamente; usada para abrir exceções para uma entrada proibida.
• forbiddenPlugins — uma lista de bloqueio de identidades de plugin ou padrões glob (por exemplo, acme/* ou "*" para um bloqueio total).

Cada entrada em requiredPlugins / optionalPlugins é uma origem — seja uma string abreviada ou um objeto:

Forma	Significado
"owner/repo"	repositório GitHub
"https://…", "git@…", "ssh://…"	qualquer URL do git
{ "source": "github", "repo": "owner/repo" }	GitHub, em formato de objeto
{ "source": "url", "url": "https://gitlab.com/team/plugin.git" }	URL do git, em formato de objeto
{ "source": "git-subdir", "url": "…", "path": "sub/dir" }	um plugin em uma subpasta de um repositório compartilhado

Todas as formas do GitHub para o mesmo repositório (owner/repo, a URL HTTPS, a URL .git e a forma SSH) se referem à mesma identidade do plugin.

O manifest é armazenado na íntegra; o agente valida a origem completa no momento da instalação.

​

Regras de governança

As entradas de forbiddenPlugins são comparadas com identidades de plugin:

• Uma identidade exata, escrita como owner/repo ou uma URL do git. Todas as formas do GitHub para o mesmo repo (owner/repo, a URL HTTPS, a URL .git, a forma SSH) se referem à mesma identidade.
• Um padrão glob — qualquer entrada que contenha *. O * corresponde a qualquer sequência de caracteres, incluindo /: acme/* corresponde a todos os repos do GitHub de acme, */secrets corresponde a um repo chamado secrets em qualquer owner, e https://gitlab.com/acme/* corresponde a qualquer repo nesse caminho.
• Um "*" isolado, que corresponde a todo o restante (um bloqueio total).

As listas são combinadas com precedência da negação:

• A negação prevalece. Um plugin é bloqueado se qualquer manifesto ativo ou plugin instalado o proibir. Se nada proíbe nada, nada é bloqueado.
• Auto-override. Os requiredPlugins e optionalPlugins de um manifesto (ou plugin) — e, no caso de um plugin, o próprio plugin — ficam isentos da sua própria lista de proibidos. Assim, "forbiddenPlugins": ["*"] mais "optionalPlugins": ["acme/approved"] significa “permitir apenas o que este manifesto lista; proibir todo o restante”. A exceção cobre apenas essas entradas diretas, não as dependências transitivas de um plugin obrigatório — liste-as explicitamente em um bloqueio total.
• Sem repermissão entre escopos. A lista de permissões de um manifesto ou plugin não pode voltar a permitir o que outro proíbe. Um bloqueio total com "forbiddenPlugins": ["*"] não pode ser contornado a partir de um escopo inferior.

A aplicação ocorre em dois momentos:

• No momento da instalação — a instalação de um plugin bloqueado (ou de um cujos plugins obrigatórios não possam ser atendidos, ou cujo nome colida com o de um plugin instalado) é recusada.
• No momento do carregamento — um plugin bloqueado depois de já estar instalado permanece no disco, mas suas skills são ignoradas no início da sessão, com um aviso informando quem fez o bloqueio.

Além dessas regras, os manifests gerenciados são hierarquizados por nível — Enterprise/conta acima de org, acima da configuração de plugin em nível de repo e de usuário. O nível de maior autoridade prevalece: um nível inferior nunca pode proibir um plugin que um nível superior exige, nem voltar a permitir um plugin que um nível superior proíbe. Assim, uma proibição em nível de org não pode bloquear um plugin exigido pelo Enterprise, mas uma proibição do Enterprise se sobrepõe a uma exigência da org.

​

Adicionando seus próprios plugins

Um plugin é apenas um diretório que contém um arquivo de manifest .devin-plugin/plugin.json e uma pasta skills/ com skills comuns:

my-plugin/
├── .devin-plugin/
│   └── plugin.json     # nome, versão e listas de dependências opcionais
├── AGENTS.md           # regra always-on opcional
├── rules/              # regras acionadas opcionais
├── hooks.json          # lifecycle hooks opcionais
├── mcp_config.json     # servidores MCP opcionais
└── skills/
    └── review/
        └── SKILL.md    # uma skill comum

Além das skills, um plugin pode incluir:

• Rules — um AGENTS.md na raiz do plugin é injetado como uma regra always-on em cada sessão — tanto em sessões em nuvem quanto na CLI. Arquivos Markdown em uma pasta rules/ também são carregados, respeitando o frontmatter trigger — consulte a referência de plugins da CLI.
• Hooks — um hooks.json na raiz do plugin registra hooks de lifecycle executados na sessão. Sessões em nuvem executam hooks command para todos os eventos, exceto SessionStart e SessionEnd — portanto, PreToolUse, PostToolUse, PermissionRequest, UserPromptSubmit, Stop e PostCompaction funcionam; hooks do tipo prompt são exclusivos da CLI/local.
• servidor MCP — um mcp_config.json na raiz do plugin declara servidores MCP ("mcpServers": { "<name>": { … } }) que são carregados em todas as sessões em que o plugin está instalado. Eles ainda não aparecem na UI de configurações de MCP, mas suas tools estão disponíveis para o Devin. A configuração de MCP de um plugin pode definir um Client ID e Scopes de um cliente OAuth, mas nunca um Client Secret de cliente OAuth — uma configuração de servidor que inclua um deles será rejeitada na ativação.
• subagente personalizado — perfis agents/<name>.md (ou agents/<name>/AGENT.md). Atualmente, eles são carregados apenas em agentes locais do Devin — o Devin CLI e o Devin Desktop — não em sessões em nuvem.

O plugin é a unidade de instalação: ao instalá-lo, todas as suas skills são instaladas (além de tudo que estiver em requiredPlugins) — não é possível instalar skills individuais de um plugin. Para oferecer skills separadamente, divida-as em plugins distintos. Consulte a referência de plugins da CLI para ver o formato completo de plugin.json e o fluxo de criação local.

Dependendo de onde o plugin está, adicione-o de uma destas formas:

Onde ele está	Como adicioná-lo
Repositório Git público	Adicione "owner/repo" (ou a URL do git) ao manifest, ou instale pela aba Marketplace se estiver no catálogo
Repositório Git privado	A mesma entrada no manifest — veja como usar um repo privado de skills para entender como a autenticação funciona
Subpasta de um repositório Git (por exemplo, um monorepo de plugins)	{ "source": "git-subdir", "url": "…", "path": "sub/dir" } — cada subpasta é um plugin próprio
Não está em um repositório Git	Importe-o como um pacote (abaixo)

Um repositório Git (ou uma subpasta git-subdir) corresponde a um plugin. Um único repositório Git pode hospedar vários plugins em subpastas, cada um referenciado com sua própria entrada git-subdir.

​

Importando um pacote de plugin

Na aba Configuração, a seção Plugin importado permite importar um plugin como pasta ou arquivo .zip, ou criar um diretamente no editor. Ao salvá-lo, ele é adicionado ao manifest como um plugin obrigatório (instalando-o para todos no escopo); ao excluí-lo, a referência é removida. Esta é uma boa opção para um plugin que você não quer hospedar em um repositório Git (ou não pode).

​

Como usar um repo privado de skills

Aponte o manifest diretamente para o repo privado — em geral, você não precisa incorporá-lo ao seu snapshot de ambiente. Qualquer repo privado que o Devin já consiga acessar pela sua integração com o Git é instalado automaticamente. Use o formato de URL do git ou git-subdir para instalar um plugin a partir de uma subpasta de um repo compartilhado. (Os usuários da CLI cobertos pelo mesmo manifest fazem o fetch com suas próprias credenciais locais do git, então também precisarão de acesso ao repo.)

Se o repo não puder ser acessado pela sua integração com o Git, importe-o como um pacote (acima) ou clone-o durante a configuração do ambiente e faça referência a ele com um caminho local.

​

Como as atualizações são distribuídas

• Alterações no manifest (Configurações → Marketplace) passam a valer na próxima sessão.
• Alterações no plugin — ao fazer merge na branch que o plugin acompanha, elas chegam automaticamente às novas sessões em algumas horas. Fixe o plugin em um SHA de commit para controlar as atualizações por conta própria; na CLI, devin plugins update atualiza imediatamente.
• As sessões em execução mantêm o que carregaram no início — as atualizações nunca alteram uma sessão no meio da execução.

​

Compatibilidade

Os plugins do Claude também funcionam: se não houver .devin-plugin/plugin.json, o Devin usa .claude-plugin/plugin.json como alternativa. Quando os dois manifests estão presentes, o do Devin prevalece.

​

Escopo e herança

Os manifests gerenciados existem em até dois níveis:

• Contas independentes têm um único manifest de conta que se aplica a todos.
• Enterprises têm um manifest de enterprise compartilhado que é herdado por cada org subordinada, além de um manifest por org em um nível abaixo. A visualização do Marketplace mostra ambos, e os admins do Enterprise podem optar por instalar um plugin no escopo do Enterprise (aplica-se em toda parte) ou um admin da org pode instalá-lo apenas na própria org.

Esses manifests ficam no topo da hierarquia geral de plugins, acima de qualquer configuração de plugin por repo ou por usuário:

1. Manifest de Enterprise / conta (esta página)
2. Manifest de Org (esta página)
3. Configuração de plugin no nível de Repo (o arquivo .devin/config.json de um repo)
4. Plugins no nível de User — instalações próprias de uma pessoa no CLI, que se aplicam apenas ao agente Devin local dela e nunca são carregadas em sessões em nuvem

Prevalece o nível de autoridade mais alto: um nível inferior nunca pode permitir um plugin que um nível superior proíba, nem proibir um que um nível superior exija (consulte as regras de governança).

​

Sessões em nuvem vs. a CLI

Tanto as sessões em nuvem do Devin quanto a Devin CLI aplicam o manifest de enterprise/account — os plugins obrigatórios são instalados, e as proibições também são impostas aos usuários da CLI que estiverem conectados à conta.

O manifest de org se aplica apenas a sessões em nuvem. A CLI se autentica no nível da conta e não tem contexto de org, então exigências e proibições no nível da org não se aplicam aos usuários da CLI. Coloque no manifest de enterprise/account tudo o que você precisar aplicar na CLI (ou em nível da conta) e use o manifest de org para adições específicas da org nas sessões em nuvem.

​

Saiba mais

• Skills — os procedimentos SKILL.md que os plugins incluem
• Referência de plugins da CLI — formato de arquivo do plugin, criação e instalação por usuário
• Playbooks — templates de prompt reutilizáveis associados a sessões