Plugins (Complementos): Empaquetando configuraciones de un tirón

📚 Navegación de la serie: En el artículo anterior 23 Subagentes (Subagents) aprendiste a crear un ayudante especializado con tus propias manos. ¿Pero te has dado cuenta de un problema? Todos estos subagentes, comandos, skills y hooks son piezas sueltas que hay que "configurar una a una". En este artículo aprenderás a empaquetarlos en un plugin (complemento): se instala y desinstala con un clic, e incluso puedes descargar paquetes listos para usar directamente desde el "mercado de plugins".

Amigos, hoy vamos a hablar de cómo empaquetar un montón de configuraciones sueltas. Dime si alguna vez te ha pasado esto: te has esforzado en configurar un entorno perfecto con "subagente + hook + MCP" para tu equipo, y llega un colega nuevo. Te pasas media hora explicándole: "Este archivo va en agents/, ese hook lo añades en settings.json, y ah, ¡no te olvides de .mcp.json!". Y después de todo, resulta que se dejó algo sin copiar y su entorno no funciona igual que el tuyo. No es culpa de nadie, así es la gestión de piezas sueltas: cuanto más dispersa es la configuración, más fácil es equivocarse al comunicarla verbalmente.

Fíjate en todo lo que hemos acumulado en los artículos anteriores: en el 18 escribimos CLAUDE.md, en el 22 configuramos un servidor MCP, en el 23 creamos un subagente, y por en medio introdujimos skills y hooks. Cada cosa por separado es genial, pero están dispersas: los subagentes en agents/, los hooks en settings.json, el MCP en .mcp.json... repartidos por varios archivos.

El problema viene cuando: has configurado todo esto con esfuerzo en el Proyecto A y quieres usarlo en el Proyecto B; te toca copiar y pegar archivo por archivo. O si quieres compartirlo con un colega, tienes que explicarle la estructura de directorios de palabra, y es fácil dejarse algo. Gestionar piezas sueltas es agotador y propenso a errores.

Para decirlo claramente, los plugins son la respuesta oficial de Claude Code a este problema: Empaquetar commands, subagents, skills, hooks y servidores MCP sueltos en un único paquete que se puede distribuir, iniciar y detener como un todo. En este artículo aclararemos "qué es un plugin, cómo descargarlos listos para usar del mercado y cómo gestionarlos".

Al terminar este artículo, sabrás:

• Qué incluyen exactamente los plugins, y cómo elegir entre ellos y las "configuraciones sueltas" (explicado en una tabla).
• La lógica de dos pasos del "mercado de plugins (marketplace)": primero añadir el mercado, luego instalar el plugin. (Con los comandos exactos).
• Cómo instalar tú mismo un plugin desde el mercado de demostración oficial y ejecutar los comandos que trae, con los resultados esperados.
• Cómo es la estructura de directorios de un plugin (plugin.json + carpetas de componentes), por si quieres empaquetar el tuyo.
• La "prueba de confianza" que debes pasar antes de instalar plugins de terceros. ¡No asumas que un plugin desconocido es inofensivo!

---

01 Primero lo primero: ¿Qué es exactamente un plugin?

Vamos a dar la conclusión primero: Un plugin es un "directorio autónomo" que agrupa las extensiones que has aprendido antes (skill, subagente, hook, comando, servidor MCP), y que se puede instalar, detener o distribuir como un todo.

¿Por qué lo necesitas? Porque la configuración suelta tiene tres grandes inconvenientes: es difícil de reutilizar en otros proyectos, es tedioso compartirla con el equipo, y no hay forma de hacer seguimiento de versiones (actualizaciones). Si configuras un subagente y un hook en un proyecto y quieres llevarlos a otro, solo te queda copiar y pegar; si quieres pasárselo a un colega, tienes que explicarle cada archivo. Un plugin soluciona esto metiendo todo ese conjunto "en una caja", y esa caja entera te la llevas y se la pasas a los demás.

