> ## Documentation Index
> Fetch the complete documentation index at: https://docs.devin.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Marketplace de plugins

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

<Note>
  Plugins estão em **beta fechada**. Para solicitar acesso, entre em contato com [support@cognition.ai](mailto:support@cognition.ai). O comportamento e a configuração podem mudar em versões futuras.
</Note>

<div id="what-are-plugins">
  ## O que são plugins?
</div>

Um **plugin** é um conjunto de [skills](/pt-BR/product-guides/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](/pt-BR/cli/index) 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](#cloud-sessions-vs-the-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](/pt-BR/cli/extensibility/plugins/overview).

<div id="where-to-configure-them">
  ## Onde configurá-los
</div>

Acesse [**Configurações → Marketplace**](https://app.devin.ai/settings/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**](https://app.devin.ai/settings/marketplace?tab=configuration) — 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**.

<div id="the-manifest">
  ## O manifest
</div>

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

```jsonc theme={null}
{
  "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.

<div id="governance-rules">
  ### Regras de governança
</div>

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.

<div id="adding-your-own-plugins">
  ## Adicionando seus próprios plugins
</div>

Um plugin é apenas um diretório que contém um arquivo de manifest `.devin-plugin/plugin.json` e uma pasta `skills/` com [skills](/pt-BR/product-guides/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](/pt-BR/cli/extensibility/plugins/overview).
* **Hooks** — um `hooks.json` na raiz do plugin registra [hooks de lifecycle](/pt-BR/cli/extensibility/hooks/lifecycle-hooks) 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](/pt-BR/work-with-devin/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](/pt-BR/cli/extensibility/plugins/overview) 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](/pt-BR/cli/extensibility/plugins/overview) 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](#using-a-private-skills-repo) 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`.

<div id="uploading-a-plugin-bundle">
  ### Importando um pacote de plugin
</div>

Na aba [**Configuração**](https://app.devin.ai/settings/marketplace?tab=configuration), 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).

<div id="using-a-private-skills-repo">
  ### Como usar um repo privado de skills
</div>

Aponte o manifest diretamente para o repo privado — em geral, você não precisa incorporá-lo ao seu [snapshot de ambiente](/pt-BR/onboard-devin/environment/blueprints). 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.

<div id="how-updates-roll-out">
  ## Como as atualizações são distribuídas
</div>

* **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.

<div id="compatibility">
  ## Compatibilidade
</div>

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.

<div id="scope-and-inheritance">
  ## Escopo e herança
</div>

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](/pt-BR/cli/extensibility/plugins/overview), 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](#governance-rules)).

<div id="cloud-sessions-vs-the-cli">
  ### Sessões em nuvem vs. a CLI
</div>

Tanto as sessões em nuvem do Devin quanto a [Devin CLI](/pt-BR/cli/index) 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.

<div id="learn-more">
  ## Saiba mais
</div>

* [Skills](/pt-BR/product-guides/skills) — os procedimentos `SKILL.md` que os plugins incluem
* [Referência de plugins da CLI](/pt-BR/cli/extensibility/plugins/overview) — formato de arquivo do plugin, criação e instalação por usuário
* [Playbooks](/pt-BR/product-guides/creating-playbooks) — templates de prompt reutilizáveis associados a sessões