Copilot, Claude y OpenCode

kbspec funciona desde el chat: se escribe lo que se quiere y el asistente hace el resto, invocando al CLI.

Con IBM Bob es lo mismo, con sus propios archivos y su protocolo de ganchos: ver IBM Bob.

Skills y comandos «/»

Las skills (/kb-iniciar, /kb-abrir, /kb-estado, /kb-modelo, /kb-ayuda, …) son atajos que hacen lo mismo que escribir en lenguaje natural. En Claude viven en .claude/skills/; en Copilot se espejan a .github/prompts/ como comandos de sesión.

Agentes de fase

Cada fase del ciclo tiene un agente con su rol y —si el equipo llenó MODELOS.md— el modelo ya elegido. Traen un botón de «siguiente paso» para que el ciclo fluya sin memorizar comandos — con el modelo de la fase destino escrito, si el equipo llenó la tabla. Y la extensión abre el chat de la fase siguiente sola, con el mismo modelo.

Dónde viven: el plugin kbspec

El modo KB, los agentes de fase y las skills llegan como un plugin de Copilot que kb instalar y kb init-repo instalan en la máquina —~/.copilot/installed-plugins/_direct/kbspec/, registrado en ~/.copilot/config.json, como lo hace copilot plugin install—. Es la forma que recomiendan VS Code y GitHub para distribuir personalizaciones a todo un equipo, y es lo único que ven a la vez:

el chat de VS Code, en cualquier ventana;
la ventana de agentes, que trabaja en una carpeta —la que elegís, o la del archivo abierto, o la primera del workspace del requerimiento— y, aislada, en un árbol que solo trae lo versionado;
la Copilot CLI (copilot plugin list lo muestra).

En el chat de VS Code, las skills del plugin aparecen como /kbspec:<skill>; los agentes, con su nombre (KB, kb-analizar…). Dentro del motor de Copilot —la ventana de agentes, la Copilot CLI y el SDK— los agentes llevan el prefijo del plugin: kbspec:kb-analizar (copilot --agent kbspec:kb-analizar). kb lote ya los llama así. En Windows, los agentes van también a ~/.github/agents/, la carpeta de usuario de Visual Studio 2026.

Qué no va en el plugin, y por qué:

los ganchos siguen en ~/.copilot/hooks/kbspec.json: ya actúan en los tres lugares, y en el plugin correrían dos veces;
el servidor MCP sigue en cada repositorio (.mcp.json, .vscode/mcp.json): ahí también lo lee Claude Code, y en VS Code saldría duplicado.

Hasta la 3.196.0 los agentes iban a .github/agents/ de cada repositorio, ignorados por git: en la ventana de agentes, con la carpeta del expediente o en un árbol aislado, no aparecía KB. Al actualizar se quitan de los repositorios —si no, VS Code los mostraría dos veces—. Uno que el equipo haya commiteado, o con otro nombre, no se toca. Si la organización desactiva los plugins (la política ChatPluginsEnabled), el agente KB no aparece: kb check --studio lo dice.

Una sesión nueva de la ventana de agentes corre en un árbol aparte del repositorio (<repo>.worktrees/<nombre>, rama agents/<nombre>), sin la sesión de kbspec. kbspec encuentra solo el requerimiento abierto de ese repositorio y lo deja anotado en el árbol: no hace falta decirle el número. Si hay dos abiertos sobre el mismo repositorio y nada dice de cuál salió el árbol, no adivina: se dice con el número del requerimiento.

El agente y el modelo que elegiste se mantienen al mandar el primer mensaje: el plugin es el mismo desde cualquier carpeta —antes llevaba la rama del requerimiento abierto y, al cambiar, VS Code recargaba los agentes y la sesión volvía a «Agent»— y las conversaciones nuevas arrancan con KB también en la ventana de agentes (chat.newSession.defaultMode de usuario). El modelo es aparte: una sesión de la ventana de agentes corre en la Copilot CLI, que tiene su propia lista de modelos; si el elegido no está ahí, VS Code la pone en Auto.

Hooks para todos los agentes

