Marketplaces de plugins y versionado de dependencias

Módulo 5 · Extensibilidad · Lección 8 de 8

Al terminar esta lección podrás evaluar qué artefactos de activación pertenecen al plugin del equipo, justificar la decisión de empaquetado del Día 28 con un criterio defendible y entregar al CoE un plugin versionado que pueda mantener después del proyecto.

Día 30. ¿Qué sobrevive cuando te vas?

Un plugin es todo lo que has construido, empaquetado en una unidad instalable

Has construido skills, configurado hooks, puesto en marcha servidores MCP y definido especificaciones de subagentes. Un plugin es el mecanismo que mantiene todo junto y distribuible después de que termine el proyecto.

Un plugin es una carpeta con un manifiesto plugin.json y el conjunto completo de extensiones de Claude Code que proporciona. El desarrollador lo instala con un solo comando y obtiene todo lo que contiene (skills, hooks, configuraciones MCP, slash commands, especificaciones de subagentes) sin instalar cada componente por separado. Después de instalarlo, verifica que cada componente carga y funciona como se espera: los problemas de autenticación MCP, los errores de permisos de hooks y los conflictos entre plugins pueden impedir que algunos componentes se activen.

Estructura de directorios del plugin

flowchart TD
    R["my-plugin/"] --> CP[".claude-plugin/"]
    CP --> PJ["plugin.json ← obligatorio: manifiesto del plugin"]
    R --> CM["commands/ ← slash commands personalizados"]
    CM --> CR["code-review.md"]
    R --> AG["agents/ ← especificaciones de subagentes"]
    AG --> SA["security-auditor.md"]
    R --> SK["skills/ ← skills"]
    SK --> CS["coding-standards/"]
    CS --> SM["SKILL.md"]
    R --> HK["hooks/ ← configuración de hooks"]
    HK --> HJ["hooks.json"]
    R --> MC[".mcp.json ← definiciones de servidores MCP"]

plugin.json: manifiesto del plugin

{
"name": "finserv-activation",
"version": "1.0.0",
"description": "Claude Code activation plugin for FinServ Corp engineering team"
}

Comandos de instalación

# Instalar un plugin específico
/plugin install @org/plugin-name
# Explorar los plugins disponibles
/plugin browse
# Actualizar un plugin instalado
/plugin update @org/plugin-name

El ejercicio de empaquetado del Día 30: qué incluir y qué dejar fuera

Estás cerrando una activación de cuatro semanas con un equipo de ingeniería de 12 personas en un cliente de servicios financieros. El plan de activación prevé una decisión de empaquetado en la semana 4: ¿qué skills, configuraciones MCP, hooks, subagentes y slash commands construidos durante la activación deben incluirse en el plugin del equipo?

No todo pertenece al plugin. Un componente que funcionó para el flujo de trabajo de un desarrollador no está listo para 12. Aplica esta prueba de idoneidad a cada componente antes de incluirlo:

Componente	Incluir si…
Skill	La usan al menos dos miembros del equipo y se ha probado en la práctica durante la activación
Configuración MCP	La ha aprobado el equipo de seguridad del cliente y tiene una conexión estable y probada
Hook	Funciona, está probado y aporta valor a todo el equipo, no solo al flujo de trabajo de un desarrollador
Subagente	Se ha probado en al menos un escenario real del proyecto durante la activación
Slash command	Es un patrón de prompt de uso frecuente que el equipo quiere conservar, no un experimento puntual

La conversación con el CoE que hay que tener antes del Día 27

El plugin necesita un lugar donde vivir después de que termine el proyecto. Eso significa un marketplace empresarial o un registro compartido que gestiona el CoE. No esperes al Día 30 para tener esta conversación. Si el marketplace no existe, montarlo lleva tiempo. Plantéalo en el punto de control con el CoE de la semana 3.

Plugin del equipo frente a marketplace empresarial: dos ámbitos de distribución

La separación importa para la gobernanza. Distintos propietarios, distintos ritmos de publicación, distintas audiencias.

Plugin del equipo: específico del equipo, propiedad del equipo. Skills y hooks propios del flujo de trabajo de este equipo. Se instala desde un registro compartido que gestiona el CoE. Los desarrolladores de este equipo lo instalan; nadie más lo necesita. El equipo puede iterar sobre él sin esperar a un ciclo de publicación del CoE.

Marketplace empresarial: de alcance organizativo, gobernado por el CoE. Configuraciones MCP aprobadas, hooks de seguridad y skills de cumplimiento que aplican a todos los desarrolladores. El CoE verifica y publica. El ciclo de publicación es más estricto: los cambios pasan por el flujo de aprobación antes de llegar a toda la organización.

