Plugins de Claude Code: Qué son y cómo usarlos

Un plugin de Claude Code es una carpeta que distribuye más de un tipo de extensión a la vez. Mientras que una habilidad es un único archivo SKILL.md que enseña a Claude un comportamiento, un plugin puede agrupar habilidades, subagentes, hooks, comandos slash y hasta un servidor MCP, e instalar todo con un solo comando. Es la diferencia entre darle a alguien una tarjeta de receta y darle una cocina equipada.

Anthropic añadió plugins a Claude Code a finales de 2025, y resolvieron un problema real: los equipos no instalaban una habilidad a la vez, sino que ensamblaban configuraciones. Una configuración de "ingeniero backend" podría necesitar una habilidad de depuración, un subagente de revisión de código, un hook de pre-commit y una conexión MCP de base de datos. Antes de los plugins, eso significaba cuatro instalaciones separadas y cuatro lugares para que la configuración se desincronizara. Un plugin lo convierte en uno solo.

Nosotros probamos y catalogamos habilidades de Claude en SkillProof, y los plugins son la siguiente capa superior a lo que solemos revisar: un formato de empaquetado, no un comportamiento. Esta guía cubre qué hay realmente dentro de un plugin, cómo funciona el sistema de marketplace y la misma pregunta de confianza que hemos estado haciendo sobre las habilidades desde que empezamos, ahora aplicada a algo con mucha más superficie.

Qué empaquetan realmente los plugins

Cuatro tipos de ingredientes pueden aparecer dentro de un solo plugin, y la mayoría de los plugins reales usan más de uno:

• Habilidades — instrucciones markdown que se cargan cuando una tarea coincide, el mismo formato cubierto en qué son las habilidades de Claude.
• Subagentes — instancias de Claude separadas con su propio prompt del sistema y ventana de contexto, útil para delegar una tarea ruidosa o paralela.
• Hooks — comandos shell que se ejecutan automáticamente en eventos como guardar un archivo, un commit o finalizar una llamada a una herramienta. Un hook de lint-al-guardar es el ejemplo clásico.
• Comandos slash — comandos personalizados como /deploy o /standup que ejecutan un prompt o script predefinido cuando un compañero de equipo los escribe.
• Servidores MCP — una conexión a una herramienta o fuente de datos externa, configurada una vez dentro del plugin en lugar de manualmente en cada proyecto.

Un plugin no necesita los cinco. Muchos distribuyen solo un par de habilidades, o un solo hook más el comando que lo activa. Lo que lo convierte en un plugin en lugar de una colección suelta de archivos es que se instala como una unidad, con un manifiesto que describe lo que hay dentro.

Plugins vs. habilidades: la analogía del paquete npm

La forma más limpia de pensar en esto: una habilidad es una función, un plugin es un paquete.

Una sola habilidad enseña a Claude un comportamiento, ya sea formatear notas de reuniones o auditar una página SEO. No tiene dependencias ni configuración más allá de su propio markdown. Eso es intencional: una habilidad escrita para cubrir varias tareas no relacionadas tiende a activarse de forma poco fiable en todas ellas, ya que su descripción no puede ser específica sobre ninguna en particular.

Un plugin es la unidad de distribución alrededor de ese comportamiento. En el mundo npm, una función no se distribuye sola; se distribuye dentro de un paquete con un package.json, un número de versión y quizás un par de otras funciones que pertenecen juntas. Un plugin cumple el mismo rol para Claude Code: es la cosa con un nombre, una versión, un autor y un manifiesto, y las habilidades, hooks y comandos dentro de él son las exportaciones.

Esta distinción importa por una razón práctica. Cuando algo falla, "el disparador de la habilidad es demasiado vago" y "el hook del plugin está ejecutando el comando shell incorrecto" son errores diferentes con soluciones diferentes. Culpar a todo el plugin por una mala habilidad dentro, o viceversa, es una pérdida de tiempo. Lee el manifiesto primero para ver qué se distribuyó realmente antes de diagnosticar nada.

También significa que las dos unidades se evalúan de manera diferente. Una habilidad vive o muere por la calidad del disparador y si su salida supera la de Claude por defecto. Un plugin vive o muere por si sus partes cooperan: ¿el hook se activa antes o después de que la habilidad necesite su salida, el comando llama a un servidor MCP que está realmente configurado, su instalación choca con algo que ya tienes?

Anatomía de un plugin

Cada plugin necesita un directorio .claude-plugin en su raíz que contenga plugin.json, el manifiesto. Todo lo demás (skills/, agents/, hooks/, commands/, .mcp.json) se sienta junto a él como carpetas simples que Claude Code busca por convención.

Aquí hay un plugin pequeño pero completo, anotado:

team-standards/
├── .claude-plugin/
│   └── plugin.json
├── skills/
│   └── code-review/
│       └── SKILL.md
├── hooks/
│   └── hooks.json
└── commands/
    └── deploy.md

// .claude-plugin/plugin.json
{
  "name": "team-standards",
  "version": "1.2.0",
  "description": "Nuestro hook de lint, habilidad de revisión y comando de deploy en una sola instalación.",
  "author": "platform-team"
}

