> ## Documentation Index
> Fetch the complete documentation index at: https://docs.devinenterprise.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Marketplace de plugins

> Instala y marca como obligatorios paquetes de skills para todos en tu org o Enterprise desde la aplicación web de Devin

<Note>
  Los plugins están en **beta cerrada**. Para solicitar acceso, contacta con [support@cognition.ai](mailto:support@cognition.ai). El comportamiento y la configuración pueden cambiar en futuras versiones.
</Note>

<div id="what-are-plugins">
  ## ¿Qué son los plugins?
</div>

Un **plugin** es un paquete de [skills](/es/product-guides/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](/es/cli/index) 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](#cloud-sessions-vs-the-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](/es/cli/extensibility/plugins/overview).

<div id="where-to-configure-them">
  ## Dónde configurarlos
</div>

Ve a [**Settings → Marketplace**](https://app.devin.ai/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**](https://app.devin.ai/settings/marketplace?tab=configuration) — 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**.

<div id="the-manifest">
  ## El manifiesto
</div>

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

```jsonc theme={null}
{
  "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.

<div id="governance-rules">
  ### Reglas de gobernanza
</div>

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.

<div id="adding-your-own-plugins">
  ## Agregar tus propios plugins
</div>

Un plugin es simplemente un directorio que contiene un manifiesto `.devin-plugin/plugin.json` y una carpeta `skills/` con [skills](/es/product-guides/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](/es/cli/extensibility/plugins/overview).
* **Hooks** — un `hooks.json` en la raíz del plugin registra [hooks del ciclo de vida](/es/cli/extensibility/hooks/lifecycle-hooks) 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](/es/work-with-devin/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](/es/cli/extensibility/plugins/overview) 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](/es/cli/extensibility/plugins/overview) 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](#using-a-private-skills-repo) 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`.

<div id="uploading-a-plugin-bundle">
  ### Subir un paquete de plugin
</div>

En la pestaña [**Configuración**](https://app.devin.ai/settings/marketplace?tab=configuration), 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).

<div id="using-a-private-skills-repo">
  ### Cómo usar un repo privado de skills
</div>

Haz que el manifiesto apunte directamente al repo privado; por lo general, no necesitas incorporarlo a tu [instantánea de Environment](/es/onboard-devin/environment/blueprints). 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.

<div id="how-updates-roll-out">
  ## Cómo se despliegan las actualizaciones
</div>

* 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.

<div id="compatibility">
  ## Compatibilidad
</div>

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.

<div id="scope-and-inheritance">
  ## Ámbito y herencia
</div>

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:

1. manifiesto de **Enterprise / account** (esta página)
2. manifiesto de **Org** (esta página)
3. configuración del plugin a nivel de **Repo** (el `.devin/config.json` de un repo)
4. plugins a nivel de **User** — las instalaciones propias de una persona desde el [CLI](/es/cli/extensibility/plugins/overview), 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](#governance-rules)).

<div id="cloud-sessions-vs-the-cli">
  ### Sesiones en la nube vs. la CLI
</div>

Tanto las sesiones de Devin en la nube como la [Devin CLI](/es/cli/index) 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.

<div id="learn-more">
  ## Más información
</div>

* [Skills](/es/product-guides/skills) — los procedimientos `SKILL.md` que vienen con los plugins
* [Referencia de plugins de la CLI](/es/cli/extensibility/plugins/overview) — formato de archivo del plugin, creación e instalación por usuario
* [Playbooks](/es/product-guides/creating-playbooks) — plantillas de prompt reutilizables asociadas a las sesiones