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.

Um plugin é um pacote de skills e regras, hooks, servidores MCP ou subagentes personalizados opcionais que você pode instalar de um repo do GitHub, de uma URL do git, de uma subpasta de um repo ou de uma pasta local. Os plugins funcionam em sessões em nuvem do Devin, no Devin CLI e no Devin Desktop, sujeitos às limitações específicas de cada interface descritas abaixo. Ao instalar um plugin, suas skills ficam disponíveis como comandos de barra /<plugin>:<skill>. O plugin é a unidade de instalação. Instalar um plugin instala todas as suas skills e seus requiredPlugins; não é possível instalar skills individuais de um plugin. Para oferecer skills separadamente, divida-as em plugins separados. Um plugin é simplesmente uma origem que contém:

my-plugin/
├── .devin-plugin/
│   └── plugin.json     # O manifesto do plugin
├── AGENTS.md           # Regra always-on opcional
├── rules/              # Regras acionadas opcionais
├── agents/
│   └── reviewer.md     # Subagente personalizado opcional (reviewer/AGENT.md também funciona)
├── hooks.json          # Hooks de ciclo de vida opcionais
├── .mcp.json           # Servidores MCP opcionais
└── skills/
    └── review/
        └── SKILL.md    # Uma skill comum

O diretório skills/ armazena skills comuns — os plugins não introduzem nenhum novo formato de skill. Consulte Criando Skills para ver o formato SKILL.md. Um repo (ou uma subpasta git-subdir) é um plugin. Um único repo pode hospedar muitos plugins como subpastas, cada um referenciado com sua própria origem git-subdir. Além de skills, um plugin pode incluir:

Regras — um AGENTS.md na raiz do plugin é injetado como uma regra sempre ativa em toda sessão, junto com as regras do seu projeto. Arquivos Markdown em uma pasta rules/ também são carregados, com o mesmo frontmatter trigger e os mesmos tipos de ativação das regras do Windsurf.
Subagentes personalizados — perfis agents/<name>.md ou agents/<name>/AGENT.md (o mesmo formato de subagente personalizado dos subagentes do projeto), disponíveis como <plugin>:<name>. Atualmente, os subagentes de plugin são carregados apenas em agentes locais do Devin — o CLI e o Devin Desktop — não em sessões em nuvem do Devin.
Hooks — um hooks.json na raiz do plugin registra hooks de ciclo de vida que são executados em toda sessão em que o plugin está instalado. Em sessões em nuvem, os hooks command são executados na máquina da sessão e só são acionados enquanto essa máquina estiver ativa. Eles oferecem suporte a todos os eventos, exceto SessionStart e SessionEnd — incluindo PreToolUse, PostToolUse, PermissionRequest, UserPromptSubmit, Stop e PostCompaction; os hooks do tipo prompt são exclusivos do CLI/local.
Servidores MCP — os plugins podem fornecer servidores MCP opcionais que são iniciados com a sessão. Suas ferramentas estão disponíveis para o Devin, embora os servidores MCP de plugin ainda não apareçam na UI de configurações de MCP. Uma configuração de MCP de plugin pode definir um ID de cliente OAuth e escopos, mas nunca um segredo do cliente — uma configuração de servidor que contenha um é rejeitada na ativação.

Formatos compatíveis

O layout acima é o formato de plugin do próprio Devin. O Devin também carrega plugins empacotados em outros dois layouts, com a seguinte precedência de manifesto: .devin-plugin/plugin.json > .claude-plugin/plugin.json > plugin.json na raiz:

