Configura tu ecosistema 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.

Esta guía explica cómo poner en marcha tu propio ecosistema de plugins: un repo de plugins propiedad de tu organización, que se distribuye a cada sesión de Devin y a cada usuario de la CLI mediante un manifest administrado, con plugins obligatorios, opcionales y prohibidos como controles de gobernanza. Esta guía incluye dos repositorios de plantilla:

plugin-template — una plantilla inicial para crear un solo plugin (o un par de ellos).
team-marketplace-template — el patrón completo del ecosistema: un monorepo de plugins junto con un meta-plugin cuyo manifiesto define tu configuración base y tu política.

1. Crea tus plugins

Un plugin es un directorio con el manifiesto .devin-plugin/plugin.json; todo lo demás es opcional:

my-plugin/
├── .devin-plugin/
│   └── plugin.json     # name, version, dependency + policy lists
├── AGENTS.md           # always-on rule
├── rules/              # triggered rules
├── agents/<name>.md   # subagentes personalizados (solo CLI/Desktop por ahora); agents/<name>/AGENT.md también funciona
├── hooks.json          # lifecycle hooks
├── mcp_config.json     # MCP servers
└── skills/<name>/SKILL.md   # skills, exposed as /<plugin>:<skill>

Haz un fork de plugin-template para empezar y consulta la Referencia de plugins para la CLI para ver el formato completo. Mantén AGENTS.md breve — consume contexto en cada sesión para todas las personas que tengan el plugin.

2. Validar y probar localmente

Ambas plantillas incluyen un validador (node scripts/validate-template.mjs) y un flujo de trabajo de CI que lo ejecuta en cada PR. Para una prueba real, instala desde una carpeta local con Devin CLI:

devin plugins install ./plugins/my-plugin   # vinculado: los cambios se aplican en la próxima sesión
devin plugins list

3. Aloja todos en un solo repo

Coloca todos los plugins de tu organización en un único repo como subcarpetas (plugins/<name>/), cada uno con su propio origen git-subdir. El repo puede seguir siendo privado: las sesiones en la nube lo obtienen mediante tu integración con Git, y quienes usan la CLI lo obtienen con sus propias credenciales de git (así que también necesitan acceso al repo). Haz un fork de team-marketplace-template para usar esta estructura y actualiza las URL de git-subdir de su meta-plugin para que apunten a tu fork. En la plantilla, el meta-plugin está en la raíz del repo, así que el propio repo es la unidad instalable: especificar your-org/your-marketplace instala toda la configuración base.

4. Define tu configuración base con un meta-plugin

El patrón de meta-plugin convierte todo tu ecosistema en una única unidad instalable. Es un plugin con poco o ningún contenido propio: su manifiesto hace el trabajo. Colócalo en la raíz del repo para que el propio repo sea el meta-plugin:

// .devin-plugin/plugin.json (raíz del repositorio)
{
  "name": "team-starter-pack",
  "requiredPlugins": [
    // instalado automáticamente para todos, de forma recursiva
    { "source": "git-subdir", "url": "https://github.com/acme/plugins.git", "path": "plugins/engineering-baseline" },
    { "source": "git-subdir", "url": "https://github.com/acme/plugins.git", "path": "plugins/security-guardrails" }
  ],
  "optionalPlugins": [
    // aprobado, no instalado automáticamente; también una excepción a las restricciones de este manifiesto
    { "source": "git-subdir", "url": "https://github.com/acme/plugins.git", "path": "plugins/frontend-standards" }
  ],
  "forbiddenPlugins": [
    "untrusted-vendor/*"
  ]
}

5. Distribuir desde Settings → Marketplace

Un Admin agrega una entrada al manifest administrado en la página de Settings → Marketplace — consulta la guía del marketplace de plugins:

{
  "requiredPlugins": ["acme/plugins"]
}

Exigir el repo del marketplace instala su meta-plugin raíz, que incorpora recursivamente toda la configuración base. Todos los que estén dentro del ámbito reciben ahora la configuración base automáticamente. Elige el ámbito con cuidado:

El manifiesto de enterprise/cuenta se aplica a las sesiones en la nube y a los usuarios de la CLI que hayan iniciado sesión en la cuenta.
El manifiesto de organización se aplica solo a las sesiones en la nube — la CLI no tiene contexto de organización.

