Cursor

Hasta la 3.216 Cursor entraba por «universal»: leía las skills de .agents/skills/ y AGENTS.md, y trabajaba sin juez. Desde la 3.217.0 kbspec gobierna el trabajo de Cursor —el editor y cursor-agent— igual que el de Copilot y Claude Code: el mismo ciclo, las mismas skills y el mismo juez antes de cada herramienta.

kb init-repo --ia cursor

Qué deja en el repositorio

Archivo	Para qué
.agents/skills/	Las mismas skills de kbspec, en la ruta compartida que Cursor lee (si «universal» no las puso ya).
.cursor/rules/00-kbspec.mdc	Una regla corta siempre activa (alwaysApply: true): el modelo sabe desde el primer mensaje que kbspec manda, dónde están las reglas y qué hacer con una herramienta denegada.
.cursor/mcp.json	El servidor MCP de kbspec, el mismo que .mcp.json.
.cursor/hooks.json	Los ganchos, en el esquema de Cursor: la compuerta (preToolUse, sin matcher), el contexto al arrancar (sessionStart), las decisiones que la persona escribe (beforeSubmitPrompt) y el cierre de fase (stop).
AGENTS.md	Las reglas del proceso. Cursor lo carga solo.

Nada de eso se commitea: queda en .git/info/exclude, como el resto de lo que genera kbspec. Si el equipo ya tiene un .cursor/hooks.json con sus propios ganchos, se fusiona: los del equipo quedan intactos, los de kbspec se reemplazan y no se duplican, y un archivo que no es JSON válido no se toca —se dice qué agregar a mano—.

Con --ia todos, Cursor se prepara solo donde se usa: si el repositorio ya tiene .cursor/, la máquina tiene ~/.cursor/ o cursor/cursor-agent en el PATH (KB_CURSOR=1 o KB_CURSOR=0 manda). kb update mantiene todo al día y kb check lo revisa («Cursor gobernado por kbspec»).

La compuerta

Es el mismo juez que en Copilot y Claude Code (kb hook pretool). Frena los comandos que corre una persona (kb ciclo aprobar, kb pr aprobado…), los secretos antes de que el archivo exista, las rutas vedadas, el código en una fase cuyo producto es el expediente y el código en la rama equivocada.

Lo que cambia es la respuesta. Cursor lee cada gancho en su propio esquema, y en preToolUse un stdout vacío o un JSON que no case bloquea la herramienta: por eso permitir también se dice ({"permission": "allow"}), y negar es permission: deny con el motivo en agent_message —le llega al modelo en la misma negación— y en user_message, saliendo con código 0. kb hook … --agente cursor captura lo que la compuerta imprime en el esquema de Claude Code y lo traduce; así cada compuerta nueva también le niega a Cursor.

Lo que hay que saber

• El sessionStart de Cursor no espera al gancho: el contexto del requerimiento llega, pero el agente ya arrancó. La regla siempre activa es la que lo cubre desde el primer turno; el contexto completo (fase, qué falta, cómo se trabaja) llega enseguida.
• Cursor puede correr también los ganchos de .claude/settings.local.json («ganchos de terceros»), con CLAUDE_PROJECT_DIR como alias de CURSOR_PROJECT_DIR. Donde .cursor/hooks.json ya trae el juez, los de kbspec ceden ahí: una compuerta por herramienta, no dos.
• beforeSubmitPrompt no inyecta contexto: la decisión que la persona escribe («aprobado 02») se registra igual; lo que falta por resolver lo dice el agente con kb estado.
• La terminal de Cursor dice TERM_PROGRAM=vscode, como VS Code. kb abrir la reconoce (CURSOR_TRACE_ID, la ruta de su askpass) y abre el workspace con cursor, no con code.
• cursor-agent (el lote), el modelo por fase (MODELOS.md), el consumo y el panel en Cursor vienen en etapas siguientes.