kbspec como plugin de agente

La instalación de siempre deja las skills, los agentes de fase, los ganchos y el servidor MCP en cada repositorio de código (kb init-repo). Algunas organizaciones activan una política para que Copilot cargue solo las personalizaciones que vienen de un plugin, y ahí lo que deja kb init-repo en el repositorio no alcanza. Para ese caso, y a pedido, kbspec se empaqueta como un plugin de agente con el formato de la especificación Agent Plugins 1.0.0.

Empaquetar

Lo corre quien administra kbspec, sobre una carpeta vacía o una que ya generó kbspec (solo rehace esas):

kb plugin empaquetar ~/kbspec-plugins --marketplace kbspec-equipo

Deja un marketplace con un plugin adentro:

kbspec-plugins/
├── .claude-plugin/marketplace.json
├── README.md
└── plugins/kbspec/
    ├── plugin.json            el manifiesto, con la versión de kbspec
    ├── skills/                las skills que rigen para el equipo
    ├── com.github.copilot/    los agentes y los ganchos de Copilot
    └── mcp.json               el servidor MCP (kb mcp)

Las skills son las que rigen: las del framework, con la versión del equipo donde la hay, más las propias, menos las deshabilitadas en SKILLS.md. Es lo mismo que instala kb init-repo.
La rama de quien empaqueta no viaja: si tiene un requerimiento abierto, su rama no entra en los agentes, que llevan el prefijo de ramas de la estrategia del equipo.
Los nombres por defecto son kbspec-equipo para el marketplace y kbspec para el plugin (--nombre); --dueno dice quién lo publica. Van en minúsculas, números y guiones.

Probar

kb plugin probar ~/kbspec-plugins

Dice lo que un cliente de Agent Plugins rechazaría, antes de que lo rechace: el $schema y el nombre del plugin.json, claves que el esquema no admite, skills cuyo name no es el de su carpeta o que no tienen descripción, un servidor MCP que no es stdio válido y ganchos mal formados. Sale con 1 si encuentra algo.

Publicarlo en Azure Repos

El marketplace es un repositorio git con esa carpeta en la raíz, en Azure Repos o en GitHub. Nadie lo edita a mano: cuando el equipo cambia sus skills, o llega una versión nueva de kbspec, se vuelve a empaquetar sobre la misma carpeta y se hace commit. VS Code toma la versión nueva del repositorio.

Activarlo en cada repositorio de código

Una vez por repositorio, y por Pull Request:

kb plugin activar https://dev.azure.com/<org>/<proyecto>/_git/kbspec-plugins --marketplace kbspec-equipo
kb plugin                  # ¿llega kbspec como plugin a este repositorio?
kb plugin desactivar       # saca solo lo de kbspec

activar escribe .github/copilot/settings.json —extraKnownMarketplaces y enabledPlugins— sin tocar lo que ya tenía; el --marketplace es el mismo con que se empaquetó. Una URL de Azure Repos se registra como git y se clona con la credencial de git de cada máquina; un dueño/repo se registra como GitHub. Con --repo se activa en otro repositorio que el actual. El archivo se sube por Pull Request: así VS Code se lo ofrece a todo el equipo al abrir el repositorio. desactivar quita solo las entradas de kbspec, y si el archivo queda vacío lo borra.

En VS Code, los plugins de agente tienen que estar habilitados (chat.plugins.enabled).

Qué cambia y qué no

	Instalación de siempre	Como plugin
kbspec en cada máquina	Sí	Sí: los ganchos y el MCP llaman a `kb`
Skills y agentes	En cada repositorio de código	En el marketplace del equipo
Cómo llegan los cambios del equipo	`kb update`	Se empaqueta de nuevo y se hace commit
Quién decide qué skills rigen	`SKILLS.md`	`SKILLS.md`, al empaquetar

El expediente y el rastro de auditoría los escribe siempre la CLI, y las compuertas son ganchos que llaman a kb: nada de eso depende de cómo llegaron las skills.