Plugins

Los plugins están en beta cerrada. Para solicitar acceso, contacta con support@cognition.ai. El comportamiento y la configuración pueden cambiar en futuras versiones.

Un plugin es un conjunto de skills que puedes instalar desde un repo de GitHub, una URL de git o una carpeta local y reutilizar en distintos proyectos. Al instalar un plugin, sus skills pasan a estar disponibles como comandos de barra diagonal /<plugin>:<skill>, y también puede incorporar automáticamente otros plugins de los que depende. Un plugin es simplemente un origen que contiene:

my-plugin/
├── .devin-plugin/
│   └── plugin.json     # El manifiesto del plugin
├── AGENTS.md           # Rule activa opcional
├── rules/              # Rules con trigger opcionales
├── agents/
│   └── reviewer.md     # Subagente personalizado opcional (reviewer/AGENT.md también funciona)
├── hooks.json          # Hooks de ciclo de vida opcionales
├── mcp_config.json     # Servidores MCP opcionales
└── skills/
    └── review/
        └── SKILL.md    # Un skill ordinario

El directorio skills/ contiene skills normales; los plugins no introducen ningún nuevo formato de skill. Consulta Creación de skills para ver el formato de SKILL.md. Además de skills, un plugin puede incluir:

Rules — un archivo AGENTS.md en la raíz del plugin se inyecta como una Rule activa en cada sesión, junto con las Rules del propio proyecto. Los archivos Markdown de una carpeta rules/ también se cargan, con el mismo frontmatter trigger y los mismos tipos de activación que las Rules de Windsurf.
subagentes personalizados — perfiles agents/<name>.md o agents/<name>/AGENT.md (el mismo formato de subagente personalizado que los subagentes del proyecto), disponibles como <plugin>:<name>. Actualmente, los subagentes del plugin solo se cargan en agentes locales de Devin: la CLI y Devin Desktop, no en sesiones de Devin en la nube.
Hooks — un archivo hooks.json en la raíz del plugin registra hooks del ciclo de vida que se ejecutan en cada sesión en la que el plugin está instalado.
servidores MCP — un archivo mcp_config.json en la raíz del plugin declara servidores MCP ("mcpServers": { "<name>": { … } }) que se inician con la sesión. También se respetan el archivo .mcp.json en la raíz de los plugins de Claude y el campo mcpServers del manifiesto.

Instalar un plugin

El origen de un plugin puede ser un owner/repo de GitHub, una URL de git o una ruta local:

# Desde GitHub
devin plugins install acme/review-tools

# Desde cualquier host de git
devin plugins install https://gitlab.com/acme/review-tools.git

# Desde una carpeta local (ideal para desarrollo de plugins)
devin plugins install ./my-plugin

Antes de instalarlo, Devin muestra lo que agrega el plugin: las skills que proporciona, los plugins requeridos que se instalarán automáticamente y cualquier política que introduzca (por ejemplo, si prohíbe otros plugins). Usa -y / --yes para omitir la confirmación. Los plugins se instalan a nivel de usuario y están disponibles en todos tus proyectos.

Administrar plugins

# Listar los plugins instalados, sus versiones y si alguno está bloqueado por política
devin plugins list

# Mostrar los skills de un plugin y sus listas de requeridos/opcionales/prohibidos
devin plugins info review-tools

# Volver a obtener un plugin (o todos los plugins) en la versión más reciente
devin plugins update review-tools
devin plugins update

# Eliminar un plugin (los plugins requeridos instalados automáticamente se conservan)
devin plugins remove review-tools

Los plugins locales se enlazan directamente con su carpeta de origen, por lo que las ediciones se reflejan al instante: devin plugins install ./my-plugin → edita skills/<name>/SKILL.md → los cambios se aplican en la siguiente sesión, sin necesidad de update.

El manifiesto

.devin-plugin/plugin.json describe el plugin. Solo name es obligatorio y debe ser único entre los plugins instalados (es el espacio de nombres /<name>:…).

