Plugins de Devin CLI

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 en la nube de Devin, 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>. Esta página cubre los plugins en la CLI; para la web app —la página Customize, los ámbitos de organización y enterprise, la indexación y las conexiones MCP— consulta la guía de Plugins. 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 en las sesiones locales de Devin (la CLI y Devin Desktop) en las que el plugin está instalado. Actualmente, los hooks del plugin funcionan con el mejor esfuerzo y con fallo abierto; si un hook no se carga o ejecuta, la sesión continúa sin él, así que aún no dependas de ellos para guardrails cruciales.
servidores MCP — los plugins pueden proporcionar servidores MCP opcionales que se inician con la sesión. Sus tools están disponibles para Devin. En la CLI, autentica el servidor OAuth de un plugin con devin mcp login; las sesiones en la nube usan la conexión realizada en la web app (consulta MCPs). 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. Referencia los secrets como ${NAME}; los valores literales escritos en la configuración se eliminan.

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; agrega #path/to/plugin cuando el plugin esté por debajo de la raíz del repositorio:

# Desde GitHub
devin plugins install acme/review-tools

# Un plugin en una subcarpeta de un repo
devin plugins install acme/plugins#plugins/review

# 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

# Solo en esta machine, sin sincronizar con tus plugins personales en Devin Cloud
devin plugins install --local ./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. De forma predeterminada, install registra el plugin en tu manifiesto personal en Devin Cloud, por lo que los mismos plugins se cargan en cada máquina en la que inicias sesión (y en tus sesiones en la nube). Usa --local para instalarlo solo en la máquina actual. Para gestionar plugins es necesario haber iniciado sesión (devin auth login); una empresa puede deshabilitar los plugins de la CLI para sus miembros, en cuyo caso los plugins instalados no se aplican.

Gestión de plugins

# Lista los plugins instalados, sus versiones y si alguno está bloqueado por una policy
devin plugins list

# Muestra las skills, hooks y rules de un plugin, y sus listas de required/optional/forbidden
devin plugins info review-tools

# Vuelve a descargar un plugin (o todos los plugins) en su última versión
devin plugins update review-tools
devin plugins update

# Elimina un plugin de tus plugins personales (los plugins requeridos que se instalaron automáticamente se mantienen)
devin plugins remove review-tools

# Elimina solo de esta máquina (falla con los plugins que están en tus plugins personales)
devin plugins remove review-tools --local

# Descarta los requisitos de plugins de repos que ya no están en disco y libera el contenido de plugins sin usar
devin plugins prune

remove --force elimina un plugin incluso si otro plugin o un manifiesto de gobernanza aún lo requiere; un plugin requerido por gobernanza se reinstala en la siguiente sesión dentro del ámbito que lo exige, y la CLI advierte qué configuración de enterprise, organización o repositorio sigue requiriéndolo. Los plugins de carpeta local se vinculan directamente a su carpeta de origen, por lo que las ediciones se reflejan al instante: devin plugins install --local ./my-plugin → edita skills/<name>/SKILL.md → los cambios se aplican en la siguiente sesión, sin necesidad de update. Si la CLI tiene el plugin pero Customize muestra contenido faltante o desactualizado, consulta Resolver problemas de indexación. devin plugins update actualiza el contenido local del plugin; Reindex plugins en Customize actualiza el listado web. Una instalación hecha con --local permanece en este dispositivo.

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
`{ "source": "github", "repo": "owner/repo", "sha": "3f2a9c1…" }`	fijado a un commit exacto: nunca cambia hasta que edites la entrada
`{ "source": "github", "repo": "owner/repo", "ref": "v2" }`	sigue una rama o etiqueta: se vuelve a resolver en cada actualización

sha y ref funcionan con todas las formas de objeto (github, url, git-subdir) y son mutuamente excluyentes: un sha fija la versión, un ref es flotante. Si no se indica ninguno, el origen sigue la rama predeterminada del repositorio. 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 administrado de toda la cuenta, configurado por un Enterprise Admin.
Org — un manifiesto administrado a nivel de organización, por debajo de su Enterprise (una org puede agregar a lo que declara su Enterprise, pero no puede contradecirlo). Las sesiones en la nube usan el manifiesto de la organización de la sesión; la CLI y Devin Desktop usan el manifiesto de tu organización principal.
Repo — los requiredPlugins / optionalPlugins / forbiddenPlugins en el .devin/config.json de un checkout, detectados al recorrer hacia arriba desde tu directorio de trabajo (en las sesiones en la nube, desde cada repositorio clonado).
User — plugins que instalas tú mismo con devin plugins install (sincronizados a través de tu manifiesto personal) o con --local en esta máquina.

La CLI obtiene los manifiestos de Enterprise, org y personal desde Devin Cloud cuando inicias sesión; los admins gestionan los dos primeros desde la web app (consulta la guía de Plugins). 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.
Un conflicto de pins (dos manifiestos que fijan el mismo plugin a distintos sha) debe resolverse alineando los pins o dejando el pin en manos del nivel con mayor autoridad.
Cuando no se puede obtener un manifiesto administrado al inicio de la sesión, ese nivel falla de forma abierta: no se instala nada de él y sus prohibiciones no se aplican en esa sesión.

Primeros pasos

Integraciones del Editor

Extensibilidad

Enterprise

Referencia

Registro de cambios

Plugins de Devin CLI

Formatos compatibles

Instalar un plugin

Gestión de 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

​Gestión de 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

Gestión de 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