Analogía: Las tiendas de extensiones del navegador. Si quieres añadir bloqueo de anuncios, traducción y captura de pantalla a Chrome, no necesitas escribir código o modificar configuraciones a mano; vas a la tienda, haces clic en "instalar" y tienes toda la funcionalidad de golpe. Si ya no lo quieres, le das a "quitar" y se desinstala limpiamente. Los plugins de Claude Code siguen la misma filosofía: entrar al mercado e instalar un conjunto completo de funcionalidades de un clic, sin tener que configurarlas manualmente una por una. Transforma las extensiones dispersas en varios archivos en un solo ítem de la tienda.

La documentación oficial explica muy bien la elección entre "plugins" y "configuraciones sueltas", aquí te lo resumo en una tabla:

Dimensión	Configuración suelta (directorio .claude/)	Plugin (plugin)
Ideal para	Uso propio en un proyecto, flujo de trabajo personal, pruebas rápidas	Compartir con equipo/comunidad, reutilización entre proyectos, publicación con versiones
Cómo compartir	Copiando archivos a mano	A través del mercado, con /plugin install
Nombre de los skills	Corto, ej: /hello	Con espacio de nombres, ej: /my-plugin:hello
Control de versiones	No tiene, si cambias algo el usuario no se entera	Sí, al definir una versión los usuarios reciben actualizaciones

La lógica detrás de esta tabla se resume en una frase: Para uso propio y rápido en un proyecto, la configuración suelta basta; para compartir, reutilizar en otros proyectos o poder actualizar, usa plugins. La recomendación oficial también es "empezar iterando rápido con configuraciones sueltas en .claude/ y, cuando esté listo para compartir, convertirlo a plugin". No te compliques creando un plugin para algo que solo vas a usar una vez.

Aquí hay un detalle en el que los novatos suelen confundirse, y es importante aclararlo ya: Los skills dentro de un plugin siempre llevan un "espacio de nombres (namespace)". Si escribes un skill llamado hello dentro de un plugin llamado my-plugin, para invocarlo no escribirás /hello, sino /my-plugin:hello.

💡 Resumen en una frase: Un plugin es una caja que empaqueta skills, subagentes, hooks, comandos y servidores MCP para instalarlos/desinstalarlos de una vez; para uso propio basta lo suelto, para compartir, reutilizar y actualizar se empaqueta en plugin.

---

02 ¿Por qué empaquetarlo es mejor que dejarlo suelto?

En la sección anterior vimos "qué es", ahora veamos "por qué merece la pena". Porque puede que, con solo la teoría, pienses: "tampoco me cuesta tanto copiar un par de archivos a mano".

La verdadera diferencia está en tres áreas; con ejemplos concretos lo entenderás a la primera.

Primero, reutilización entre proyectos. Imagina que tienes configurado un "flujo de trabajo de git": un skill que genera mensajes de commit estandarizados, y un hook que ejecuta un linter automáticamente antes de hacer commit. Al principio lo tenías suelto, y al empezar un proyecto nuevo tenías que copiar lo de la carpeta skills/ y la sección del hook de settings.json. Si por casualidad te olvidabas de copiar la parte del hook, el proyecto nuevo haría commits sin pasar el linter y podrían colarse errores. Al empaquetarlo como plugin, un simple /plugin install en el proyecto nuevo lo deja todo listo y sin errores.

Segundo, compartir en equipo. Compartir configuración suelta con colegas implica decirles: "Copia esta carpeta y ponla en .claude/agents/, y asegúrate de pegar esto otro en el settings". Nueve de cada diez veces se equivocan en algo. Con un plugin es distinto: lo subes a un mercado (incluso a un repositorio privado de tu empresa), y tu compañero solo necesita un comando para instalarlo, asegurando una configuración idéntica. Se acabaron los "en mi máquina sí funciona".

Tercero, actualizaciones. Este es el mayor punto ciego de la configuración suelta. Si modificas algo, los que lo están usando ni se enteran; tienes que avisarles a mano. Los plugins pueden llevar un número de versión, y si publicas una nueva versión, los usuarios la obtendrán al actualizar. Oficialmente, existe la "actualización automática": los plugins del mercado oficial lo hacen por defecto, mientras que los de terceros vienen desactivados por defecto (una decisión sensata: aceptas actualizaciones de los tuyos sin preguntar, pero las de desconocidos mejor confirmarlas manualmente).