Plugins do Claude — se não houver .devin-plugin/plugin.json, o Devin recorre a .claude-plugin/plugin.json. O .mcp.json na raiz dos plugins do Claude e o campo mcpServers do manifesto são considerados, e ${CLAUDE_PLUGIN_ROOT} nas configurações de servidor é expandido para a raiz do plugin.
Plugins de Agent — plugins empacotados de acordo com a spec aberta Agent Plugins 1.0.0 (um manifesto plugin.json na raiz do plugin, servidores MCP em um mcp.json na raiz e skills em skills/) também são carregados. Para esses plugins, o mcp.json na raiz é lido como uma origem MCP convencional (após .mcp.json, que tem precedência em caso de conflito de nome de servidor) — plugins legados nos layouts Devin/Claude nunca o leem, a menos que o manifesto o declare explicitamente. As entradas MCP podem declarar o transporte usando o campo type da spec (stdio, streamable-http ou sse) em vez de transport, e ${PLUGIN_ROOT} nas configurações de servidor é expandido para a raiz do plugin, assim como ${CLAUDE_PLUGIN_ROOT}. Uma versão de $schema não reconhecida gera um aviso, mas o plugin ainda é carregado da melhor forma possível. Os servidores MCP dos Plugins de Agent também seguem as convenções de runtime da spec (elas se aplicam apenas a plugins cujo manifesto é o plugin.json na raiz; os layouts do Devin e do Claude se comportam exatamente como antes):
- ${PLUGIN_DATA} em args, valores de env e cwd é expandido para um diretório de dados persistente e gravável específico do plugin. O diretório é associado à identidade do plugin — não à versão — portanto, seu conteúdo é preservado após atualizações do plugin e excluído quando o plugin é desinstalado.
- Processos de servidor stdio recebem as variáveis de ambiente PLUGIN_ROOT e PLUGIN_DATA junto com qualquer env definido na configuração.
- Um servidor pode definir cwd (relativo à raiz do plugin); por padrão, ele é a raiz do plugin. Um command com o prefixo ./ é resolvido em relação à raiz do plugin, permitindo que os plugins incluam seus próprios executáveis. Ambos são validados para permanecer dentro da raiz do plugin ou do diretório de dados.

Instalando um plugin

A origem de um plugin pode ser um owner/repo do GitHub, uma URL do git ou um caminho local:

# Do GitHub
devin plugins install acme/review-tools

# De qualquer host git
devin plugins install https://gitlab.com/acme/review-tools.git

# De uma pasta local (ótimo para criação)
devin plugins install ./my-plugin

Antes de instalar, o Devin mostra o que o plugin adiciona — os skills que ele fornece, quais plugins obrigatórios serão instalados automaticamente e quaisquer políticas que ele introduza (por exemplo, se ele proíbe outros plugins). Use -y / --yes para pular o prompt. Os plugins são instalados no nível de usuário e ficam disponíveis em todos os seus projetos.

Gerenciamento de plugins

# Lista os plugins instalados, suas versões e se algum está bloqueado por política
devin plugins list

# Exibe as skills de um plugin e suas listas de obrigatórios/opcionais/proibidos
devin plugins info review-tools

# Rebusca um plugin (ou todos os plugins) na versão mais recente
devin plugins update review-tools
devin plugins update

# Remove um plugin (plugins obrigatórios instalados automaticamente são mantidos no lugar)
devin plugins remove review-tools

Plugins locais ficam vinculados diretamente à pasta de origem, então as edições entram em vigor em tempo real: devin plugins install ./my-plugin → edite skills/<name>/SKILL.md → as alterações são aplicadas na próxima sessão, sem precisar de update.

Manifesto

.devin-plugin/plugin.json descreve o plugin. Apenas name é obrigatório, e ele deve ser único entre os plugins instalados (é o namespace /<name>:…). Os nomes consistem em caracteres alfanuméricos minúsculos, separados por um único - ou . (por exemplo, review-tools, acme.tools).

{
  "name": "review-tools",
  "version": "1.0.0",
  "description": "Code-review skills for our team",
  "requiredPlugins": [
    "acme/secure-base",
    { "source": "github", "repo": "acme/audit-logging" }
  ],
  "optionalPlugins": [
    "acme/deploy-tools",
    { "source": "url", "url": "https://gitlab.com/acme/extra.git" }
  ],
  "forbiddenPlugins": ["sketchy-org/bad-plugin", "acme/*", "*"]
}

Metadados