{
  "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 metadatos compatibles: name, version, description, author ({ name, email }), homepage, repository, license y keywords. Dos campos opcionales adicionales controlan desde dónde se cargan los recursos: skills — una ruta o un arreglo de rutas a directorios de skills, que reemplaza el valor predeterminado skills/ — y mcpServers — rutas a archivos de declaración de MCP o un mapa inline de servidores, que se leen además de las convenciones raíz. Una entrada de dependencia es un origen: puede ser una cadena abreviada o un objeto:

Forma	Significado
`"owner/repo"`	repositorio de GitHub
`"https://…"`, `"git@…"`, `"ssh://…"`	cualquier URL de Git
`{ "source": "github", "repo": "owner/repo" }`	GitHub, en forma de objeto
`{ "source": "url", "url": "https://gitlab.com/team/plugin.git" }`	URL de Git, en forma de objeto
`{ "source": "git-subdir", "url": "…", "path": "sub/dir" }`	un plugin ubicado en una subcarpeta de un repositorio compartido

Todas las formas de GitHub para el mismo repositorio (owner/repo, la URL HTTPS, la URL .git, la forma SSH) se refieren a la misma identidad del plugin.

Dependencias y gobernanza

Un plugin puede declarar tres listas, lo que permite que un único plugin actúe como una colección seleccionada y gobernada de otros plugins.

`requiredPlugins`

Se instalan automáticamente (de forma recursiva) cuando se instala el plugin. Si un plugin requerido está bloqueado por una política, falla toda la instalación; no existe una instalación parcial.

`optionalPlugins`

Una lista de plugins permitidos que este plugin admite. No se instalan automáticamente; la lista solo importa como excepción frente a una entrada prohibida (ver más abajo).

`forbiddenPlugins`

Una lista de bloqueo de identidades de plugins y patrones glob. Las entradas de forbiddenPlugins se cotejan con las identidades de los plugins:

Una identidad exacta, escrita como owner/repo o una URL de Git. Todas las formas de GitHub del mismo repo (owner/repo, la URL HTTPS, la URL .git, la forma SSH) se refieren a la misma identidad.
Un patrón glob: cualquier entrada que contenga *. El * coincide con cualquier secuencia de caracteres, incluido /: acme/* coincide con todos los repos de GitHub de acme, */secrets coincide con un repo llamado secrets de cualquier propietario, y https://gitlab.com/acme/* coincide con cualquier repo bajo esa ruta.
El único "*", que coincide con todo lo demás (un bloqueo total).

Las listas se combinan con prioridad de denegación:

La denegación prevalece. Un plugin queda bloqueado si cualquier manifiesto activo o plugin instalado lo prohíbe. Si nada prohíbe nada, no se bloquea nada.
Excepción para sí mismo. Los requiredPlugins y optionalPlugins de un manifiesto (o de un plugin) —y, en el caso de un plugin, el propio plugin— están exentos de su propia lista de prohibidos, por lo que "forbiddenPlugins": ["*"] más "optionalPlugins": ["acme/approved"] significa “permitir solo lo que enumera este manifiesto; prohibir todo lo demás”. La excepción cubre solo esas entradas directas, no las dependencias transitivas de un plugin requerido; enumérelas explícitamente en un bloqueo total.
No se puede volver a permitir entre ámbitos. La lista de permitidos de un manifiesto o plugin no puede volver a permitir lo que otro prohíbe. Un bloqueo total con "forbiddenPlugins": ["*"] no puede eludirse desde un ámbito inferior.

La aplicación se produce en dos momentos:

En el momento de la instalación: se rechaza la instalación de un plugin bloqueado (o de uno cuyos plugins requeridos no pueden satisfacerse, o cuyo nombre entra en conflicto con un plugin instalado).
En el momento de la carga: un plugin bloqueado después de ya estar instalado permanece en disco, pero sus skills se omiten al inicio de la sesión con una advertencia que indica quién lo prohíbe.

Una identidad prohibida también puede ser una ruta local (para plugins instalados desde una carpeta local), además de las formas owner/repo y URL de git indicadas arriba.

Herencia y niveles

Los plugins no se declaran en un solo lugar. Además de tus propias instalaciones, los plugins pueden ser obligatorios, recomendados o prohibidos por tu repo y por el admin de tu organización. Cada origen es un nivel, y los niveles se ordenan por autoridad, de mayor a menor:

Enterprise — el manifiesto gestionado de toda la cuenta, configurado por un admin.
Org — un manifiesto gestionado a nivel de organización, por debajo de su cuenta (una org puede agregar a lo que declara su cuenta, pero no puede contradecirlo). Esto se aplica solo a las sesiones de Devin en la nube: la CLI se autentica a nivel de cuenta y no tiene contexto de org, así que los requisitos y las prohibiciones a nivel de org no se aplican a los usuarios de la CLI. Coloca todo lo que necesites hacer cumplir en la CLI en el manifiesto de Enterprise/cuenta.
Repo — los requiredPlugins / optionalPlugins / forbiddenPlugins en el .devin/config.json de un checkout, detectados al recorrer hacia arriba desde tu directorio de trabajo.
User — plugins que instalas tú mismo con devin plugins install.

Cada nivel declara las mismas tres listas, y dentro de un nivel se combinan con las mismas reglas de prioridad de deny y anulación propia que un único manifiesto. Lo que los niveles agregan, además, es una regla: prevalece la autoridad superior.

La autoridad superior prevalece

Un nivel inferior nunca puede volver a permitir lo que un nivel superior prohíbe.
Un nivel inferior nunca puede prohibir lo que un nivel superior exige; esa prohibición se ignora y el plugin igualmente se carga.

Así, un admin puede imponer un plugin que ningún repo ni usuario puede desactivar, y prohibir un plugin que ningún nivel inferior puede volver a habilitar.

Una lista de denegación solo se anula en su propio nivel

Como las listas de elementos permitidos no se aplican entre niveles, la única forma de hacer una excepción a una lista de denegación es en el mismo nivel en que se declaró. El forbiddenPlugins de un nivel solo se anula con los optionalPlugins (o requiredPlugins) de ese mismo manifiesto, nunca con una lista de un nivel inferior. Por ejemplo, un manifiesto gestionado a nivel Enterprise puede restringir la cuenta a un único plugin aprobado:

// Manifiesto gestionado a nivel empresarial
{
  "forbiddenPlugins": ["*"],
  "optionalPlugins": ["acme/approved"]
}

Esto significa “en toda la cuenta, permite solo acme/approved y prohíbe cualquier otro plugin.” Ninguna org, repo o usuario puede ampliar esa lista de permitidos, ni instalando un plugin ni agregándolo a optionalPlugins de un nivel inferior. La excepción también cubre solo las entradas que este manifiesto enumera directamente; las dependencias transitivas de un plugin requerido no están exentas, así que enuméralas explícitamente en un bloqueo.

Conflictos y dependencias

Si el mismo plugin tiene un requisito y una prohibición en el mismo nivel pero en manifiestos distintos (por ejemplo, dos plugins independientes instalados a nivel de usuario), prevalece la prohibición: una lista de permitidos solo exime las entradas de su propio manifiesto, así que no puede salvar un plugin que otro manifiesto prohíbe. (Dentro de un único manifiesto, sus propios requeridos/opcionales siguen exentos de sus propias prohibiciones, como arriba.)
Un plugin bloqueado por gobernanza falla de forma no crítica: al inicio de la sesión, sus skills se omiten con una advertencia que indica quién lo prohibió, en lugar de abortar la sesión.
Que otros plugins dependan de él no le concede ninguna exención. Un plugin incorporado solo como una dependencia transitiva sigue estando sujeto a toda prohibición que se le aplique, y hereda el nivel de autoridad más alto de cualquier plugin que lo requiera.

Primeros pasos

Integraciones del Editor

Extensibilidad

Enterprise

Referencia

Registro de cambios

Instalar un plugin

Administrar plugins

El manifiesto

Dependencias y gobernanza

`requiredPlugins`

`optionalPlugins`

`forbiddenPlugins`

Herencia y niveles

La autoridad superior prevalece

Una lista de denegación solo se anula en su propio nivel

Conflictos y dependencias

​Instalar un plugin

​Administrar plugins

​El manifiesto

​Dependencias y gobernanza

​requiredPlugins

​optionalPlugins

​forbiddenPlugins

​Herencia y niveles

​La autoridad superior prevalece

​Una lista de denegación solo se anula en su propio nivel

​Conflictos y dependencias

Instalar un plugin

Administrar plugins

El manifiesto

Dependencias y gobernanza

`requiredPlugins`

`optionalPlugins`

`forbiddenPlugins`

Herencia y niveles

La autoridad superior prevalece

Una lista de denegación solo se anula en su propio nivel

Conflictos y dependencias