Plugins de Claude Code: cómo instalarlos con criterio

Hola, bienvenido. En la lección anterior le dimos a Claude un navegador, y en el caso de Playwright lo hicimos añadiendo a mano un servidor MCP con un solo comando. En esta lección vamos a ver la forma de instalar varias piezas de golpe: los plugins. Veremos qué trae un plugin, cómo se buscan e instalan con /plugin, qué es el marketplace oficial de Anthropic y en qué se diferencia de los demás, qué ámbito elegir al instalar y, sobre todo, cómo revisar un plugin antes de darle acceso a tu máquina. Para practicar vamos a revisar security-guidance, el plugin de seguridad que instalaremos en la siguiente lección.

¿Por qué tanto énfasis en el criterio? Porque un plugin es la forma más rápida de meter en tu Claude Code configuración escrita por otros, y la documentación lo dice sin rodeos en la primera línea de su página de seguridad: un plugin que instalas puede ejecutar código arbitrario en tu máquina con tus privilegios de usuario. Sus hooks y sus servidores MCP se ejecutan fuera del sandbox, y las reglas de permisos que configuramos en la sección de permisos no cubren el código que el plugin ejecuta por su cuenta. Es la misma situación que con un paquete de Composer que añades a un proyecto, y ya sabes cómo acaba eso cuando nadie revisa lo que instala. Si quieres un caso reciente del ecosistema Laravel, lo tienes en el artículo El ataque a laravel-lang: cómo un paquete de traducciones acabó robando credenciales↗ (se abre en una pestaña nueva).

Para seguir esta lección necesitas una sesión de Claude Code en la raíz de claude-tasks y tu terminal. No vamos a instalar nada ni a cambiar ningún archivo del proyecto: todo lo que vamos a hacer es mirar, que es justo lo que hay que hacer antes de instalar.

Un plugin es una carpeta con componentes que Claude Code instala y carga como una sola unidad, normalmente con un manifiesto en .claude-plugin/plugin.json que le da nombre, versión y descripción. Los componentes son piezas que ya conoces, empaquetadas:

• Skills y comandos, que se invocan con el nombre del plugin delante, como /mi-plugin:review, tal y como vimos en la tabla de la lección de skills.
• Agentes, subagentes a los que Claude puede delegar, que veremos en la siguiente sección del curso.
• Hooks, en un hooks/hooks.json, que se ejecutan en los eventos de Claude Code igual que los nuestros.
• Servidores MCP y LSP. Los MCP le dan herramientas a Claude, y los LSP conectan un servidor de lenguaje para que Claude vea los errores de tipos después de cada edición.
• Ejecutables en una carpeta bin/, que Claude Code añade al PATH de los comandos de Bash.

Además pueden traer estilos de salida, temas, canales, monitores y unos pocos ajustes por defecto. Nada de esto necesita un plugin para funcionar: todo lo que hemos montado en .claude/ funciona sin él. Un plugin tiene sentido cuando quieres recibir un conjunto de piezas que ha preparado otro, con un solo comando y con sus actualizaciones, o cuando quieres repartir el tuyo entre varios proyectos o equipos.

Y antes de instalar cualquiera, piensa que un plugin activado forma parte de todas tus sesiones, también de las que no lo usan. El nombre y la descripción de cada skill y cada agente que Claude puede invocar por su cuenta viajan en el contexto en cada turno, sus servidores MCP se arrancan con cada sesión y sus hooks se disparan en sus eventos. Por eso /doctor te avisa de los plugins que no usas comparados con lo que ocupan, como vimos en la lección de comandos, y /usage te enseña qué parte de tu uso se llevan.