Pídele un feature a tu repo desde la terminal, sin abrir el chat
Un agente de código en la terminal, como Claude Code o Codex, es bueno para lo que pide ida y vuelta con la persona: explorar un bug, ajustar un componente, probar una idea. Ese mismo agente es mala opción para un cambio largo y aislado, porque ocupa la sesión durante una hora y llena el contexto con pasos que a nadie le interesa revisar.
Desde la versión 0.72 del CLI de Ghosty, la terminal puede delegar ese cambio largo a la Software Factory: dos agentes que planean, construyen y revisan en su propia caja de trabajo. Este post muestra el flujo con comandos reales y el diseño que lo hace seguro para que un agente de código lo maneje solo.
La instalación son dos comandos y un login en el navegador
El paquete es @ghostystudio/cli, versión 0.73.0, y pide Node 22 o superior.
Sin instalación global también funciona:
ghosty login abre el navegador con OAuth2. Si el agente de código corre el login, ghosty login --json imprime primero una línea con la liga, y el agente se la pasa a la persona en el chat. En una máquina remota o en CI, ghosty login --device da una liga y un código.
Para que el agente de código aprenda los comandos, hay una skill:
Conectar el repo dice qué le falta para recibir agentes
Un repo se conecta a un room de Ghosty Teams. Con --create, el room se crea si no existe:
La línea «listo para agentes» es la parte útil para cualquier equipo. La calificación revisa nueve condiciones y en este ejemplo faltan cuatro: CI, archivo CODEOWNERS, Dependabot y rama principal protegida. Un repo sin CI le pide al agente que se revise a ojo. Un repo sin rama protegida deja que cualquier push llegue a producción.
rooms connect también revisa que la GitHub App de quien conecta vea el repo. Si la GitHub App no tiene acceso, el CLI da la liga para concedérselo.
Un pedido se escribe como un ticket: objetivo, motivo y criterio de cierre
factory run publica el pedido en el room conectado al repo, a nombre de quien llama, igual que si la persona lo escribiera en el chat. El plan, las firmas y la tarjeta son los mismos.
La ayuda del CLI recomienda escribir el pedido como un ticket: el objetivo, el porqué y cómo se sabe que quedó. La última parte es la más importante. El agente que planea convierte esa frase en el criterio de aceptación, y el agente que revisa aprueba o rechaza contra ese criterio.
Firmar exige la versión del plan que leíste
Con el plan listo, la persona lo lee y lo firma:
approve exige --plan-version. Si el agente que planea entregó otra versión mientras la persona leía, la firma se rechaza. El mismo patrón sirve para cualquier API que reciba aprobaciones: la aprobación va atada a la versión exacta que se revisó, nunca a «lo que haya en ese momento».
Si el plan no convence:
Esperar tiene tope y el código de salida dice qué pasó
--wait y watch regresan cuando el pedido necesita a una persona (firmar el plan, decidir tras un escalado, mezclar el PR) o cuando termina, e imprimen el siguiente comando. El tope por default es --timeout de 1800 s. Al vencer, el comando sale con código 1.
Los códigos de salida del CLI son cuatro:
Con --json, la salida estándar lleva sólo JSON y el error del servidor llega con su mensaje y una pista. Un agente de código que llama al CLI decide su siguiente paso por el código de salida, sin interpretar texto.
Cada acción queda en la bitácora con el nombre de quien la hizo
Cualquier miembro del espacio puede pedir, firmar y mezclar. Cada acción se registra en la bitácora de auditoría con su nombre: factory.run, factory.run_approve y factory.run_merge. Cuando un agente de código firma en nombre de una persona, el registro sigue apuntando a esa persona, porque el CLI usa la sesión de esa persona.
El mismo pedido se firma desde el teléfono
La app de Ghosty para iPhone tiene una pestaña Fábrica. La pestaña aparece sólo si alguno de tus espacios tiene pedidos, y su número en ámbar cuenta los pedidos que esperan una decisión tuya. Un pedido lanzado desde la terminal aparece ahí con su repo, su etapa, su PR, el tiempo que lleva y lo que ha costado en USD.
La lista se ordena en tres grupos: Te toca, Trabajando y Recientes. Dentro de cada pedido, una barra muestra en qué etapa va (plan, aprobación, construcción, revisión y PR), y debajo están el plan en markdown, lo que encontró la revisión y la bitácora. Las mismas decisiones del CLI están en botones: firmar el plan vN, pedir cambios, otra vuelta, replanear y mezclar, cada una con una confirmación antes de ejecutarse.
Cuando la fábrica necesita tu firma, llega una notificación push que abre directo el pedido. El flujo práctico queda así: pides desde la terminal con ghosty factory run, cierras la laptop y firmas el plan desde el teléfono cuando llega el aviso.
Lo que salió mal se diagnostica desde la misma terminal
Un pedido puede atorarse. runs show --timing dice en qué se fue el tiempo:
En ese pedido de ejemplo de la documentación, el trabajo de los agentes sumó 71.8 min y la espera por una persona sumó 3.0 h. La lectura honesta es que el cuello de botella de ese pedido fue la firma humana, no el modelo. El mismo reporte lista los comandos que tardaron 60 s o más; en el ejemplo, un comando de espera del constructor tardó 10.3 min.
runs why explica por qué falló un pedido. Antes de buscar atascos, runs why cruza los criterios del plan aprobado con la evidencia. Si el revisor aprobó un criterio «en la preview» sin preview lista, el diagnóstico sale arriba como approved_unmet_criterion. La categoría existe porque el 16 de octubre de 2026 un PR se aprobó sin la preview que exigía su plan y rompió las reservas de una app en producción.
runs stats resume la fábrica del espacio:
El resumen trae porcentaje mezclado, mediana hasta el PR, vueltas de revisión y costo por PR mezclado.
Qué conviene copiar aunque no uses este CLI
Si estás armando un CLI para que lo manejen agentes, estas decisiones nos han funcionado:
- Toda espera lleva tope. Un
--waitsin límite deja colgada la sesión del agente. - Códigos de salida distintos para error de API, uso incorrecto y sesión vencida. El agente reacciona distinto a cada uno.
--jsoncon stdout limpio y avisos a stderr.- Cada salida imprime el siguiente comando. El agente no tiene que adivinar el paso que sigue.
- Las aprobaciones llevan versión. Firmar algo distinto a lo que se leyó debe fallar.
- Cada acción con efecto queda auditada con el nombre de la persona dueña de la sesión.
En resumen
Delegar un cambio largo desde la terminal deja libre la sesión del agente de código para el trabajo que sí pide conversación. El flujo es conectar el repo, pedir con un criterio de cierre claro, firmar la versión exacta del plan, esperar con tope y mezclar. Lo que hace seguro que un agente maneje ese flujo son decisiones de diseño verificables: tope en cada espera, códigos de salida distintos, JSON limpio, aprobaciones atadas a una versión y bitácora con nombre.