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 y Rules, Hooks, servidores MCP o subagentes personalizados opcionales que puedes instalar desde un repo de GitHub, una URL de git, una subcarpeta de un repo o una carpeta local. Los plugins funcionan en las sesiones de Devin en la nube, Devin CLI y Devin Desktop, sujetos a las limitaciones específicas de cada superficie que se describen a continuación. Al instalar un plugin, sus skills pasan a estar disponibles como comandos de barra diagonal /<plugin>:<skill>. El plugin es la unidad de instalación. Al instalar un plugin, se instalan todas sus skills y sus requiredPlugins; no puedes instalar skills individuales desde un plugin. Para ofrecer skills por separado, divídelas en plugins independientes. 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.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. Un repo (o una subcarpeta git-subdir) es un plugin. Un único repo puede alojar muchos plugins como subcarpetas, cada uno referenciado con su propio origen git-subdir. 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. En las sesiones en la nube, los hooks de command se ejecutan en la máquina de la sesión y solo se activan mientras esa máquina está en funcionamiento. Admiten todos los eventos excepto SessionStart y SessionEnd, incluidos PreToolUse, PostToolUse, PermissionRequest, UserPromptSubmit, Stop y PostCompaction; los hooks de tipo prompt solo están disponibles en la CLI o en entornos locales.
servidores MCP — los plugins pueden proporcionar servidores MCP opcionales que se inician con la sesión. Sus tools están disponibles para Devin, aunque los servidores MCP del plugin aún no aparecen en la UI de Settings de MCP. Una configuración MCP de plugin puede establecer un ID de cliente OAuth y scopes, pero nunca un client secret: una configuración de servidor que incluya uno se rechaza durante la activación.

Formatos compatibles

El diseño anterior corresponde al formato de plugin propio de Devin. Devin también carga plugins empaquetados en otros dos diseños, con la siguiente precedencia de manifiestos: .devin-plugin/plugin.json > .claude-plugin/plugin.json > plugin.json en la raíz:

Plugins de Claude — si no existe .devin-plugin/plugin.json, Devin recurre a .claude-plugin/plugin.json. Se respetan el archivo .mcp.json en la raíz de los plugins de Claude y el campo mcpServers del manifiesto, y ${CLAUDE_PLUGIN_ROOT} en las configuraciones de servidor se expande a la raíz del plugin.
Plugins de Agent — también se cargan los plugins empaquetados conforme a la especificación abierta Agent Plugins 1.0.0 (un manifiesto plugin.json en la raíz del plugin, servidores MCP en un mcp.json en la raíz y skills en skills/). Para estos plugins, el archivo mcp.json de la raíz se lee como un origen MCP convencional (después de .mcp.json, que prevalece si hay un conflicto de nombres de servidor); los plugins heredados con diseño de Devin/Claude nunca lo leen, a menos que su manifiesto lo declare explícitamente. Las entradas MCP pueden declarar su transporte con el campo type de la especificación (stdio, streamable-http o sse) en lugar de transport, y ${PLUGIN_ROOT} en las configuraciones de servidor se expande a la raíz del plugin, al igual que ${CLAUDE_PLUGIN_ROOT}. Se muestra una advertencia si la versión de $schema no se reconoce, pero el plugin se sigue cargando en la medida de lo posible. Los servidores MCP de Agent Plugins también adoptan las convenciones de runtime de la especificación (estas se aplican solo a los plugins cuyo manifiesto es el plugin.json de la raíz; los diseños de Devin y Claude se comportan exactamente como antes):
- ${PLUGIN_DATA} en args, los valores de env y cwd se expande a un directorio de datos persistente y con permisos de escritura para cada plugin. El directorio se identifica mediante la identidad del plugin —no por su versión—, por lo que su contenido se conserva tras las actualizaciones del plugin y se elimina cuando se desinstala.
- Los procesos de servidor stdio reciben las variables de entorno PLUGIN_ROOT y PLUGIN_DATA junto con cualquier variable de env que establezca la configuración.
- Un servidor puede establecer cwd (relativo a la raíz del plugin); de forma predeterminada, es la raíz del plugin. Un command con el prefijo ./ se resuelve con respecto a la raíz del plugin, por lo que los plugins pueden incluir sus propios ejecutables. Ambos se validan para que permanezcan dentro de la raíz del plugin o del directorio de datos.

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.

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>:…). Los nombres constan de caracteres alfanuméricos en minúscula, separados por un único - o . (p. ej., 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/*", "*"]
}

Metadatos

name, version, description, author ({ name, email }), homepage, repository, license y keywords. Solo name se utiliza para la identidad y el espacio de nombres del plugin; el resto son descriptivos y se muestran mediante devin plugins info.

Skills & Rules

El campo skills controla desde dónde se cargan las skills y sustituye el directorio skills/ predeterminado. Acepta una única ruta relativa a la raíz del plugin o un array de rutas:

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

Un array vacío ("skills": []) desactiva por completo la carga de skills. Las rutas deben permanecer dentro del plugin: se rechazan las rutas absolutas, ~ y los recorridos con .., y una entrada no válida hace que falle todo el manifiesto. Las Rules se cargan de forma independiente de las skills: un archivo AGENTS.md en la raíz del plugin está activo, y los archivos Markdown del directorio rules/ se cargan como Rules activadas por desencadenantes. Consulta Rules para conocer los detalles de activación.

Servidores MCP

El campo mcpServers agrega declaraciones de servidores MCP. Los plugins también pueden usar el archivo raíz convencional .mcp.json (y mcp.json para los plugins que usan la estructura de manifiesto raíz de Agent Plugins). Se aceptan cuatro formatos:

// Un solo archivo de declaración
{ "mcpServers": "config/mcp.json" }

// Varios, leídos en el orden indicado
{ "mcpServers": ["config/mcp.json", "config/extra.json"] }

// Solo estos archivos: anula la convención root .mcp.json / mcp.json
{ "mcpServers": { "paths": ["config/mcp.json"], "exclusive": true } }

// Mapa de servers inline (anula la convención root si no está vacío)
{ "mcpServers": { "linear": { "command": "npx", "args": ["-y", "linear-mcp"] } } }

Las rutas declaradas siguen las mismas reglas de contención que las skills, pero las entradas no seguras se descartan en lugar de hacer que falle el plugin. Un campo mcpServers no válido solo desactiva la carga de MCP y permite seguir usando las skills, Rules y hooks. Un array vacío no agrega archivos de declaración, pero no suprime la convención de raíz. Del mismo modo, un mapa inline vacío mantiene habilitada la convención de raíz. Cuando el mismo nombre de servidor aparece en más de un origen, prevalece el primero.

Dependencias

Una entrada de dependencia es un origen: una abreviatura de cadena 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. 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 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

Formatos compatibles

Instalar un plugin

Administrar plugins

Manifiesto

Metadatos

Skills & Rules

Servidores MCP

Dependencias

`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

​Formatos compatibles

​Instalar un plugin

​Administrar plugins

​Manifiesto

​Metadatos

​Skills & Rules

​Servidores MCP

​Dependencias

​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

Formatos compatibles

Instalar un plugin

Administrar plugins

Manifiesto

Metadatos

Skills & Rules

Servidores MCP

Dependencias

`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