Analogía: Las apps del móvil y sus tiendas de aplicaciones. Si una app que tienes instalada saca una nueva versión, la tienda te notifica que "hay actualizaciones" y tú le das a un botón para actualizar, sin tener que descargar e instalar de nuevo el paquete. Los plugins y su mercado funcionan igual: la instalación es de un clic, y las actualizaciones fluyen desde el mercado, sin necesidad de copiarlas tú a mano.

Veamos la diferencia entre configuración suelta y plugins en estas tres situaciones:

Lo que quieres hacer	❌ Configuración suelta	✅ Plugin
Llevarlo a otro proyecto	Copiar archivo por archivo, riesgo de olvidar algo	Ejecutar /plugin install
Compartir con colegas	Explicarles verbalmente dónde va cada cosa	Subirlo al mercado, se instala con un comando
Notificar actualizaciones	Imposible, solo avisando boca a boca	Mediante versiones, actualización automática/manual

Para ser honesto, si trabajas solo y en un único proyecto, no notarás tanto los beneficios del plugin; pero en cuanto haya más personas o más proyectos, la configuración suelta se vuelve una carga. Yo mismo no me pasé a los plugins hasta que me tocó liderar un equipo: para configurar el entorno a los nuevos, me pasaba la mañana diciéndoles "esto va en agents/, esto otro en el settings", y aun así siempre faltaba algo; desde que lo metí en un plugin en nuestro repositorio interno, el nuevo ejecuta un comando y tiene la configuración exacta que yo, cero problemas de "en mi máquina sí que va".

💡 Resumen en una frase: El verdadero valor de los plugins brilla con el "tamaño": reutilizar entre proyectos, compartir con el equipo y hacer actualizaciones. Hacerlo de forma suelta depende de trabajo manual, mientras que con plugins es un solo comando; a más gente y proyectos, mayor es la diferencia.

---

03 Mercado de plugins: Primero añade la "tienda", luego la "app"

Ahora que sabes qué es un plugin, la siguiente pregunta es: ¿Dónde consigo los plugins que otros han hecho? La respuesta es el "mercado de plugins" (marketplace).

Aquí hay un concepto crítico en el que los novatos suelen atascarse: usar el mercado consta de "dos pasos", no de uno.

• Paso 1: Añadir el mercado. Es como "registrar" el mercado en Claude Code para que sepa qué plugins hay ahí. Atención: en este paso no se instala ningún plugin, solo te da acceso a ver la estantería.
• Paso 2: Instalar el plugin. Echas un vistazo a la estantería y eliges lo que quieres instalar individualmente.

Analogía: Añadir una "tienda de apps" extra en tu teléfono. Aparte de la tienda oficial de tu móvil, puedes instalar otras tiendas alternativas. Pero "instalar esa nueva tienda" no significa que automáticamente hayas "instalado todas sus apps". La tienda solo te permite entrar y mirar qué hay; si quieres una app específica, tendrás que entrar y descargarla. El mercado de plugins es esa "tienda": añadirlo te deja ver qué hay, instalar un plugin es otra cosa.

Si entiendes estos "dos pasos", los comandos te resultarán lógicos. Veamos primero cómo añadir un mercado; la fuente más común es GitHub:

/plugin marketplace add owner/repo

Solo tienes que cambiar owner/repo por el nombre real del repositorio de GitHub (por ejemplo, el de demostración oficial es anthropics/claude-code). Aparte de GitHub, puedes añadir mercados desde URLs de Git (como GitLab, Bitbucket, o servidores privados), rutas locales o URLs remotas; la documentación tiene la lista completa, pero con GitHub te bastará al principio.

Una vez añadido el mercado, para instalar un plugin se usa esto:

/plugin install nombre-plugin@nombre-mercado

Lo que va después del @ es el nombre del mercado, lo que significa "instala este plugin desde este mercado". Por ejemplo, para instalar la integración de GitHub desde el mercado oficial:

/plugin install github@claude-plugins-official