6. Gobernanza

Las tres listas conforman el lenguaje de políticas en todos los niveles (manifiestos gestionados, configuración del repo, manifiestos de plugins). Prevalece el nivel de autoridad más alto: enterprise/cuenta por encima de organización, organización por encima de repo y repo por encima de usuario; y un nivel inferior nunca puede volver a permitir lo que un nivel superior prohíbe, ni prohibir lo que exige. Para limitar una cuenta únicamente a un conjunto aprobado:

{
  "forbiddenPlugins": ["*"],
  "requiredPlugins": [
    "acme/plugins",
    { "source": "git-subdir", "url": "https://github.com/acme/plugins.git", "path": "plugins/engineering-baseline" },
    { "source": "git-subdir", "url": "https://github.com/acme/plugins.git", "path": "plugins/security-guardrails" }
  ],
  "optionalPlugins": [
    { "source": "git-subdir", "url": "https://github.com/acme/plugins.git", "path": "plugins/frontend-standards" }
  ]
}

Las propias entradas required/optional del manifiesto están exentas de su propia prohibición "*"; nada más lo está, y ningún nivel inferior puede ampliar esa excepción. La exención cubre solo las entradas listadas directamente — las dependencias transitivas de un plugin marcado como required no están exentas — así que, en un entorno bloqueado, lista explícitamente todo lo que incorpora el meta-plugin (aquí engineering-baseline y security-guardrails). Consulta las reglas de gobernanza para ver la semántica completa.

7. Evoluciona

Hacer merge en la rama predeterminada del repo de tu plugin es la versión: las sesiones nuevas lo recogen automáticamente — consulta cómo se implementan las actualizaciones.
Los equipos agregan plugins mediante una pull request (PR) al repo del marketplace; la CI de la plantilla valida la estructura en cada PR.
Los plugins de Claude existentes se instalan tal cual (Devin recurre a .claude-plugin/plugin.json), así que puedes respaldar plugins de la comunidad en optionalPlugins sin tener que incluirlos en el repositorio.

Limitaciones actuales

Los plugins se cargan en sesiones en la nube, en Devin CLI y en Devin Desktop (al usar Devin Local); no se aplican al agente Cascade clásico.
Subagentes (agents/<name>.md or agents/<name>/AGENT.md) se cargan solo en agentes locales de Devin (CLI y Devin Desktop), no en sesiones en la nube.
Hooks: las sesiones en la nube ejecutan hooks de command para todos los eventos excepto SessionStart y SessionEnd; los hooks de tipo prompt solo están disponibles en CLI/local.
MCP servido por plugins se carga dentro de la sesión, pero aún no aparece en la interfaz de Settings de MCP.
Los manifiestos a nivel de la organización no llegan a los usuarios de CLI; usa el manifiesto de enterprise/cuenta para aplicar la enforcement en CLI.

Más información

Marketplace de plugins — la parte de la aplicación web: manifiestos, ámbitos, cargas
Referencia de plugins para la CLI — formato de archivo, creación, instalaciones por usuario
Skills — los procedimientos de SKILL.md incluidos en los paquetes de plugins

Primeros pasos

Conceptos clave

Incorporación de Devin

Trabajar con Devin

Guías de producto

Integraciones

Admin

Notas de la versión

Configura tu ecosistema de plugins

1. Crea tus plugins

2. Validar y probar localmente

3. Aloja todos en un solo repo

4. Define tu configuración base con un meta-plugin

5. Distribuir desde Settings → Marketplace

6. Gobernanza

7. Evoluciona

Limitaciones actuales

Más información

​1. Crea tus plugins

​2. Validar y probar localmente

​3. Aloja todos en un solo repo

​4. Define tu configuración base con un meta-plugin

​5. Distribuir desde Settings → Marketplace

​6. Gobernanza

​7. Evoluciona

​Limitaciones actuales

​Más información

1. Crea tus plugins

2. Validar y probar localmente

3. Aloja todos en un solo repo

4. Define tu configuración base con un meta-plugin

5. Distribuir desde Settings → Marketplace

6. Gobernanza

7. Evoluciona

Limitaciones actuales

Más información