bond v1.10.0

Llega el modo hub: un repo de operaciones que agrupa otros repos (como submódulos o como
symlinks a tus clones) y trabaja con ellos en vertical, con una rama del mismo nombre en todos y
un agente por repo. La web estrena diseño y una página de novedades con un vídeo del modo hub.

• hub.toml, la sesión del hub: el nombre y la base del hub y, por repo, path, base,
  link = "submodule" o "symlink", url, agent y description. Las rutas a tus clones van
  en .bond/hub.local.toml (en .gitignore, admite ~), y ~/.bond/hubs.toml permite encontrar
  el hub desde un repo enlazado por symlink.
• bond hub init, asistente para crear un hub o prepararlo en un repo que ya existe:
  • primero hace bond init en el propio hub (con plan-team y la memoria de decisiones, para
    que los runs del equipo queden en el hub);
  • importa los submódulos que ya hubiera y añade repos por URL (submódulo) o desde un clon local
    (symlink), que se elige navegando por el disco; los repos nuevos van en repos/<nombre>;
  • hace bond init con la config del hub en los repos que no tienen bond (los que ya lo tienen
    conservan la suya) y commitea esa config si el repo estaba limpio; en un submódulo avisa de
    que ese commit hay que subirlo con git push antes que el hub;
  • deja un hub nuevo con su config generada y un commit inicial.
• bond hub add <url|ruta> añade un repo (--path, --base, --link, --agent,
  --description); bond hub sync deja el disco como dice hub.toml (junctions en Windows
  si no se puede crear el symlink) y hace el bond init que falte; bond hub enseña la
  sesión.
• bond hub check revisa cada repo de la sesión y dice cómo arreglar lo que falla: enlace,
  base, bond init y config, agentes, worktrees, cambios sin commitear y ramas verticales a
  medias. Los avisos (un repo fuera de repos/, una base atrasada respecto a su remoto) no
  cambian el código de salida. --fix arregla lo seguro (enlaces y submódulos sin iniciar),
  pregunta antes de cada cambio salvo con --yes, y nunca descarta cambios ni cambia de rama.
  --json da un level (ok, warn o fail) por comprobación, por repo y por informe, como
  bond doctor, que resume el hub en su fila.
• bond hub pull pone al día la base del hub y de cada repo con git fetch y avance solo en
  fast-forward; si la base no está en uso en ningún worktree (un submódulo con HEAD separado),
  avanza la rama sin tocar la carpeta de trabajo. Salta, explicando por qué, lo que tiene cambios
  o ha divergido; nunca hace merge, rebase ni push.
• En un hub, bond sync genera en su AGENTS.md un bloque (bond:hub) con la tabla de
  repos y las reglas del hub, para que el orquestador sepa qué es cada repo; lo que escribas fuera
  del bloque se conserva.
• bond team en un hub: bond team fix/x abre una rama vertical, con un worktree y un agente
  en cada repo de la sesión (o en los de --repos), cada uno desde su base; solo cabe una abierta
  a la vez. bond team prompt manda la tarea a todos con una nota que nombra a los demás agentes;
  collect --repo guarda los runs en el hub y clean lo deja todo como estaba. status y la
  tabla en vivo (tabla · <hub>) enseñan toda la sesión, también desde dentro de un repo.
• Las skills plan-team y bond-team saben trabajar en un hub: una fase o tarea es una rama
  vertical, se ponen al día las bases antes de abrirla y se recoge repo a repo. Al integrar
  recuerdan subir los punteros de los submódulos, sin hacerlo ellas.
• bond team prompt reintenta una vez un encargo que no llega a un agente recién arrancado
  (agent_prompt_stalled) y, si vuelve a fallar, da error en lugar de un aviso.
• La skill global bond-team vuelve a cargar en pi: su description no era YAML válido. Una
  prueba comprueba ahora el frontmatter de todas las skills globales.
• bond dentro de su propio workspace de Herdr abre el agente por defecto (o el de --agent) en
  el panel donde lo escribes, en la raíz del repo; al salir del agente vuelves a la shell. Antes
  solo decía que el workspace ya estaba abierto.
• La web (josecorral.dev/bond) estrena diseño y logo, y una página de Novedades / What's
  new con el modo hub y un vídeo en castellano y otro en inglés.

Instalar