Hay que hacer una mención especial al mercado que viene de serie: claude-plugins-official. No necesitas añadirlo a mano: está ahí desde que inicias Claude Code. Contiene una selección de plugins elegidos por Anthropic (integraciones con GitHub, GitLab, Slack, Figma, Sentry, herramientas de código LSP, plugins de seguridad, etc.). Si quieres instalar un plugin oficial, te saltas el "Paso 1" (añadir mercado) y directamente usas install.

💡 Resumen en una frase: Usar el mercado siempre son "dos pasos": primero /plugin marketplace add para añadir la estantería, luego /plugin install xxx@mercado para instalar el plugin en sí. La única excepción es el mercado oficial claude-plugins-official, que ya viene incluido y listo para instalar.

---

04 Los tres mercados: ¿Para qué sirve cada uno?

En la sección anterior mencionamos varios nombres de mercados y es fácil confundirse. Ahora vamos a aclarar los tres mercados que mantiene oficialmente Anthropic.

Analogía: Tres tipos de tiendas en la misma ciudad. Tienes la "Tienda Insignia" de la marca (solo con productos oficiales y de alta calidad), el "Gran Centro Comercial" (donde otros pueden vender sus productos, pero pasando un control de calidad), y la "Sala de Exposiciones" (solo para mostrar muestras de lo que se puede hacer). En Claude Code, los tres mercados oficiales son exactamente así:

Mercado	Comando para añadirlo	Enfoque	Contenido
claude-plugins-official (Oficial)	Ya viene, no hace falta añadirlo	Selección oficial	Plugins escogidos por Anthropic, los más estables
claude-community (Comunidad)	/plugin marketplace add anthropics/claude-plugins-community	Aportes de terceros con revisión automática	Plugins de la comunidad, bloqueados a un commit específico
claude-code-plugins (Demostración)	/plugin marketplace add anthropics/claude-code	Ejemplos oficiales	Plantillas y ejemplos para ver qué se puede hacer

Aclaraciones importantes:

El mercado oficial es el más estable pero no es abierto. Anthropic decide qué entra ahí, así que todo está seleccionado y tiene la menor probabilidad de dar problemas. Tus necesidades más comunes (integración con GitHub, LSPs para lenguajes, revisiones de seguridad) suelen estar aquí.

El mercado de la comunidad es abierto, pero con filtros. Para que un plugin de un tercero entre ahí, tiene que pasar las validaciones automáticas y los filtros de seguridad de Anthropic. Además, cada plugin se fija a un commit concreto, lo que significa que siempre instalarás la versión que fue revisada; el autor no puede cambiar el contenido a escondidas. Hay que añadirlo a mano y usar claude-community al instalar.

El mercado de demostración es para aprender. Solo tiene ejemplos de lo que el sistema de plugins es capaz de hacer (como el que usaremos en la práctica de la sección 06). También hay que añadirlo a mano.

Orden recomendado para buscar plugins: Mira primero en el mercado oficial; si no lo encuentras, busca en el de la comunidad (y lee su descripción y permisos antes de instalar). Usa el mercado de demostración solo para probar y aprender; no están pensados para uso diario en producción.

💡 Resumen en una frase: El mercado oficial ya viene incluido y es el más fiable, el de la comunidad hay que añadirlo y ha pasado controles, y el de demostración es para aprender; busca siempre en el oficial primero, luego en el de la comunidad, y usa los ejemplos solo para practicar.

---

05 ¿Qué estás instalando exactamente con un plugin?

Cuando ejecutas /plugin install, ¿qué entra realmente en tu entorno? Vamos a dejarlo claro para que no te preguntes "¿y ahora qué hago?" tras instalar uno.

Un plugin puede traer estos tipos de componentes, y la "forma de activarlos" varía según el tipo, esto es clave:

Componente	Cómo se usa una vez instalado
Skills / Commands	Se convierten en comandos con espacio de nombres (ej: /plugin:skill), puedes escribirlos tú o Claude los usará
Subagents	Aparecen en tu lista de /agents; Claude los asignará a tareas, o los puedes invocar tú
Hooks	Se ejecutan solos cuando toca (ej: después de modificar un archivo), no tienes que hacer nada
Servidores MCP	Se inician solos, y sus herramientas se añaden a las de Claude automáticamente
Servidores LSP	Le dan a Claude inteligencia sobre tu código (ir a definición, buscar referencias, errores), requieren instalar el binario del lenguaje

