Marketplace de 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.

¿Qué son los plugins?

Un plugin es un paquete de skills — y, opcionalmente, Rules, hooks y servidores MCP — empaquetados para poder instalarse y reutilizarse como una sola unidad. Mientras que una skill reside en un único repo, un plugin es un origen portátil (un repo de GitHub, una git URL, una subcarpeta de un repo o un archivo .zip subido) que puedes requerir en toda tu organización o Enterprise. Los plugins gestionados permiten que un Admin instale plugins de forma centralizada desde la aplicación web de Devin, para que se apliquen a todas las personas de la organización o Enterprise — sin configuración por usuario. Esto abarca las sesiones de Devin en la nube y a los usuarios de Devin CLI que hayan iniciado sesión en la cuenta (la configuración a nivel de Enterprise/cuenta también llega a la CLI; consulta sesiones en la nube vs. la CLI). Cuando se instala un plugin, sus skills pasan a estar disponibles automáticamente para Devin como comandos /<plugin>:<skill>. Esta página trata la parte de plugins en la nube (aplicación web). Para ver el formato de archivo del plugin y el flujo de instalación por usuario de la CLI, consulta la referencia de plugins de la CLI.

Dónde configurarlos

Ve a Settings → Marketplace. La página tiene dos pestañas:

Marketplace — explora plugins (el catálogo oficial de Devin, además de cualquier plugin que tu organización o Enterprise haya agregado) e instálalos. Instalar un plugin lo agrega al manifiesto del ámbito elegido como plugin obligatorio, por lo que se instala para todos en ese ámbito.
Configuración — edita el manifiesto del plugin en bruto como JSON y sube tu propio plugin como carpeta o archivo .zip (o crea uno en el editor).

El acceso está restringido por permisos:

Org admins (acceso a Organization Settings) gestionan el manifiesto de la org.
Enterprise admins (acceso a Settings de Enterprise) también gestionan el manifiesto compartido de Enterprise.

El manifiesto

El manifiesto es un único documento JSON con tres listas:

{
  "requiredPlugins": [
    // propietario/repo de GitHub
    "acme/review-tools",

    // cualquier git URL
    "https://gitlab.com/acme/secure-base.git",

    // forma de objeto
    { "source": "github", "repo": "acme/audit-logging" },

    // un plugin ubicado en una subcarpeta
    {
      "source": "git-subdir",
      "url": "https://github.com/acme/vendor-plugins.git",
      "path": "plugins/stripe"
    }
  ],

  "optionalPlugins": [],

  "forbiddenPlugins": [
    "sketchy-org/bad-plugin",
    "acme/*"
  ]
}