name, version, description, author ({ name, email }), homepage, repository, license e keywords. Apenas name é usado para a identidade e o namespace do plugin; os demais são descritivos e exibidos por devin plugins info.

Skills & Regras

O campo skills controla de onde as skills são carregadas, substituindo o diretório skills/ padrão. Ele aceita um único caminho relativo à raiz do plugin ou um array desses caminhos:

{ "skills": "custom-skills" }
{ "skills": ["skills", "extra/skills"] }

Um array vazio ("skills": []) desativa completamente o carregamento de skills. Os caminhos devem permanecer dentro do plugin — caminhos absolutos, ~ e percursos com .. são rejeitados, e uma entrada inválida invalida todo o manifesto. As regras são carregadas independentemente das skills: um AGENTS.md na raiz do plugin fica always-on, e os arquivos Markdown no diretório rules/ são carregados como regras acionadas. Consulte Regras para detalhes sobre a ativação.

Servidores MCP

O campo mcpServers adiciona declarações de servidores MCP. Os plugins também podem usar o arquivo raiz convencional .mcp.json (e o mcp.json para plugins que usam o layout de manifesto raiz do Plugins de Agent). São aceitos quatro formatos:

// Um arquivo de declaração
{ "mcpServers": "config/mcp.json" }

// Vários, lidos na ordem em que forem listados
{ "mcpServers": ["config/mcp.json", "config/extra.json"] }

// Somente estes arquivos — desativa a convenção .mcp.json / mcp.json na raiz
{ "mcpServers": { "paths": ["config/mcp.json"], "exclusive": true } }

// Mapa de servidores inline (desativa a convenção da raiz quando não estiver vazio)
{ "mcpServers": { "linear": { "command": "npx", "args": ["-y", "linear-mcp"] } } }

Os caminhos declarados seguem as mesmas regras de contenção de skills, mas as entradas inseguras são descartadas em vez de causar falha no plugin. Um campo mcpServers inválido apenas desativa o carregamento de MCP, mantendo skills, regras e hooks utilizáveis. Um array vazio não adiciona arquivos de declaração, mas não desativa a convenção de raiz. Da mesma forma, um mapa inline vazio mantém a convenção de raiz ativada. Quando o mesmo nome de servidor aparece em mais de uma origem, a primeira origem prevalece.

Dependências

Uma entrada de dependência é uma origem — seja uma forma abreviada em string 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. Um plugin pode declarar três listas, permitindo que um único plugin funcione como uma coleção curada e governada de outros plugins.

`requiredPlugins`

Instalado automaticamente (de forma recursiva) quando o plugin é instalado. Se um plugin obrigatório for bloqueado por uma política, a instalação inteira falha — não há instalação parcial.

`optionalPlugins`

Uma lista de permissões de plugins que este plugin aprova. Eles não são instalados automaticamente; a lista só serve como uma exceção para uma entrada proibida (veja abaixo).

`forbiddenPlugins`

Uma lista de bloqueio de identidades de plugin e padrões glob. 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.

Uma identidade proibida também pode ser um caminho local (para plugins instalados a partir de uma pasta local), além das formas owner/repo e URL do git acima.

Herança e níveis

Os plugins não são declarados em um único lugar. Além das instalações que você faz, os plugins podem ser obrigatórios, recomendados ou proibidos pelo seu repo e pelo administrador da sua organização. Cada origem é um nível, e os níveis são classificados por autoridade, da mais alta para a mais baixa:

Enterprise — o manifesto gerenciado em nível da conta, configurado por um administrador.
Org — um manifesto gerenciado no nível da organização, em uma camada abaixo da conta (uma organização pode acrescentar ao que a conta declara, mas não pode se sobrepor a isso). Isso se aplica apenas a sessões em nuvem do Devin: a CLI autentica no nível da conta e não tem contexto de organização, portanto exigências e proibições no nível da organização não alcançam usuários da CLI. Coloque tudo o que precisar ser aplicado na CLI no manifesto da Enterprise/conta.
Repo — os requiredPlugins / optionalPlugins / forbiddenPlugins em um .devin/config.json de um checkout, encontrados ao subir a partir do seu diretório de trabalho.
User — plugins que você instala com devin plugins install.