El manifiesto es deliberadamente delgado. Identifica el plugin y su versión; no enumera cada archivo dentro, porque Claude Code descubre skills/, hooks/ y commands/ por los nombres de sus carpetas automáticamente.

// hooks/hooks.json
{
  "PreToolUse": [
    {
      "matcher": "Bash",
      "hooks": [{ "type": "command", "command": "./scripts/check-branch.sh" }]
    }
  ]
}

Este hook se activa antes de cualquier llamada a herramienta Bash y puede bloquearla, que es cómo un plugin impone algo como "nunca ejecutar comandos git destructivos en main" sin depender de que Claude recuerde verificar.

<!-- commands/deploy.md -->
---
description: Ejecutar nuestra lista de verificación de despliegue contra staging
---

Verificar que la rama no sea main, confirmar que las migraciones se han aplicado,
luego ejecutar `./deploy.sh staging`. Reportar el resumen del log de despliegue.

Escribir /deploy ejecuta exactamente esto, cada vez, redactado idénticamente para cada compañero de equipo que instale el plugin. Esa consistencia es todo el argumento: tres componentes, un número de versión, un comando de instalación, y la configuración local de nadie se desincroniza de la de los demás.

Un archivo separado, marketplace.json, no es parte del plugin en sí. Es el índice que un repositorio de marketplace publica para que Claude Code sepa qué plugins viven allí y de dónde obtener cada uno. El marketplace.json de un repositorio puede listar docenas de plugins no relacionados; piénsalo como el registro, con plugin.json como el paquete individual dentro de él.

Instalación desde marketplaces

Obtener un plugin en tu máquina son dos comandos. Primero, apunta Claude Code a un marketplace:

/plugin marketplace add anthropic/plugins

Esto lee el marketplace.json de ese repositorio y añade cada plugin que lista a lo que puedes explorar. Luego instala uno:

/plugin install code-standards@anthropic

La parte @anthropic especifica de qué marketplace tirar, ya que puedes tener varios añadidos a la vez y el mismo nombre de plugin podría teóricamente existir en más de uno. Claude Code descarga los archivos del plugin, registra sus habilidades y comandos, y conecta cualquier hook o servidor MCP que declare.

Aquí está la parte que debería sonar familiar si has leído algo más que hemos escrito: nadie revisa esto. Añadir un marketplace significa confiar en quien mantenga ese repositorio, e instalar un plugin de él significa confiar en cada archivo que el plugin trae, incluyendo hooks que ejecutan comandos shell y servidores MCP que obtienen acceso a la red. Este es exactamente el problema de confianza que hemos documentado para las habilidades, excepto que un plugin tiene más partes móviles, lo que significa más lugares para que algo malo se esconda. Una habilidad solo puede ser texto persuasivo cargado en contexto. Un plugin también puede ser un hook que se ejecuta en cada commit, ya estés mirando o no.

Nuestra lista de verificación de seguridad para habilidades se aplica aquí con una adición. Antes de instalar un plugin:

1. Lee el manifiesto y cada archivo al que hace referencia antes de ejecutar el comando de instalación, no después. Un plugin.json que afirma ser un "ayudante de despliegue" que también declara un servidor MCP apuntando a un dominio desconocido es una señal en la que vale la pena detenerse.
2. Fija la versión. Instala code-standards@1.2.0, no lo que latest resuelva la próxima semana. Un plugin que cambia su comportamiento de hook después de que ya lo has confiado es peor que uno que fue malo desde el principio, porque no estarás mirando.
3. Verifica qué hooks y comandos se distribuyen, específicamente. Los hooks se ejecutan automáticamente, sin que escribas nada, en eventos como llamadas a herramientas y guardado de archivos. Ese es el componente que más vale la pena leer en su totalidad, ya que es el que actúa sin un prompt tuyo en el momento.
4. Trata un servidor MCP incluido en un plugin como cualquier otro servidor MCP: obtiene acceso real a la red y a menudo credenciales reales. Incluirlo dentro de un plugin no lo hace más seguro, solo lo hace más fácil de instalar sin notar que está ahí.

Cubrimos el modelo de amenaza completo, incluyendo cómo se ve un hook o habilidad maliciosa en la práctica, en nuestra guía de seguridad de habilidades. Todo lo que allí se dice sobre tratar las instrucciones de terceros como una dependencia que no has auditado se aplica a los plugins, solo que con un radio de explosión más amplio.

Cuándo empaquetar la configuración de tu equipo como un plugin

La señal más clara de que estás listo para un plugin: has escrito las mismas instrucciones de configuración en un README, un pin de Slack y un documento de incorporación, y ya están desincronizadas en dos de los tres lugares.

Tomemos un caso concreto. Un equipo de plataforma quiere que la sesión de Claude Code de cada ingeniero aplique los mismos estándares: no commits directos a main, una pasada de revisión de código consistente antes de fusionar, y un despliegue con un solo comando a staging. Empaquetado por separado, es un hook que alguien tiene que recordar añadir a settings.json, una habilidad que alguien tiene que recordar instalar, y un comando del que alguien tiene que recordar que existe. Empaquetado como un plugin team-standards, es una línea:

