Configura tu ecosistema de plugins

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.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 --local ./plugins/my-plugin   # vinculado, solo en esta máquina: los cambios se aplican en la próxima sesión
devin plugins list

También puedes subir una carpeta de plugin o un .zip a tu ámbito personal desde Customize → Plugins y probarlo en una sesión en la nube.

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 Customize

Un admin instala el repo del marketplace desde Customize → Plugins → Add plugin → From repository en el ámbito de organización o enterprise; consulta la guía de Plugins. Con esto se agrega una entrada al manifest administrado de ese ámbito:

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

Requerir el repo del marketplace instala su meta-plugin raíz, que a su vez incorpora toda la configuración base de forma recursiva. Customize indexa entonces el ámbito y lista todos los plugins que incorporó, con sus skills, MCP, hooks y Rules. A partir de ese momento, todos los que estén dentro del ámbito reciben la configuración base automáticamente: en las sesiones en la nube, en el Devin CLI y en Devin Desktop. Elige el ámbito con criterio:

El manifest de enterprise llega a todas las organizaciones de la enterprise.
Un manifest de organización llega a las sesiones en la nube de esa organización y al CLI/Desktop de los miembros cuya organización principal sea esa.

Si la configuración base incluye servidores MCP que necesitan credenciales, completa la configuración en la pestaña MCPs después de la indexación. En los servidores OAuth con acceso de Organización, conecta una service account para que los miembros la compartan; con acceso Personal, cada miembro conecta su propia cuenta. Si falta contenido de la configuración base, sigue Resolver problemas de indexación.

6. Gobernanza

Las tres listas conforman el lenguaje de políticas en todos los niveles (manifiestos administrados, 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 dependencias y 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.
Actualmente, los hooks se ejecutan según el principio de mejor esfuerzo y fallo abierto: un hook que no se carga o no se ejecuta no detiene la sesión, así que aún no dependas de ellos para guardrails cruciales. Consulta la referencia de hooks de CLI para la configuración local.
La gobernanza falla en abierto: si no se puede obtener un manifest administrado al inicio de la sesión, los plugins de ese nivel no se instalan y sus prohibiciones no se aplican en esa sesión.
El contenido de plugins de un repo privado aparece en Customize solo para las organizaciones cuya integración con Git puede acceder al repo; en los demás casos se retiene hasta que se conceda acceso al repo en Settings → Repositories.

Más información

Guía de plugins — la parte de la aplicación web: Customize, ámbitos, indexación, MCP
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 Customize

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 Customize

​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 Customize

6. Gobernanza

7. Evoluciona

Limitaciones actuales

Más información