Cada nível declara as mesmas três listas e, dentro de um nível, elas se combinam com as mesmas regras em que a negação prevalece e de override próprio de um único manifesto. O que os níveis acrescentam além disso é uma regra: a autoridade mais alta prevalece.

A autoridade superior prevalece

Um nível inferior nunca pode voltar a permitir o que um nível superior proíbe.
Um nível inferior nunca pode proibir o que um nível superior exige — a proibição é ignorada e o plugin ainda é carregado.

Assim, um admin pode tornar obrigatório um plugin do qual nenhum repo ou user pode abrir mão e proibir um plugin que nenhum nível inferior pode reabilitar.

Uma lista de bloqueio só é sobrescrita no próprio nível

Como as listas de permissão não se aplicam entre níveis, a única maneira de criar uma exceção a uma lista de bloqueio é no mesmo nível que a declarou. O forbiddenPlugins de um nível só é sobrescrito pelo próprio optionalPlugins (ou requiredPlugins) desse mesmo manifesto — nunca por uma lista em um nível inferior. Por exemplo, um manifesto gerenciado em nível Enterprise pode restringir a conta a um único plugin aprovado:

// Manifest gerenciado em nível Enterprise
{
  "forbiddenPlugins": ["*"],
  "optionalPlugins": ["acme/approved"]
}

Isso significa “em toda a conta, permitir apenas acme/approved e proibir qualquer outro plugin.” Nenhuma org, repo ou usuário pode ampliar essa lista de permissões — nem instalando um plugin, nem adicionando-o ao optionalPlugins de um nível inferior. A exceção também cobre apenas as entradas que este manifesto lista diretamente; as dependências transitivas de um plugin obrigatório não estão isentas, portanto liste-as explicitamente em um bloqueio.

Conflitos e dependências

Um require e um forbid para o mesmo plugin no mesmo nível, mas em manifestos diferentes (por exemplo, dois plugins de nível de usuário instalados separadamente) resultam na prevalência do forbid — uma lista de permissões só isenta entradas do seu próprio manifesto, então não pode livrar um plugin que outro manifesto proíbe. (Dentro de um único manifesto, seus próprios require/optional continuam isentos de seus próprios forbids, como acima.)
Um plugin bloqueado por governança falha de forma não fatal: no início da sessão, suas skills são ignoradas com um aviso que identifica quem aplicou o forbid, em vez de abortar a sessão.
Ser usado como dependência não concede isenção. Um plugin incluído apenas como uma dependência transitiva ainda está sujeito a todo forbid aplicável a ele e herda o nível de autoridade mais alto de qualquer plugin que o exija.

Primeiros passos

Integrações do Editor

Extensibilidade

Enterprise

Referência

Changelog

Formatos compatíveis

Instalando um plugin

Gerenciamento de plugins

Manifesto

Metadados

Skills & Regras

Servidores MCP

Dependências

`requiredPlugins`

`optionalPlugins`

`forbiddenPlugins`

Herança e níveis

A autoridade superior prevalece

Uma lista de bloqueio só é sobrescrita no próprio nível

Conflitos e dependências

​Formatos compatíveis

​Instalando um plugin

​Gerenciamento de plugins

​Manifesto

​Metadados

​Skills & Regras

​Servidores MCP

​Dependências

​requiredPlugins

​optionalPlugins

​forbiddenPlugins

​Herança e níveis

​A autoridade superior prevalece

​Uma lista de bloqueio só é sobrescrita no próprio nível

​Conflitos e dependências

Formatos compatíveis

Instalando um plugin

Gerenciamento de plugins

Manifesto

Metadados

Skills & Regras

Servidores MCP

Dependências

`requiredPlugins`

`optionalPlugins`

`forbiddenPlugins`

Herança e níveis

A autoridade superior prevalece

Uma lista de bloqueio só é sobrescrita no próprio nível

Conflitos e dependências