Como ves, algunos los invocas "tú" (skills/comandos) y otros actúan "solos" (hooks/MCP/LSP). Así que, después de instalar un plugin, tienes que saber qué trae para saber cómo aprovecharlo.

La buena noticia es que la versión actual de Claude Code te muestra todo esto antes de instalar. En el menú de /plugin, al seleccionar los detalles de un plugin, verás una sección de "Se instalará" que enumera comandos, agentes, skills, hooks, y servidores MCP y LSP. También te da un cálculo del "Costo de contexto": te avisa de cuántos tokens adicionales consumirá este plugin en tu ventana de contexto en cada turno.

Tengo que hacer hincapié en el "Costo de contexto", es crucial. Recuerda lo que vimos en el artículo 19 sobre la gestión del contexto: cada componente de un plugin ocupará espacio en tu "mesa de trabajo". Si instalas muchos plugins, antes de empezar a trabajar ya tendrás la ventana medio llena con definiciones de herramientas y skills. Mira siempre este número antes de instalar; si son unos cientos de tokens no pasa nada, pero si son miles, plantéate seriamente si vas a usar ese plugin. Instalar plugins inútiles y malgastar contexto es un error de principiante.

Un último detalle: después de instalar un plugin, recuerda ejecutar /reload-plugins para que se aplique, no hace falta reiniciar Claude Code. Cualquier cambio (instalar, detener, activar) en medio de la sesión requiere este comando para surtir efecto:

/reload-plugins

Tras ejecutarlo te dirá cuántos plugins, skills, agentes, hooks y servidores (MCP y LSP) están cargados actualmente.

💡 Resumen en una frase: Los componentes de un plugin se dividen en los que invocas tú (skills/comandos) y los que actúan solos (hooks/MCP/LSP); antes de instalar revisa qué trae y cuánto contexto gasta; tras instalar usa /reload-plugins para activarlo.

Esta imagen une las dos ideas principales de este artículo: a la izquierda, el proceso de dos pasos de "Añadir mercado → Instalar plugin", y a la derecha, la caja del plugin con sus cinco tipos de componentes (skill, subagente, hook, MCP, LSP) y cómo se activan (invocación manual o automática).

---

06 Práctica: Añade un mercado, instala un plugin y pruébalo

La teoría sin práctica no sirve de mucho. Ahora te guiaré para que añadas el mercado de demostración, instales un plugin real, y ejecutes sus comandos, todo con los resultados que deberías esperar. Instalaremos commit-commands, un plugin que añade un flujo de trabajo para git, mencionado en la documentación oficial.

Paso 1: Inicia Claude Code y añade el mercado de demostración

Abre Claude Code en cualquier directorio:

claude

Una vez dentro, teclea esto (este es el primer paso: añadir el mercado):

/plugin marketplace add anthropics/claude-code

Qué debería pasar: Claude Code descargará el directorio del mercado y te notificará que se ha añadido con éxito. Ahora tu "estantería" tiene productos, pero todavía no has instalado nada.

Paso 2: Abre el gestor de plugins y echa un vistazo

Teclea:

/plugin

Qué debería pasar: Se abrirá una interfaz con cuatro pestañas: Descubrir / Instalados / Mercados / Errores. Puedes cambiar de pestaña con Tab (y Shift+Tab para volver atrás). En la pestaña "Descubrir", verás los plugins de demostración del mercado que acabas de añadir. Si ves commit-commands en la lista = el mercado se añadió bien.

Paso 3: Instala el plugin commit-commands

Puedes instalarlo haciendo clic en él en la interfaz, o directamente con un comando (este es el segundo paso):

/plugin install commit-commands@claude-code-plugins

Fíjate que después del @ va claude-code-plugins. Ese es el nombre interno del mercado de demostración (no anthropics/claude-code, que era el repositorio que añadiste en el paso 1). Te pedirá que elijas el alcance (scope):

