Playbooks paso a paso
Guías para pasar del manifest a herramientas funcionando
01 / path
Empieza aquí: despliega un release
Un release comienza en un repositorio Git con un hubbound.json v2. El camino seguro más corto es: define el deployment, ejecuta el preflight local y publica solo cuando el dry run esté limpio.
-
1. Crea el manifest del proyecto
Ejecuta hubbound init y agrega un deployment bajo deployments. Mantén las dependencias del proyecto bajo dependencies: son pins de instalación, no cosas que deploy publica.
-
2. Elige el contrato del artifact
Elige MCP, SKILL, SUBAGENT, HOOK o RULE. Su objeto content le dice a HubBound cómo aplicar el release a las herramientas soportadas; files selecciona el bundle.
-
3. Valida antes de mutar
Ejecuta hubbound deploy --dry-run --json. Esto revisa manifest, procedencia Git, rutas, archivos UTF-8 y límites del release sin llamar al backend de releases.
-
4. Publica y verifica
Autentícate, ejecuta deploy, guarda el resultado JSON y separa un release committed de su posterior proyección en el registry público.
02 / artifacts
Recetas de artifacts
Los artifacts son la unidad publicable más pequeña. El tipo cambia la forma de content y cómo los providers los materializan localmente; las reglas del release y de los archivos son las mismas.
Conecta un servidor de herramientas
Define transporte stdio o HTTP, referencias a entorno, secretos y permisos de tools.
Leer guía de MCP SKILLEmpaqueta una skill reusable
Envía un entrypoint como SKILL.md más referencias, scripts o assets de apoyo.
Leer guía de skill SUBAGENTDefine un agente especialista
Apunta a un archivo de instrucciones que las herramientas soportadas puedan registrar como subagent.
Leer guía de subagent HOOKEjecuta automatización en eventos
Conecta un entrypoint ejecutable seguro a un vocabulario de triggers independiente del provider.
Leer guía de hook RULEPublica instrucciones
Aplica markdown siempre, a archivos coincidentes o mediante la descripción de un smart trigger.
Leer guía de rule03 / composition
Receta de kit
Un kit es una composición versionada de artifacts. No contiene una segunda copia de cada blob: nombra deployments de artifacts locales y/o versiones exactas de tags remotos; install resuelve y aplica sus miembros.
Compón un bundle para el equipo
Construye un kit con deployments de artifacts locales y miembros remotos pineados, y publica la composición después de sus artifacts.
Leer guía de kits04 / model
El modelo mental
Mantén separadas estas cuatro capas. Muchos errores de deploy vienen de tratar un pin de dependencia, un paquete local y una entrada del registry público como si fueran lo mismo.
hubbound.json
La fuente de verdad para dependencias exactas y deployments locales nombrados.
Preflight
La barrera local de seguridad para schema, procedencia Git, rutas, tipo y tamaño de archivos.
Release
El flujo autenticado prepare/upload/commit que guarda la versión inmutable.
Install
El flujo consumidor que resuelve una versión, descarga miembros y materializa archivos del provider.