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

# Plugins

> Instale e compartilhe pacotes de skills de um repo, URL do git ou pasta local.

<Note>
  Os plugins estão em **beta**. O comportamento e a configuração podem mudar em versões futuras.
</Note>

Um **plugin** é um pacote de [skills](/pt-BR/cli/extensibility/skills/overview) que você pode
instalar de um repo do GitHub, de uma URL do git ou de uma pasta local e reutilizar em diferentes
projetos. Ao instalar um plugin, suas skills ficam disponíveis como
comandos de barra `/<plugin>:<skill>`, e ele também pode incluir automaticamente outros plugins dos quais depende.

Um plugin é simplesmente uma origem que contém:

```
my-plugin/
├── .devin-plugin/
│   └── plugin.json     # O manifesto do plugin
└── skills/
    └── review/
        └── SKILL.md    # Um skill comum
```

O diretório `skills/` armazena skills comuns — os plugins não introduzem nenhum novo
formato de skill. Consulte [Criando Skills](/pt-BR/cli/extensibility/skills/creating-skills) para ver o
formato `SKILL.md`.

***

<div id="installing-a-plugin">
  ## Instalando um plugin
</div>

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

```bash theme={null}
# 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.

***

<div id="managing-plugins">
  ## Gerenciamento de plugins
</div>

```bash theme={null}
# 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`.

***

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

`.devin-plugin/plugin.json` descreve o plugin. Apenas `name` é obrigatório, e
ele deve ser único entre os plugins instalados (é o namespace `/<name>:…`).

```jsonc theme={null}
{
  "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/*", "*"]
}
```

Campos de metadados suportados: `name`, `version`, `description`, `author`
(`{ name, email }`), `homepage`, `repository`, `license` e `keywords`.

Uma entrada de dependência é uma **origem** — pode ser uma string abreviada ou um objeto:

* `"owner/repo"` → GitHub
* `"https://…"`, `"git@…"`, `"ssh://…"` → URL do git
* `{ "source": "github", "repo": "owner/repo" }`
* `{ "source": "url", "url": "https://gitlab.com/team/plugin.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 de plugin.

***

<div id="dependencies-and-governance">
  ## Dependências e governança
</div>

Um plugin pode declarar três listas, permitindo que um único plugin funcione como uma coleção curada e governada
de outros plugins.

<div id="requiredplugins">
  ### `requiredPlugins`
</div>

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.

<div id="optionalplugins">
  ### `optionalPlugins`
</div>

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

<div id="forbiddenplugins">
  ### `forbiddenPlugins`
</div>

Uma **lista de bloqueio**. Cada entrada é uma das seguintes:

* Uma identidade exata de plugin, escrita como `owner/repo`, uma URL git ou um caminho local.
* Um **padrão glob** — qualquer entrada que contenha `*`. O `*` corresponde a qualquer sequência de
  caracteres, incluindo `/`. Os padrões são normalizados primeiro para o espaço
  de identidade canônica, então `acme/*` se torna `https://github.com/acme/*` (todos os
  repos do GitHub da `acme`), `*/secrets` corresponde a um repo
  chamado `secrets` de qualquer owner, e `https://gitlab.com/acme/*`
  corresponde a qualquer repo nesse caminho.
* O único `"*"`, que corresponde a todos os outros plugins (um bloqueio total impossível de contornar).

As regras da política são:

* **A negação prevalece.** Um plugin é bloqueado se qualquer plugin instalado o proibir (por sua
  identidade exata, por um glob correspondente ou por `"*"`).
* **Auto-override.** Os `requiredPlugins`, `optionalPlugins` e o próprio plugin ficam isentos
  da sua **própria** lista de bloqueio. Portanto,
  `forbiddenPlugins: ["*"]` junto com `optionalPlugins: [B, C]` significa "permitir
  a mim mesmo, B e C; proibir todo o resto."
* **Sem reautorização entre plugins.** As listas de permissão de um plugin não podem voltar a permitir
  o que **outro** plugin proíbe. Um plugin instalado com
  `forbiddenPlugins: ["*"]` é um bloqueio total impossível de contornar.
* **Aberto por padrão.** Se nenhum plugin instalado proíbe nada, nada é bloqueado.

A política é aplicada em dois momentos:

* **No momento da instalação** — a instalação de um plugin bloqueado (ou de um cujos plugins obrigatórios
  não podem ser atendidos, ou cujo nome colide com o de um plugin instalado) é
  recusada.
* **No momento do carregamento** — se um plugin passar a ser bloqueado após a instalação (por exemplo, se um
  plugin que o proíbe for instalado depois), ele permanece em disco, mas suas
  skills são ignoradas no início da sessão, com um aviso informando o nome do plugin que o proíbe.