curl -fsSL https://raw.githubusercontent.com/jmanuelcorral/bond/main/install.sh | sh

Windows: irm https://raw.githubusercontent.com/jmanuelcorral/bond/main/install.ps1 | iex

bond v1.9.1

• bond init y el asistente de bond setup ya ofrecen Antigravity (agy) cuando su instalador
  lo deja en ~/.local/bin y esa carpeta no está en el PATH, como ya hacían bond doctor y
  bond team. Antes no salía en la lista de agentes.

Instalar

curl -fsSL https://raw.githubusercontent.com/jmanuelcorral/bond/main/install.sh | sh

Windows: irm https://raw.githubusercontent.com/jmanuelcorral/bond/main/install.ps1 | iex

bond v1.9.0

Antigravity (agy) entra en bond como un agente más, también en equipos, y aceptar decisiones
deja de pedirte una segunda validación: lo que apruebas en la conversación queda aceptado.

• Antigravity (agy) como agente del repo: bond init --agents agy y bond sync generan un
  plugin de bond en .agents/plugins/bond/ con los servidores MCP (del catálogo y los de
  [mcp_servers]) y los comandos del catálogo y propios, cada uno como skill (/commit,
  /review...). agy ya leía AGENTS.md y .agents/skills/ por su cuenta. Quitar agy de
  agents borra el plugin. bond doctor enseña la versión de agy y avisa si no está
  instalado o si está en ~/.local/bin pero fuera del PATH.
• bond setup con agy: deja un plugin global, bond-global, en
  ~/.gemini/config/plugins/bond/ con tus instrucciones, las reglas de bond y las skills
  bond-delegate, bond-team y herdr, así que agy las carga en cualquier repo. Instala
  también la integración antigravity-cli de Herdr, y bond doctor comprueba las dos cosas. No
  toca nada más de ~/.gemini/config/; sin agy entre tus agentes, no crea nada.
• agy en equipos y delegaciones (bond team <rama>:agy, skill bond-delegate):
  • arranca aunque solo esté en ~/.local/bin (bond añade esa carpeta al PATH de la shell del
    panel) y con --dangerously-skip-permissions, porque sin él pide permiso por cada comando y
    no avanza; tus argumentos tras -- lo sustituyen;
  • si agy pregunta si confías en la carpeta, la rama sale bloqueado y prompt no manda
    nada; el aviso de novedades al arrancar («esc to dismiss») ya no cuenta como pregunta;
  • bond team collect toma su respuesta de la conversación de agy (con la integración de
    Herdr) o, si no, del panel, sin el banner, el encargo repetido ni las líneas de herramientas.
• Confianza del orquestador en bond team: si el agente del panel que lanza el equipo (pi,
  Claude Code o agy) confía en el checkout principal, todos los agentes pi, Claude Code y agy
  del equipo arrancan confiando en su worktree, aunque su agente no hubiera abierto nunca el
  repo (en agy, en trustedWorkspaces de ~/.gemini/antigravity-cli/settings.json). Sin esa
  confianza, cada agente hereda la que él mismo daba al checkout, como hasta ahora; --no-trust
  lo desactiva.
• Aceptar al aprobar: bond decisions add (y record_decision en pi) admite
  --confirmed-by "<lo que dijo el usuario>" (confirmed_by en el JSON) y registra la
  decisión ya accepted, con esa cita y accepted_via. Las skills plan-create,
  decision-record, plan-execute y convention-document lo usan: las decisiones que apruebas
  con un plan quedan aceptadas sin tener que aceptarlas otra vez; solo quedan proposed las que
  un agente toma por su cuenta.
• Sin cuadro de permiso para aceptar: bond sync ya no deja reglas ask para bond decisions accept, reject y supersede en .claude/settings.json, y quita las que dejó la 1.8.0
  conservando las tuyas. Si lo has pedido por chat, no hay que validar el comando otra vez.