• Usuario (por defecto): Lo puedes usar en cualquier proyecto.
• Proyecto: Se guarda en .claude/settings.json, y los colaboradores del repositorio podrán usarlo.
• Local: Solo para ti, en este repositorio.

Elige "Usuario" (User scope) que es el predeterminado.

Qué debería pasar: La terminal te avisará de que la instalación ha sido un éxito, y quizá te muestre si se instaló alguna dependencia automáticamente.

Paso 4: Haz que el plugin funcione y veas sus comandos

/reload-plugins

Qué debería pasar: Claude Code se recargará y te dirá cuántos plugins, skills, agentes y hooks están cargados. Dado que el skill de commit-commands usa un espacio de nombres, ahora tendrás disponible un comando como /commit-commands:commit.

Paso 5: Úsalo (mira el skill del plugin en acción)

Haz cualquier pequeño cambio en un archivo de tu proyecto (por ejemplo, crea un archivo de texto vacío), y escribe:

/commit-commands:commit

Qué debería pasar: Este skill añadirá tus cambios al staging, generará un mensaje de commit y lo ejecutará. Si ves que completa todo este flujo de git, significa que el plugin no solo se ha instalado, sino que funciona. Acabas de experimentar lo que es instalar de un clic un flujo de trabajo ya hecho.

⚠️ Si al ejecutar el paso 5 te dice que no encuentra el comando, asegúrate de que hiciste el paso 4 (/reload-plugins); si sigue sin ir, ve a la pestaña "Errores" en /plugin para ver qué ha fallado al cargar.

Al completar estos cinco pasos, habrás verificado por ti mismo toda la ruta: "Añadir mercado → Instalar plugin → Cargar cambios → Usar comando con espacio de nombres". En el futuro, la instalación de cualquier plugin seguirá este mismo patrón.

💡 Resumen en una frase: Añadir mercado (marketplace add) → Instalar plugin (install) → Recargar (/reload-plugins) → Usar comandos con espacio de nombres. Hacer este ejercicio de 5 pasos te enseñará más que memorizar diez comandos teóricos.

---

07 ¿Quieres empaquetar tus cosas? Conoce la estructura del directorio

Todo lo anterior trataba de "usar los plugins de los demás", pero tarde o temprano querrás "empaquetar mi configuración en un plugin". No te voy a enseñar a crearlo de cero aquí, pero sí vamos a revisar cómo es la estructura de directorios de un plugin para que lo entiendas a vista de pájaro.

El núcleo de un plugin consta de dos cosas: el archivo de "identidad" + las carpetas de los componentes.

El archivo de identidad es .claude-plugin/plugin.json, y declara el nombre, descripción y versión del plugin:

{
  "name": "my-first-plugin",
  "description": "A greeting plugin to learn the basics",
  "version": "1.0.0"
}

El campo más importante es name, porque determinará el espacio de nombres de tus skills. Los skills de este plugin se invocarán como /my-first-plugin:xxx. version es opcional, pero necesario para que los usuarios reciban actualizaciones; si vas a publicarlo, asegúrate de aumentar la versión con cada cambio.

Las carpetas de los componentes se colocan en la raíz del plugin, clasificadas por su tipo. Basado en la estructura sugerida oficialmente, debes organizar las cosas así:

Qué quieres añadir	En qué directorio lo pones
skill	skills/<nombre>/SKILL.md
subagente	agents/
hook	hooks/hooks.json
Servidor MCP	.mcp.json en la raíz
Servidor LSP	.lsp.json en la raíz

En resumen, un plugin se vería más o menos así:

my-first-plugin/
├── .claude-plugin/
│   └── plugin.json        ← La identidad, solo esto va aquí
├── skills/
│   └── hello/
│       └── SKILL.md
├── agents/
│   └── reviewer.md
└── hooks/
    └── hooks.json

Voy a recalcar algo que la documentación menciona de forma clara y que es un error común:

Error común: No coloques commands/, agents/, skills/ o hooks/ dentro del directorio .claude-plugin/. Solo plugin.json debe ir en .claude-plugin/. El resto de carpetas deben estar en el directorio raíz del plugin.