kb init-repo siembra .github/hooks/kbspec.json: hooks de workspace que VS Code ejecuta para cualquier agente, sin depender de chat.useCustomAgentHooks. Hasta 3.148 los hooks vivían solo en el frontmatter de los agentes de fase, y ese ajuste —apagado por defecto— hacía que en la práctica no corrieran. Ahora corren siempre: la compuerta de rama, el barrido de secretos, el contexto al arrancar y al compactar, el tope de herramientas por conversación, el freno de bucle y el cierre de fase, con la fase resuelta desde el expediente (--fase auto).

kb init-repo deja además, en el repositorio, la aprobación automática de kb …, git status/diff/log y los builds en la terminal del agente (VS Code pide confirmarla una vez), y en los ajustes de usuario el modelo utilitario barato para títulos y resúmenes. Nada de eso pisa lo que el equipo ya decidió.

Claude Code

Con Claude Code en la máquina —o pedido con --ia claude—, kb init-repo deja en cada repositorio lo que Claude Code lee, sin tocar lo de Copilot:

las reglas: Claude Code lee AGENTS.md solo si no hay un CLAUDE.md; una regla en .claude/rules/00-kbspec.md se la trae igual (@../../AGENTS.md). Si el AGENTS.md es del equipo, ahí van las reglas de kbspec enteras;
las skills en .claude/skills/ —/kb y las de cada fase—;
las compuertas en .claude/settings.local.json: el juez antes de cada herramienta, las decisiones que la persona escribe en el chat, el contexto al arrancar y al compactar, y el cierre de cada turno. Ese archivo lo leen también la CLI de Copilot y el chat de VS Code, que tienen sus propios ganchos: ahí los de Claude ceden y no corren dos veces;
los permisos (3.206.0): los comandos kb, las lecturas de git y los builds y pruebas de siempre, sin preguntar —lo mismo que Copilot aprueba en su terminal—; las decisiones de la persona (kb finalizar, kb lote autorizar…), siempre preguntando. Lo que la persona ya tenía en el archivo no se toca;
el servidor MCP de kbspec (.mcp.json), habilitado sin el diálogo de cada sesión.

El consumo de Claude Code se mide de sus transcripciones (~/.claude/projects/), por la carpeta de cada sesión: lo que corrió en la carpeta de un requerimiento es de ese.

El lote en paralelo corre también con Claude Code (3.206.0): corredor = claude en CICLO.md —o solo, en una máquina con Claude Code y sin Copilot— lanza claude -p en el árbol de cada tarea, con el modelo del plan en el alias de Claude (opus, sonnet, haiku), las ediciones y la terminal permitidas, git push vedado, y los ganchos de kbspec del árbol juzgando cada herramienta.

Lo que kbspec no deja para Claude Code, a propósito: subagentes en .claude/agents/ —el chat de VS Code los mostraría junto a los del plugin de Copilot, dos veces cada uno; las lentes de /kb-revisar corren como subagentes con su texto— y una línea de estado propia, que pisaría la de la persona.

OpenCode

OpenCode no lee .claude/skills/: lee .opencode/commands/ y .opencode/agents/. Hasta 3.146 kbspec daba por hecho lo contrario y en OpenCode no aparecía ningún comando. Desde 3.147 kb init-repo genera, desde las mismas skills, lo que OpenCode sí lee — donde OpenCode está presente, o con --ia opencode:

.opencode/commands/ con /kb y los comandos de sesión (/kb-iniciar, /kb-abrir, /kb-estado, /kb-cerrar, /kb-publicar…). El nombre del archivo es el comando.
.opencode/agents/ con un agente por fase (mode: primary, porque una fase no se delega) y las cuatro lentes de revisión como subagent.
opencode.json con el servidor MCP, fusionado sin pisar los servidores del equipo.
La compuerta como plugin (.opencode/plugins/kbspec.js): intercepta edit/write/patch y le pregunta al mismo juez que usan Copilot y VS Code — kb hook pretool --fase auto.

La brecha honesta: el consumo no se mide desde OpenCode — no alimenta ninguna fuente que kb tokens sepa leer — y los agentes de OpenCode no fijan modelo, porque OpenCode los nombra proveedor/modelo y MODELOS.md tiene los nombres de Copilot y Claude Code.

El CLI es el único que escribe

Toda la lógica vive en un CLI en Python (kb). Skills, agentes, el servidor MCP y el panel de VS Code lo invocan; ninguno reimplementa nada. Eso mantiene una sola fuente de verdad y hace el comportamiento reproducible.