requiredPlugins — se instalan para todos en el ámbito (de forma recursiva, incluidos los plugins de los que dependan).
optionalPlugins — una lista de permitidos que autoriza plugins sin instalarlos automáticamente; se usa para crear excepciones a una entrada prohibida.
forbiddenPlugins — una lista de bloqueo de identidades de plugins o patrones glob (p. ej., acme/* o "*" para un bloqueo completo).

Cada entrada de requiredPlugins / optionalPlugins es un origen: ya sea 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. El manifiesto se almacena tal cual; el agente valida el origen completo en el momento de la instalación.

Reglas de gobernanza

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.

Además de estas reglas, los manifiestos gestionados están jerarquizados por niveles: Enterprise/cuenta está por encima de org, que a su vez está por encima de la configuración de plugins a nivel de repo y de usuario. Prevalece el nivel con mayor autoridad: un nivel inferior nunca puede prohibir un plugin que un nivel superior exige, ni volver a permitir uno que un nivel superior prohíbe. Por lo tanto, una prohibición a nivel de org no puede bloquear un plugin exigido por Enterprise, pero una prohibición de Enterprise prevalece sobre un requisito de org.

Agregar tus propios plugins

Un plugin es simplemente un directorio que contiene un manifiesto .devin-plugin/plugin.json y una carpeta skills/ con skills comunes:

my-plugin/
├── .devin-plugin/
│   └── plugin.json     # nombre, versión y listas de dependencias opcionales
├── AGENTS.md           # regla activa siempre opcional
├── rules/              # reglas opcionales con trigger
├── hooks.json          # hooks de ciclo de vida opcionales
├── mcp_config.json     # servidores MCP opcionales
└── skills/
    └── review/
        └── SKILL.md    # una skill ordinaria

Además de skills, un plugin puede incluir:

Rules — un AGENTS.md en la raíz del plugin se inyecta como una regla activa en cada sesión — tanto en las sesiones en la nube como en la CLI. Los archivos Markdown de una carpeta rules/ también se cargan, respetando su frontmatter trigger; consulta la referencia de plugins de la CLI.
Hooks — un hooks.json en la raíz del plugin registra hooks del ciclo de vida que se ejecutan en la sesión. Las sesiones en la nube ejecutan hooks command para todos los eventos excepto SessionStart y SessionEnd — así que PreToolUse, PostToolUse, PermissionRequest, UserPromptSubmit, Stop y PostCompaction funcionan; los hooks de tipo prompt solo funcionan en la CLI o en entornos locales.
servidor MCP — un mcp_config.json en la raíz del plugin declara servidores MCP ("mcpServers": { "<name>": { … } }) que se cargan en cada sesión donde el plugin está instalado. Todavía no aparecen en la UI de Settings de MCP, pero sus tools están disponibles para Devin. La configuración MCP de un plugin puede establecer un ID de cliente OAuth y scopes, pero nunca un client secret de OAuth: una configuración de servidor que incluya uno se rechaza al activarse.
subagente personalizado — perfiles agents/<name>.md (o agents/<name>/AGENT.md). Actualmente, estos solo se cargan en agentes locales de Devin — el Devin CLI y Devin Desktop — no en sesiones en la nube.

El plugin es la unidad de instalación: al instalarlo, se instalan todas sus skills (además de cualquier elemento de requiredPlugins) — no puedes instalar skills individuales de un plugin. Para ofrecer skills por separado, divídelas en plugins independientes. Consulta la referencia de plugins de la CLI para ver el formato completo de plugin.json y el flujo de creación local. Según dónde esté el plugin, agrégalo de una de estas maneras:

Dónde se encuentra	Cómo agregarlo
Repo de git público	Agrega `"owner/repo"` (o la git URL) al manifiesto, o instálalo desde la pestaña Marketplace si está en el catálogo
Repo de git privado	La misma entrada en el manifiesto — consulta cómo usar un repo privado de skills para ver cómo funciona la autenticación
Subcarpeta de un repo (p. ej., un monorepo de plugins)	`{ "source": "git-subdir", "url": "…", "path": "sub/dir" }` — cada subcarpeta es su propio plugin
No está en ningún repo	Súbelo como un paquete (abajo)

Un repo (o una subcarpeta git-subdir) es un plugin. Un solo repo puede alojar muchos plugins como subcarpetas, cada uno referenciado con su propia entrada git-subdir.

Subir un paquete de plugin

En la pestaña Configuración, la sección Plugin subido te permite subir un plugin como carpeta o archivo .zip, o compilar uno directamente en el editor. Al guardarlo, se agrega al manifiesto como plugin obligatorio (lo instala para todos en el ámbito); al eliminarlo, se quita la referencia. Esta es una buena opción para un plugin que no quieres alojar en un repositorio de Git (o no puedes hacerlo).

Cómo usar un repo privado de skills

Haz que el manifiesto apunte directamente al repo privado; por lo general, no necesitas incorporarlo a tu instantánea de Environment. Cualquier repo privado al que Devin ya pueda acceder mediante tu integración de Git se instala automáticamente. Usa el formato de git URL, o git-subdir para instalar un plugin desde una subcarpeta de un repo compartido. (Los usuarios de la CLI cubiertos por el mismo manifiesto lo obtienen con sus propias credenciales locales de git, así que también necesitarán acceso al repo). Si no se puede acceder al repo mediante tu integración de Git, súbelo como un paquete (arriba) o clónalo durante la configuración de Environment y haz referencia a él con una ruta local.

Cómo se despliegan las actualizaciones

Los cambios en el manifiesto (Settings → Marketplace) se aplican en la siguiente sesión.
Los cambios del plugin — cuando se fusionan en la rama que sigue el plugin, llegan automáticamente a las sesiones nuevas en unas horas. Fija el plugin a un SHA de commit para controlar tú mismo las actualizaciones; en la CLI, devin plugins update las actualiza de inmediato.
Las sesiones en curso conservan lo que cargaron al iniciarse; las actualizaciones nunca cambian una sesión a mitad de ejecución.

Compatibilidad

Los plugins de Claude también funcionan: si no hay .devin-plugin/plugin.json, Devin recurre a .claude-plugin/plugin.json. Cuando ambos manifiestos están presentes, prevalece el de Devin.

Ámbito y herencia

Los manifiestos gestionados pueden existir en hasta dos niveles:

Las cuentas independientes tienen un único manifiesto de account que se aplica a todos.
Las cuentas Enterprise tienen un manifiesto compartido de enterprise que hereda cada org subordinada, además de un manifiesto por org en una capa inferior. La vista del Marketplace muestra ambos, y los Admin de Enterprise pueden elegir instalar un plugin con ámbito enterprise (se aplica en todas partes), o un Admin de org puede instalarlo solo en su org.

Estos se sitúan en la parte superior de la jerarquía general de plugins, por encima de cualquier configuración de plugin por repo o por usuario:

manifiesto de Enterprise / account (esta página)
manifiesto de Org (esta página)
configuración del plugin a nivel de Repo (el .devin/config.json de un repo)
plugins a nivel de User — las instalaciones propias de una persona desde el CLI, que solo se aplican a su agente local de Devin y nunca se cargan en sesiones en la nube

Prevalece el nivel de mayor autoridad: un nivel inferior nunca puede permitir un plugin que un nivel superior prohíbe, ni prohibir uno que un nivel superior exige (consulta las reglas de gobernanza).

Sesiones en la nube vs. la CLI

Tanto las sesiones de Devin en la nube como la Devin CLI aplican el manifiesto de Enterprise/cuenta: se instalan los plugins obligatorios y también se aplican las restricciones a los usuarios de la CLI que hayan iniciado sesión en la cuenta. El manifiesto de la org se aplica solo a las sesiones en la nube. La CLI se autentica a nivel de cuenta y no tiene contexto de org, por lo que los requisitos y restricciones a nivel de org no se aplican a los usuarios de la CLI. Coloca en el manifiesto de Enterprise/cuenta todo lo que debas aplicar en la CLI (o en toda la cuenta), y usa el manifiesto de org para adiciones específicas de la org en las sesiones en la nube.

Más información

Skills — los procedimientos SKILL.md que vienen con los plugins
Referencia de plugins de la CLI — formato de archivo del plugin, creación e instalación por usuario
Playbooks — plantillas de prompt reutilizables asociadas a las sesiones

Primeros pasos

Conceptos clave

Incorporación de Devin

Trabajar con Devin

Guías de producto

Integraciones

Admin

Notas de la versión

Marketplace de plugins

¿Qué son los plugins?

Dónde configurarlos

El manifiesto

Reglas de gobernanza

Agregar tus propios plugins

Subir un paquete de plugin

Cómo usar un repo privado de skills

Cómo se despliegan las actualizaciones

Compatibilidad

Ámbito y herencia

Sesiones en la nube vs. la CLI

Más información

​¿Qué son los plugins?

​Dónde configurarlos

​El manifiesto

​Reglas de gobernanza

​Agregar tus propios plugins

​Subir un paquete de plugin

​Cómo usar un repo privado de skills

​Cómo se despliegan las actualizaciones

​Compatibilidad

​Ámbito y herencia

​Sesiones en la nube vs. la CLI

​Más información

¿Qué son los plugins?

Dónde configurarlos

El manifiesto

Reglas de gobernanza

Agregar tus propios plugins

Subir un paquete de plugin

Cómo usar un repo privado de skills

Cómo se despliegan las actualizaciones

Compatibilidad

Ámbito y herencia

Sesiones en la nube vs. la CLI

Más información