Dicho de forma sencilla: En .claude-plugin/ SOLO puede haber plugin.json, todo lo demás va en la raíz del plugin, al mismo nivel que .claude-plugin/. Yo mismo cometí este error la primera vez: por comodidad metí skills/ dentro de .claude-plugin/, y aunque cargó bien y /reload-plugins no dio error, mi skill no aparecía por ningún lado. Me pasé rato revisando el plugin.json y todo estaba bien, hasta que me di cuenta de que el directorio estaba mal ubicado. Lo moví fuera, al nivel de plugin.json, y funcionó al instante.

Quizá notes que esta estructura de directorios es casi idéntica a los directorios locales del .claude/ (del artículo 13), agents/ (del 23) y .mcp.json (del 22). No es una casualidad. Básicamente, crear un plugin es coger esas configuraciones dispersas en tu .claude/ y organizarlas con la misma estructura dentro de una carpeta independiente. Por eso la documentación dice que las configuraciones locales se pueden "convertir en plugins" fácilmente.

Si quieres probar a cargar tu propio plugin sin pasar por el mercado, hay una forma rápida recomendada: usa --plugin-dir al arrancar para cargar tu directorio local:

claude --plugin-dir ./my-first-plugin

Esto es para pruebas y desarrollo. Cuando hagas cambios, con un /reload-plugins verás los efectos, sin necesidad de publicar en un mercado ni instalarlo.

💡 Resumen en una frase: Un plugin se forma de .claude-plugin/plugin.json (identidad, el name fija el espacio de nombres) + carpetas de componentes en la raíz; memoriza la regla de oro: dentro de .claude-plugin/ solo va plugin.json, el resto va en el directorio principal.

---

08 Cuidado al instalar plugins de terceros: Pasa siempre la "prueba de confianza"

Esta es la sección donde debes tener más cuidado en todo el artículo, y es donde los principiantes suelen confiarse demasiado: Un plugin no es un juguetito inofensivo, es algo que puede ejecutar cualquier código en tu ordenador con tus permisos.

Recuerda lo que vimos en el artículo 21 sobre límites de seguridad; ese mismo criterio se aplica aquí, y con más motivo. La documentación es bastante seria en este punto:

Los plugins y mercados son componentes de alta confianza que pueden usar los permisos de tu usuario para ejecutar código arbitrario en tu máquina. Instala plugins y añade mercados únicamente si confías en la fuente.

¿Qué significa esto? Un plugin puede incluir hooks (scripts automáticos), servidores MCP (programas que se inician solos), o binarios en bin/. Si lo instalas y lo activas, todo esto empezará a ejecutarse en tu sistema, bajo tu usuario: podrá leer tus archivos, acceder a la red y ejecutar comandos. Con los mismos permisos que tienes tú. Instalar un plugin de origen desconocido es casi como ejecutar un script de un desconocido en tu ordenador.

Analogía: Bajar un .exe de una web rara y ejecutarlo. Seguramente no ejecutarías un archivo descargado de una web desconocida, ¿verdad? Porque una vez en marcha puede hacer de todo. Pues instalar plugins de terceros es igual. Debes plantearte siempre: "¿De dónde viene?" antes de instalar, no te dejes llevar por lo rápido que es el /plugin install.

Por eso te doy estas tres reglas para hacer una "autoevaluación" antes de instalar cualquier plugin de terceros. Considera esto una norma estricta:

Lo que debes revisar	Cómo hacerlo
¿La fuente es de confianza?	Da prioridad al mercado oficial; si es de la comunidad, revisa el autor y el repositorio; si es un origen privado o desconocido, no lo instales si no estás seguro.
¿Qué incluye el plugin?	Antes de confirmar la instalación, revisa en "Se instalará" del /plugin si trae hooks, MCP o ejecutables.
¿Dónde lo instalo (alcance)?	Si dudas, pruébalo en el alcance "Local" primero. No uses "Usuario" de buenas a primeras.