• bond team collect con agentes Claude Code: toma el informe de su transcript
  (~/.claude/projects/*/<sesión>.jsonl) en vez del panel; cuenta como decisiones del agente
  solo las firmadas agent:<kind>/<nombre> que no estaban en la base (antes sumaba las del
  orquestador del mismo tipo y las ya existentes); y compara con la base guardada al mandar el
  encargo, así que recoger después de integrar la rama sigue mostrando sus commits y decisiones.
• bond decisions check mira solo los trailers Decision: de la rama actual: antes leía los de
  todas las ramas y, con agentes en paralelo, una rama fallaba por las decisiones de otra.

Instalar

curl -fsSL https://raw.githubusercontent.com/jmanuelcorral/bond/main/install.sh | sh

Windows: irm https://raw.githubusercontent.com/jmanuelcorral/bond/main/install.ps1 | iex

bond v1.8.0

Aceptar decisiones sin salir de la conversación con tu agente: le dices cuáles aceptas y queda
constancia de que lo pediste tú y de quién lo ejecutó.

• bond decisions accept, reject y supersede admiten --confirmed-by "<lo que dijo el usuario>" y con él no necesitan terminal. La decisión guarda esa referencia en accepted_by
  y en accepted_via quién lo ejecutó (agent:<kind>/<nombre> desde un panel de Herdr, user
  fuera); check valida su formato. Aceptan varios ids y --all-proposed: un id desconocido o
  que no está proposed se informa sin cortar los demás, y la salida es distinta de 0 si alguno
  falla. Sin terminal y sin --confirmed-by se siguen negando, y un --confirmed-by vacío se
  rechaza.
• Comando nuevo del catálogo, /accept: enseña las decisiones proposed, te pregunta cuáles
  quieres y solo entonces las acepta, rechaza o sustituye citando tus palabras.
• En Claude Code, con [decisions], bond sync añade a .claude/settings.json reglas ask
  para accept, reject y supersede: cada una pasa por el cuadro de permiso de Claude Code.
  Se fusionan con las reglas del repo sin pisarlas, y al quitar [decisions] solo se van las de
  bond.
• bond decisions supersede dejaba en supersedes de la decisión nueva su propio id en lugar
  del de la sustituida.
• El comentario de [decisions] que escribe bond init en .bond/bond.toml ya no habla de un
  índice en el README (desde la 1.7.0 no lo hay) y dice que los trailers Agent: y Decision:
  son opcionales.

Instalar

curl -fsSL https://raw.githubusercontent.com/jmanuelcorral/bond/main/install.sh | sh

Windows: irm https://raw.githubusercontent.com/jmanuelcorral/bond/main/install.ps1 | iex

bond v1.7.0

Memoria de decisiones de los agentes: en un repo con bond, las decisiones, los encargos a otros
agentes y lo que respondieron quedan por escrito en el repo, para auditar después qué hizo cada
uno. La escritura la hace bond, no el modelo: funciona también con modelos locales que no
siguen formatos a mano.

• Se activa por repo con la sección [decisions] de .bond/bond.toml (dir = "docs/decisions",
  ajustable dentro del repo). bond init la propone cuando eliges la skill decision-record,
  marcada por defecto; al reinicializar, una sección que ya tuvieras se conserva. bond sync
  crea <dir>/README.md con el formato si falta; después es del repo. Sin [decisions], nada
  cambia.
• bond decisions add registra una decisión: el agente pasa el título, el contexto, la decisión
  y, si las hay, alternativas, consecuencias y enlaces (por flags o JSON con --stdin), y bond
  escribe <dir>/<YYYY-MM-DD-slug>.md con su frontmatter, la rama y el HEAD. La autoría la pone
  bond: en un panel de Herdr, el agente de ese panel (agent:pi/kevin); fuera, user. Siempre
  entra como proposed.
• bond decisions accept, reject y supersede son del usuario: piden terminal interactiva y
  confirmación, y se niegan desde el shell de un agente. Evita aceptaciones por descuido; no es
  una medida de seguridad (la integridad la da git).
• Para auditar: bond decisions lista (--status, --agent, --json), show <id> enseña una
  decisión o un run, runs lista los encargos y check valida frontmatter, ids, sustituciones y
  trailers Decision: (sale con 1 si hay errores). bond doctor añade una fila con los errores
  y las decisiones pendientes de aceptar.
• En pi, la herramienta record_decision (Bond Extensions) llama a bond decisions add.
• Encargos e informes: con la memoria activa, bond team prompt guarda el encargo exacto en
  <dir>/runs/ antes de mandarlo (--no-record para no guardarlo; si falla al escribir, avisa
  y manda el prompt igual) y le pide al agente que commitee en su rama lo que registre. La nueva
  bond team collect <rama> guarda en el run la última respuesta del agente (de su fichero de
  sesión o, si no se puede, del panel sin el banner de arranque), el estado, los commits de la
  rama y las decisiones de ese agente; se niega mientras el agente trabaja o espera una respuesta
  y repetirlo no duplica nada. Con --request y --agent sirve también para delegaciones sin
  equipo.
• Las decisiones viajan con la rama y se revisan con el código; no hay un índice compartido que
  dé conflictos entre agentes en paralelo.
• Skills: decision-record es nueva; plan-create, plan-execute, git-conventional-commit,
  delivery-review-github y convention-document registran y enlazan sus decisiones con la
  herramienta; bond-team, plan-team y bond-delegate guardan encargos e informes con
  prompt y collect. Con la memoria activa, los commits pueden llevar los trailers opcionales
  Agent: y Decision:; sin ella, las skills no firman nada. Una regla global de bond setup
  pide usar la memoria en los repos que la tienen.
• bond catalog check falla si el frontmatter de una skill no es YAML válido (por ejemplo, una
  description sin comillas con : dentro), que pi se niega a cargar aunque Claude Code lo
  tolere.

Instalar

curl -fsSL https://raw.githubusercontent.com/jmanuelcorral/bond/main/install.sh | sh

Windows: irm https://raw.githubusercontent.com/jmanuelcorral/bond/main/install.ps1 | iex

bond v1.6.3

• bond team status da por integrada una rama que entró en la base por fast-forward o con un
  merge (antes salía sin commits, como si no hubiera empezado), y por eso bond team clean
  sin argumentos ya la quita. Lo distingue el reflog de la rama: si avanzó desde que se creó, ya
  trabajó. Una rama recién creada sigue saliendo sin commits.
• Nuevo vídeo en la web (https://josecorral.dev/bond/): Claude, solo en su panel, planifica una
  web, la reparte entre dos agentes pi con bond team, revisa, integra y limpia el equipo.

Instalar

curl -fsSL https://raw.githubusercontent.com/jmanuelcorral/bond/main/install.sh | sh

Windows: irm https://raw.githubusercontent.com/jmanuelcorral/bond/main/install.ps1 | iex

bond v1.6.2

• La tool repo_map de pi (y el script repo-map de la skill code-context) ya no falla en
  repos con mucha historia: la lista de ficheros más tocados cortaba la tubería con head y,
  con pipefail, el script terminaba con error (SIGPIPE) aunque hubiera escrito el mapa.
• La web de la documentación (https://josecorral.dev/bond/) tiene vídeos de bond en acción sobre
  un proyecto real: bond init, el puesto de trabajo, un equipo de agentes y los catálogos.

Instalar

curl -fsSL https://raw.githubusercontent.com/jmanuelcorral/bond/main/install.sh | sh

Windows: irm https://raw.githubusercontent.com/jmanuelcorral/bond/main/install.ps1 | iex

bond v1.6.1

• bond init interactivo vuelve a marcar de partida lo que el repo ya usa (o, en un repo nuevo,
  lo del catálogo por defecto). En la 1.6.0 la lista salía sin marcar y, si confirmabas sin
  tocarla, guardaba lo del catálogo de bond con prefijo ("bond:context7" en vez de
  "context7"): funcionaba, pero no era lo esperado. Un bond.toml con esos prefijos sigue
  valiendo; bond init lo deja otra vez con los nombres a secas.
• La documentación tiene web propia, en castellano e inglés: https://josecorral.dev/bond/
  (los mismos docs/, con buscador).

Instalar

curl -fsSL https://raw.githubusercontent.com/jmanuelcorral/bond/main/install.sh | sh

Windows: irm https://raw.githubusercontent.com/jmanuelcorral/bond/main/install.ps1 | iex

bond v1.6.0

Catálogos del equipo: un equipo reúne en un repo sus skills, comandos y servidores MCP, y cada
proyecto lo usa con bond como usa el catálogo de bond.

• bond catalog create: prepara el repo actual como catálogo propio de un equipo. Pregunta el
  nombre (por defecto, el de la carpeta; --name para no preguntar) y crea catalog.toml y
  las carpetas skills/, commands/ y mcps/, cada una con un README.md que explica cómo
  añadir lo suyo. No mete ejemplos instalables. Si ya hay catalog.toml, no lo toca y solo
  añade lo que falte.
• bond catalog check [dir]: comprueba un catálogo (skills con SKILL.md y name igual a su
  carpeta, comandos con description, servidores MCP con command o url, entradas de
  catalog.toml que existen) y sale con 1 si hay errores, para CI. Avisa de secretos escritos
  tal cual en env o headers.
• Catálogos del equipo en un repo: [[catalog]] con path en .bond/bond.toml. Sus skills,
  comandos y servidores MCP salen en bond init (y en --list, con el nombre del catálogo) y
  bond sync los genera para cada agente como los del catálogo de bond; en pi, sus comandos van
  a .pi/prompts/. Con el mismo nombre que una de bond, gana la del equipo (bond:nombre pide
  la de bond); en dos catálogos del equipo, se elige con catalogo:nombre. sync
  valida el catálogo como bond catalog check y no escribe nada si tiene errores; avisa si la
  carpeta está fuera del repo. Sin [[catalog]], nada cambia.
• Catálogos del equipo por git: bond catalog add <url> [--ref tag|rama|sha] los declara en
  .bond/bond.toml ([[catalog]] con name, git y ref) y fija el commit en
  .bond/lock.json, que se commitea. sync usa ese commit (aunque la rama avance) y lo descarga
  a ~/.bond/catalogs/ si falta; con la caché llena funciona sin red. bond catalog update
  vuelve a resolver la ref y mueve el lock; list, remove (quita también lo elegido de él) y
  clean (poda la caché). add y update enseñan antes los servidores MCP que llegan o cambian
  y lo que pasa a venir de otro catálogo, y piden confirmación (--yes). add también acepta
  una carpeta ([[catalog]] path).
• bond doctor añade una fila por cada catálogo del equipo en .bond/bond.toml: el commit
  fijado en .bond/lock.json, si está descargado en ~/.bond/catalogs y si la ref tiene un
  commit más nuevo (avisa con bond catalog update <nombre>; con --quick o sin acceso, «sin
  verificar» — no toca la red). Los catálogos locales salen con su carpeta, y falla si no
  existe.
• bond doctor ya no se corta cuando .bond/bond.toml, .bond/lock.json o un catálogo del
  equipo no valen (lock ilegible o que no cuadra, catálogo con errores, nombre desconocido): la
  fila «repo» falla con el motivo y el arreglo, y el resto de comprobaciones, incluida la fila
  de cada catálogo, sale igual.
• Skill nueva en el catálogo de bond: catalog-maintain (opcional, default = false). Ayuda a
  llenar y mantener un catálogo de equipo creado con bond catalog create: añadir skills,
  comandos y servidores MCP con el formato de los README.md que create deja en cada
  carpeta, mantener catalog.toml y pasar bond catalog check antes de publicar. No duplica
  la estructura que ya da create.
• Los servidores MCP del catálogo van ahora en un fichero por servidor (catalog/mcps/<nombre>.json
  en lugar de catalog/mcp.json), el mismo formato que los catálogos propios. Lo que genera
  bond sync no cambia.
• Documentado el ciclo de vida de los catálogos externos (crear, comprobar, publicar, añadir,
  sincronizar, actualizar y diagnosticar) con las notas de seguridad y de CI con repos privados
  en docs/reference.md; atajo para equipos en docs/getting-started.md.

Instalar

curl -fsSL https://raw.githubusercontent.com/jmanuelcorral/bond/main/install.sh | sh

Windows: irm https://raw.githubusercontent.com/jmanuelcorral/bond/main/install.ps1 | iex

bond v1.5.1

• bond doctor: ejecutándose desde el repo de bond, si ~/.bond/pi apunta a un runtime
  instalado (~/.bond/runtime/<versión> con su marca .complete) la fila «Bond Extensions»
  avisa en vez de fallar: pi está usando las extensiones de esa versión instalada y no las
  del repo en desarrollo. Sigue fallando si el destino no es ni el repo ni un runtime válido.

Instalar

curl -fsSL https://raw.githubusercontent.com/jmanuelcorral/bond/main/install.sh | sh

Windows: irm https://raw.githubusercontent.com/jmanuelcorral/bond/main/install.ps1 | iex