Plugins do Devin CLI

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>. Esta página aborda plugins no CLI; para o web app — a página Customize, escopos de organização e enterprise, indexação e conexões MCP — consulte o guia de Plugins. 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 em sessões locais do Devin (o CLI e o Devin Desktop) em que o plugin está instalado. Os hooks de plugin são atualmente de melhor esforço e falham abertos — se um hook não for carregado ou executado, a sessão continua sem ele — portanto, não dependa deles para guardrails cruciais ainda.
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. No CLI, autentique o servidor OAuth de um plugin com devin mcp login; as sessões em nuvem usam a conexão feita no web app (consulte MCPs). 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. Referencie segredos como ${NAME}; valores literais escritos na configuração são removidos.

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; acrescente #path/to/plugin quando o plugin estiver abaixo da raiz do repositório:

# Do GitHub
devin plugins install acme/review-tools

# Um plugin em uma subpasta de um repo
devin plugins install acme/plugins#plugins/review

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

# De uma pasta local (ótimo para criação) — apenas nesta máquina, vinculado à pasta
devin plugins install --local ./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. Por padrão, o install registra o plugin no seu manifesto pessoal no Devin Cloud, de modo que os mesmos plugins são carregados em todas as máquinas em que você fizer login (e nas suas sessões em nuvem). Use --local para instalar apenas na máquina atual. Uma pasta local não pode ser registrada no seu manifesto pessoal, então instale-a com --local, que a vincula nesta máquina. Para gerenciar plugins é necessário estar autenticado (devin auth login); uma Enterprise pode desativar os plugins do CLI para seus membros e, nesse caso, os plugins instalados não são aplicados.

Gerenciando plugins

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

# Mostra as skills, hooks e regras de um plugin, além de suas listas required/optional/forbidden
devin plugins info review-tools

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

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

# Remove apenas desta machine (falha para plugins que estão nos seus plugins pessoais)
devin plugins remove review-tools --local

# Descarta requisitos de plugin de repos que não estão mais em disco e limpa o conteúdo de plugin não utilizado
devin plugins prune

remove --force remove um plugin mesmo que outro plugin ou um manifesto de governança ainda o exija; um plugin exigido por governança é reinstalado na próxima sessão dentro do escopo que o exige, e a CLI avisa qual configuração de enterprise, organização ou repositório ainda o exige. Plugins de pasta local são vinculados diretamente à sua pasta de origem, então as edições valem de imediato: devin plugins install --local ./my-plugin → edite skills/<name>/SKILL.md → as changes passam a valer na próxima sessão, sem precisar de update. Se a CLI tem o plugin, mas o Customize mostra conteúdo ausente ou obsoleto, consulte Resolver problemas de indexação. devin plugins update atualiza o conteúdo local do plugin; Reindex plugins no Customize atualiza a listagem na web. Uma instalação feita com --local fica restrita a este dispositivo.

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
`{ "source": "github", "repo": "owner/repo", "sha": "3f2a9c1…" }`	fixado em um commit exato — nunca muda até você editar a entrada
`{ "source": "github", "repo": "owner/repo", "ref": "v2" }`	acompanha um branch ou tag — resolvido novamente a cada atualização

sha e ref funcionam com todos os formatos de objeto (github, url, git-subdir) e são mutuamente exclusivos: um sha é uma fixação, enquanto um ref é flutuante. Sem nenhum dos dois, a origem acompanha o branch padrão do repositório. 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 da Enterprise.
Org — um manifesto gerenciado no nível da organização, em uma camada abaixo da sua Enterprise (uma organização pode acrescentar ao que a Enterprise declara, mas não pode se sobrepor a isso). As sessões em nuvem usam o manifesto da organização da sessão; a CLI e o Devin Desktop usam o manifesto da sua organização principal.
Repo — os requiredPlugins / optionalPlugins / forbiddenPlugins em um .devin/config.json de um checkout, encontrados ao subir a partir do seu diretório de trabalho (em sessões em nuvem, a partir de cada repositório clonado).
User — plugins que você instala com devin plugins install (sincronizados por meio do seu manifesto pessoal) ou com --local nesta máquina.

A CLI busca os manifestos da Enterprise, da organização e o pessoal no Devin Cloud quando você faz login; os administradores gerenciam os dois primeiros pelo web app (veja o guia de Plugins). 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.
Um conflito de pin — dois manifestos fixando o mesmo plugin em shas diferentes — deve ser resolvido alinhando os pins ou deixando o pin a cargo do nível de autoridade mais alta.
Quando um manifesto gerenciado não pode ser obtido no início da sessão, esse nível falha de forma aberta: nada dele é instalado e seus forbids não são aplicados naquela sessão.

Primeiros passos

Integrações do Editor

Extensibilidade

Enterprise

Referência

Changelog

Plugins do Devin CLI

Formatos compatíveis

Instalando um plugin

Gerenciando 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

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

Gerenciando 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