La arquitectura refleja cómo las buenas organizaciones gestionan la infraestructura compartida: una capa de gobernanza (el plugin del CoE) y una capa de equipo (el plugin del equipo), cada una con su propio ritmo de publicación y su propio propietario. Un mega-plugin acopla ambas; cualquier cambio en un componente requiere una publicación completa del CoE.

Cuando el marketplace empresarial tiene un plugin aprobado, el CoE puede conectarlo con RBAC y con la asignación de grupos SCIM en la Admin Console. El flujo tiene tres pasos: crear y aprobar el plugin, publicarlo en el marketplace y asignarlo a los grupos SCIM correspondientes. A partir de ahí, cualquier desarrollador aprovisionado en esos grupos recibe la configuración aprobada automáticamente: sin instalación manual, sin herramientas en la sombra y sin brecha entre el acceso y la configuración.

flowchart LR
    S1["1. Crear y aprobar el plugin"] --> S2["2. Publicar en el marketplace"]
    S2 --> S3["3. Asignar a los grupos SCIM"]
    S3 --> S4["El desarrollador aprovisionado recibe la configuración aprobada"]

La propuesta de gobernanza del Día 1

Cuando el CISO del cliente pregunta cómo mantendrán el control a medida que Claude Code escala entre equipos, esta es la respuesta: tu equipo de seguridad aprueba el plugin, tu equipo de TI lo asigna a los grupos SCIM adecuados, y cada nuevo desarrollador hereda la configuración aprobada el primer día. El acceso a la herramienta y el acceso a la configuración gobernada llegan juntos. Ese es el modelo, no documentos de política y la esperanza de que los desarrolladores cumplan.

Versionado del plugin: qué contarle al CoE para mantener la estabilidad

El plugin entrega una configuración conocida como buena. El versionado es lo que la mantiene así después de que termine el proyecto.

El manifiesto plugin.json admite versionado. Tres prácticas que hay que establecer con el CoE el Día 30:

1. Fija las versiones de los servidores MCP. Los servidores MCP se actualizan de forma independiente, así que un cambio upstream en el esquema de entrada de una herramienta puede romper un flujo de trabajo del que depende el equipo. Fija las versiones en el manifiesto y deja que el CoE pruebe y promueva las nuevas versiones de forma deliberada.
2. Versiona el propio plugin. Cuando el CoE publica una versión nueva, los desarrolladores ejecutan /plugin update, y el número de versión le dice al soporte exactamente qué configuración está usando cada equipo.
3. Documenta el paquete del Día 30. Registra qué contiene el plugin, qué versión de cada servidor MCP está incluida y quién es su propietario. Es el documento de traspaso: el CoE lo recibe de ti; sin él, el plugin es una caja negra que nadie sabe mantener.

Comprueba tu comprensión

Dos afirmaciones para verificar tu lectura de estos límites antes del escenario.

Arquitectura del plugin: dos afirmaciones

Actividad · ¿Verdadero o falso? Selecciona una respuesta para cada afirmación.

Afirmación 1: un plugin del equipo y un plugin del CoE deben compartir el mismo ritmo de publicación porque se distribuyen como un paquete.

Verdadero / Falso

Ver respuesta

Falso. Tienen propietarios distintos y ritmos de publicación independientes. El CoE gobierna lo que posee: configuraciones MCP aprobadas para toda la organización, hooks de seguridad y skills de cumplimiento. El equipo itera sobre lo que posee: skills, comandos y hooks locales específicos del equipo. Acoplarlos al mismo ciclo de publicación anula la separación.

Afirmación 2: una configuración MCP que el equipo de seguridad no ha revisado puede incluirse en el plugin del equipo siempre que se etiquete como «experimental».

Verdadero / Falso

Ver respuesta

Falso. Solo deben incluirse configuraciones MCP aprobadas y estables. La etiqueta «experimental» no sustituye a la revisión de seguridad: solo documenta que el equipo sabe que no está revisada. Cuando el plugin se distribuye, los desarrolladores asumen que los componentes incluidos son seguros de usar. Los servidores no aprobados saltan el modelo de gobernanza que el CISO del cliente acaba de respaldar.

Los plugins del equipo y del CoE son independientes por diseño: propietarios independientes, ritmos independientes. Los componentes incluidos se ganan su lugar a través de la tabla de idoneidad: la aprobación de seguridad no es opcional, y «experimental» no es un atajo.

Revisión del empaquetado del Día 28: ¿qué va en el plugin?

Estás con el CoE del cliente. Tienes cinco componentes que evaluar. Tres decisiones son claras y dos son de criterio: aplica la tabla de idoneidad.

Decisión · Empaquetado del plugin