Hay algunos mecanismos de diseño oficial que pueden darte algo de tranquilidad: los plugins del mercado de la comunidad pasan por verificaciones automáticas de seguridad y revisiones, y se anclan a una confirmación (commit) concreta (el autor no puede cambiar el contenido por otro diferente); los del mercado oficial están elegidos a dedo por Anthropic. Pero nada de esto reemplaza tu sentido común: "instala solo lo que consideres fiable".

Para ir a lo seguro: instala los del mercado oficial sin miedo; para los de la comunidad, revisa quién lo ha hecho y qué permisos pide en su web antes de actuar; y de los plugins privados o desconocidos, aléjate a menos que puedas auditar su código. La facilidad de uso está genial, pero tú eres responsable de la seguridad. La suavidad de la instalación a un solo clic no significa que el contenido sea seguro.

💡 Resumen en una frase: Los plugins pueden usar tus permisos para ejecutar código, instalarlos equivale a ejecutar scripts de terceros; aplica siempre las tres reglas antes de instalar (origen de confianza, qué incluye, alcance de la instalación). El mercado oficial es el más seguro; no instales desde fuentes desconocidas.

---

09 Resumen

En este artículo hemos visto los plugins de Claude Code de principio a fin. Un plugin no es más que una caja en la que metes las extensiones que vimos anteriormente (skills, subagentes, hooks, etc.), empaquetadas para poder instalarse de un solo golpe, compartirse y actualizarse fácilmente.

Vamos a repasar los puntos más importantes:

Lo que debes recordar	Con qué	Puntos clave
Concepto de plugin	plugin = la caja de herramientas empaquetada	Empaqueta skill/subagent/hook/MCP/LSP; configuraciones sueltas para uso propio, plugins para compartir
Instalar plugins de otros	Mercado de plugins	Dos pasos: marketplace add para añadir el mercado → install para instalar el plugin
Identificar los mercados	3 mercados oficiales	El oficial viene de serie, el de la comunidad necesita instalarse a mano (revisado), el de demostración es para aprender
Aplicar el plugin	/reload-plugins	Úsalo cada vez que instales/desinstales o pares un plugin, no hay que reiniciar el programa
Entender qué trae	Detalles del /plugin	Revisa el panel "Se instalará" y el consumo de contexto antes de instalar nada
Empaquetar el tuyo	plugin.json + carpetas en la raíz	El .claude-plugin/ solo puede contener plugin.json, nada más
Instalar plugins de terceros	Las tres reglas de confianza	Pueden ejecutar código; asegúrate de que la fuente sea fiable antes de instalar

Ahora serás capaz de: Saber cuándo usar configuraciones sueltas y cuándo plugins; utilizar los 3 pasos "Añadir mercado → Instalar plugin → /reload-plugins" para sacar funcionalidades del mercado; revisar la pestaña "Se instalará" y el gasto de contexto; conocer la estructura de carpetas de un plugin, y ser consciente de las precauciones de seguridad antes de instalar plugins de terceros. Gracias a esto, ya no tendrás que configurarlo todo desde cero; tienes un mercado de paquetes listos a tu disposición.

Desde el artículo 18 hasta este, hemos completado toda tu "caja de herramientas de expansión" para Claude Code: CLAUDE.md, MCP, subagentes, skills, hooks, y finalmente los plugins para controlarlos todos de una vez. Tus herramientas están listas.

---

El próximo será el artículo 25 "El Sistema de Memoria (Memory)". Con todas estas herramientas, quizás te hayas dado cuenta de algo incómodo: cada vez que abres una nueva sesión, Claude vuelve a ser "un lienzo en blanco", olvidando tus preferencias o los datos clave del proyecto que le diste ayer. En el próximo artículo hablaremos de cómo lograr que Claude te "recuerde" a través de múltiples sesiones, recordando que te gusta cierta estructura o las reglas estrictas de tu proyecto sin que tengas que repetírselo en cada inicio de chat. Imagínate: si se comporta como un colega que te conoce desde hace tiempo y adivina tus intenciones, ¿a que sería genial?

---

Lecturas recomendadas

• Voice (Modo Voz): Habla en vez de escribir los prompts
• Agent teams (Equipos de agentes): Colaboración multi-sesión
• Gestión de contexto: Ni amnesia ni agotar tokens