Varios plugins en un marketplace de Claude Code: el común, uno por tipo de proyecto y el paquete

Hola, bienvenido. En esta lección vamos a añadir al marketplace un segundo plugin, team-filament, con las convenciones del equipo para los proyectos que tienen un panel de Filament. Con él vamos a ver cómo se reparte la configuración cuando el equipo trabaja con varios tipos de proyecto: qué contiene el plugin común, qué un plugin por tipo y qué se queda en cada repo. Es la última lección del núcleo, así que al final repasaremos qué tiene ya el equipo y qué sigue dependiendo de las personas.

El equipo de Marta no tiene un solo tipo de proyecto. helpdesk sirve vistas con Blade, el siguiente proyecto llevará un panel con Filament y hay una API prevista. Las convenciones del panel no le sirven de nada a la API, y si las añadimos a team, el plugin acaba siendo el mismo cajón que era .claude/: una mezcla de piezas que cada repo usa a medias y que cuesta contexto en todas las sesiones.

En la primera lección repartimos la configuración entre el plugin, el paquete, el repo y lo personal. Con varios tipos de proyecto, ese reparto gana una pregunta más: a cuántos proyectos afecta cada pieza. Se resume en 3 reglas:

• Lo que es igual en todos los proyectos forma parte del plugin común, team.
• Lo que depende del tipo de proyecto forma parte de un plugin aparte del mismo marketplace, como team-filament. Si es una convención de código, forma parte de un paquete Composer por arquitectura.
• Lo que es de un solo proyecto se queda en su repo.

Con lo de un solo proyecto es más fácil equivocarse. La tentación es escribirlo todo en CLAUDE.md, y entonces CLAUDE.md crece con cada detalle y se carga entero en cada sesión. El repo lo reparte en 3 sitios. CLAUDE.md solo recoge lo esencial: qué es el proyecto, los comandos clave y dónde está cada pieza. Las reglas del proyecto están en .claude/rules/, con paths:, que Claude Code solo carga cuando la sesión toca esos archivos, y cada una remite al documento de .ai/docs/ que tiene el detalle. Y los procedimientos propios del proyecto son skills del repo, en .claude/skills/. Es el mismo patrón de rules que remiten a docs que trae tu proyecto del Setup Profesional. Si tienes dudas con paths:, lo tienes en la lección Rules en Claude Code: instrucciones por carpeta con .claude/rules↗ (se abre en una pestaña nueva) del curso de Claude Code.

Por ejemplo, un proyecto que importa datos con jobs tendría una rule como esta, que solo entra en la sesión cuando Claude toca app/Jobs/:

Si el equipo arranca un segundo proyecto de importación y esa rule, su doc y sus skills se repiten, ya no son de un solo proyecto. Pasan a un plugin de ese tipo, team-etl, que instalan los 2 repos.