Día 28. Revisión de la activación. Tienes: un subagente security-auditor (probado durante 3 sprints), una skill de documentación de API (la usan 8 de 10 ingenieros), una skill de ISO 20022 (la usan 2 ingenieros y todavía está en pruebas), un hook de registro (probado y funcionando) y una configuración MCP de Jira (aprobada por TI la semana pasada). ¿Qué va en el plugin del equipo?

• A · Todo. Se construyó todo durante la activación y debe conservarse.
• B · Solo la skill y el hook. Los MCP y los subagentes añaden complejidad de mantenimiento.
• C · El auditor de seguridad, la skill de documentación de API, el hook de registro y la configuración MCP de Jira. Incluye lo probado y aprobado. Deja la skill de ISO 20022 en una rama de desarrollo hasta que cumpla el umbral del equipo.

Ver respuesta

C es correcta. El auditor de seguridad está probado durante 3 sprints, la skill de documentación de API la usan 8 de 10 ingenieros, el hook de registro está probado y funciona, y la configuración MCP de Jira está aprobada por TI: los cuatro superan la tabla de idoneidad. La skill de ISO 20022 está en el límite (2 de 10, aún en pruebas): déjala en una rama de desarrollo, revísala en el siguiente sprint y añádela cuando esté lista. La opción A incluye un componente sin probar que todo desarrollador recibe al instalar. La opción B descarta los MCP y los subagentes por principio: es una preferencia, no una decisión de gobernanza.

Construye tu plugin de activación

Todo lo construido en las lecciones 5.1 a 5.7 va en un único plugin instalable. Es el artefacto que entregas al CoE del cliente el Día 30.

1. Crea el directorio del plugin. Crea un directorio <client-name>-activation/. Dentro: .claude-plugin/plugin.json (el manifiesto), skills/, hooks/, agents/ y .mcp.json.
2. Copia tus componentes. Copia el SKILL.md de la lección 5.5 en skills/<skill-name>/. Copia el hooks.json de la lección 5.6 en hooks/. Copia la especificación del subagente de la lección 5.7 en agents/. Añade el .mcp.json de la lección 5.1.
3. Escribe el manifiesto plugin.json. Define el nombre, la versión y la descripción del plugin. Estos son los tres campos obligatorios. Fija las versiones de los servidores MCP que incluyas para que el CoE controle cuándo se promueven las actualizaciones.
4. Instala y verifica. Ejecuta /plugin install ./<client-name>-activation/. Verifica que la skill carga, que el hook se dispara y que el servidor MCP conecta.

Artefacto del curso · Completo

Plugin de activación

Skill de ejemplo y script de hook funcional

1. Incluye tu SKILL.md de la lección 5.5 y tu hooks.json de la lección 5.6 en la estructura de directorios del plugin de esta lección.
2. Haz commit del plugin completo en el repositorio de la cohorte. Es el artefacto que entregas al CoE del cliente el Día 30: todo lo que el equipo necesita para seguir usando Claude Code cuando termine el proyecto.

Este es el artefacto que hereda el CoE del cliente. Todo lo que necesita para mantener Claude Code en marcha cuando te vayas está en este directorio.

Práctica

Antes de salir de este curso, construye una skill que funcione y un hook que funcione en tu instalación local de Claude Code. Conecta un servidor MCP aprobado. Estos tres componentes (una skill que se ejecuta, un hook que se dispara y una conexión MCP que se mantiene) son tu prueba de preparación. Si puedes construir y probar los tres de forma independiente, puedes guiar a un equipo de cliente por la misma configuración en un proyecto.

Ya puedes extender Claude Code para cualquier entorno de cliente

Ocho lecciones, un solo resultado: las skills para conectar Claude Code a los sistemas del cliente, gobernar a qué puede acceder, empaquetar la experiencia reutilizable, automatizar las barreras de control, orquestar el trabajo en paralelo y entregarlo todo como un plugin versionado que sobrevive al proyecto.

Ideas clave

• Un plugin agrupa skills, hooks, configuraciones MCP, slash commands y especificaciones de subagentes en una sola unidad instalable con un manifiesto plugin.json.
• Solo entran en el plugin los componentes que superan la tabla de idoneidad: uso por al menos dos personas, aprobación de seguridad para los MCP y valor para todo el equipo.
• El plugin del equipo y el del CoE tienen propietarios y ritmos de publicación distintos; «experimental» no sustituye a la revisión de seguridad.
• El marketplace empresarial, RBAC y los grupos SCIM permiten que cada desarrollador aprovisionado reciba la configuración aprobada desde el primer día.
• Versiona el plugin, fija las versiones de los servidores MCP y documenta el paquete del Día 30 para que el CoE pueda mantenerlo.

Siguiente: Managed settings: login, MCP y restricciones de hooks