/plugin install team-standards@our-org

y cada nuevo empleado obtiene el hook de protección de rama, la habilidad lista de verificación de revisión de código y el comando /deploy en un solo paso, versionado juntos para que una actualización del script de despliegue y una actualización de los criterios de revisión se distribuyan en la misma versión en lugar de separarse.

La señal inversa también importa: si tu configuración es una sola habilidad sin hooks, comandos o dependencia MCP, empaquetarla como un plugin añade un manifiesto y una lista de marketplace sin beneficio. Publícala como una habilidad por sí sola, como cubrimos en qué son las habilidades de Claude, y busca un plugin solo una vez que haya más de una parte móvil que mantener sincronizada. Si el servidor MCP es la parte complicada de tu configuración, nuestras notas sobre cómo construir uno se encuentran en MCP Builder, que vale la pena revisar antes de decidir si un plugin necesita su propio servidor en lugar de apuntar a uno que ya existe.

Nuestra propia guía de configuración de Claude Code de 30 minutos recorre la construcción de esta capa capa por capa para un individuo; un plugin de equipo es el mismo ejercicio de capas, solo que versionado y compartido en lugar de ensamblado manualmente en cada portátil.

El ecosistema en 2026, honestamente

Los plugins son jóvenes, y se nota. El formato de marketplace solo se estabilizó hace unos meses, lo que significa que la mayoría de los archivos marketplace.json en circulación se escribieron contra un borrador temprano de la especificación y no se han tocado desde entonces. La calidad de la documentación varía enormemente: algunos repositorios de plugins tienen un README claro con un historial de versiones, otros son un solo commit sin explicación de lo que realmente hace el hook incluido.

La fragmentación es el problema mayor. Dado que un plugin puede declarar sus propias habilidades en lugar de referenciar las que ya tienes instaladas, el mismo comportamiento se reinventa en una docena de plugins diferentes con una docena de barras de calidad diferentes. Hemos visto una habilidad de revisión de código incluida en tres plugins no relacionados, ninguno consciente de que los otros existen, cada uno escrito con un estándar diferente.

Eso produce la misma lotería de calidad que documentamos en las habilidades comunitarias en general: aproximadamente la mitad de lo que probamos falla en el primer intento, ya sea por un script de instalación que asume una estructura de directorios que el autor nunca verificó en una máquina limpia, o un hook que silenciosamente no hace nada porque fue escrito contra una versión anterior de la API de hooks. Un plugin no soluciona esa tasa de fallos. Simplemente agrupa más componentes que pueden fallar independientemente, y un plugin solo funciona si cada pieza dentro de él lo hace.

Nada de eso significa que debas saltarte los plugins. Significa aplicar el mismo escepticismo que aplicarías a cualquier dependencia: verifica quién la mantiene, verifica cuándo se actualizó por última vez y no instales algo con tres componentes cuando solo necesitas uno de ellos. El formato de empaquetado es genuinamente útil para mantener un equipo sincronizado. No es un sustituto de leer lo que estás instalando.

FAQ

¿Cuál es la diferencia entre un plugin de Claude Code y una habilidad?

Una habilidad es un comportamiento en un archivo markdown. Un plugin es una unidad de distribución que puede agrupar varias habilidades junto con subagentes, hooks, comandos slash y un servidor MCP, todo instalado junto con un comando y un número de versión. Las habilidades de cada plugin siguen siendo habilidades debajo; el plugin es solo el empaquetado a su alrededor.

¿Cómo instalo un plugin de Claude Code?

Primero añade el marketplace con /plugin marketplace add <repo>, luego instala un plugin específico de él con /plugin install <plugin-name>@<marketplace>. Fija una versión en lugar de instalar lo que el marketplace apunta actualmente como latest, para que una actualización no cambie silenciosamente un comportamiento que ya revisaste.

¿Son seguros de instalar los plugins de Claude Code?

Trátalos como tratarías cualquier dependencia de terceros, y con más cuidado que una habilidad simple, ya que un plugin también puede distribuir hooks que ejecutan comandos shell automáticamente y servidores MCP con acceso real a la red. Lee el manifiesto y cada archivo incluido antes de instalar, no después. Nuestra guía de seguridad de habilidades cubre el modelo de amenaza subyacente en detalle.

¿Puedo poner mi propio servidor MCP dentro de un plugin?

Sí. Un plugin puede declarar un .mcp.json que configura un servidor MCP como parte de la instalación, para que los compañeros de equipo obtengan la conexión configurada automáticamente en lugar de configurarla manualmente en cada proyecto. Si estás construyendo el servidor en sí en lugar de solo conectarlo, consulta MCP Builder para el lado de la construcción de eso.

¿Dónde encuentro plugins de Claude Code para instalar?

Anthropic mantiene un marketplace oficial, y los marketplaces comunitarios han crecido rápidamente desde que se lanzó el formato. La calidad varía tanto como lo hace en las habilidades comunitarias en general, así que verifica el manifiesto, verifica cuándo se actualizó por última vez, y prefiere plugins de mantenedores que documenten lo que realmente hay dentro antes de añadir su marketplace.