Qué es Open GSD, el flujo Git-Ship-Done para agentes de programación
Open GSD[1] es un conjunto de herramientas de código abierto para dirigir agentes de programación (Claude, Copilot, Cursor y compañía) sin perder el hilo del proyecto. El nombre resume su método: «Git. Ship. Done», o sea, versiona, publica y termina. En este artículo cuento qué problema ataca, cómo funciona su bucle de trabajo y en qué punto de madurez está, porque no todo lo que promete está disponible todavía.
Puntos clave
- Open GSD combate el deterioro del contexto: la caída de calidad que sufre un agente según se le llena la ventana de contexto.
- Estructura el trabajo en cinco pasos que se repiten: discutir, planificar, ejecutar, verificar y enviar.
- Delega la parte pesada (investigar, planificar, ejecutar) en subagentes con contexto limpio, para que la sesión principal no se sature.
- El núcleo son dos piezas ya maduras:
gsd-core, un motor de flujos para tu editor, ygsd-pi(versión 1.5.0), un agente autónomo de terminal. - Es software libre con licencia MIT y se instala desde npm.
El problema que resuelve
Cualquiera que haya usado un agente en una sesión larga conoce el patrón: al principio acierta y, según se llena su ventana de contexto, empieza a olvidar decisiones, a repetir trabajo o a irse por las ramas. En la documentación lo llaman «context rot», el deterioro del contexto. No es un fallo puntual, es el coste de acumular demasiada información en una sola conversación.
Open GSD parte de esa observación. En lugar de meterlo todo en una única sesión, separa el trabajo en fases y ejecuta cada tarea en un subagente que arranca con el contexto limpio. La sesión con la que hablas tú se mantiene ligera; el trabajo sucio ocurre aparte y vuelve resumido. La propia web lo resume así:
«Open GSD keeps agentic work from dissolving into context bloat: explicit plans, clean execution contexts, real verification, and git history that tells the truth.» — opengsd.net
El bucle de trabajo
El método se organiza en cinco pasos que se repiten en cada fase del proyecto:
- Discutir: se capturan las decisiones de implementación antes de planificar nada.
- Planificar: se investiga, se descompone la tarea y se comprueba que el plan cabe en una ventana de contexto nueva.
- Ejecutar: los planes se ejecutan en oleadas paralelas y cada ejecutor empieza con un contexto limpio.
- Verificar: se repasa lo construido, se diagnostica y se corrige antes de dar nada por terminado.
- Enviar: se abre la pull request, se archiva la fase y se pasa a la siguiente.
Si te suena, es porque es la misma disciplina que aplican otros sistemas de desarrollo con skills y subagentes. Lo que aporta Open GSD es empaquetarla con más de 60 comandos listos para usar.
Las herramientas
El proyecto se reparte en varias piezas y, a mediados de 2026, la mayoría ya son usables (no solo un par, como al principio):
| Pieza | Qué es | Estado |
|---|---|---|
gsd-core |
El motor de flujo para tu editor: investigar, planificar, ejecutar, verificar y enviar | Disponible |
gsd-pi |
El agente autónomo de terminal (versión 1.5.0): worktrees de Git, memoria de proyecto en .gsd/ e interfaz web opcional |
Disponible |
gsd-browser |
Automatización determinista del navegador, con aserciones y trazas | Disponible |
gsd-cursor |
Complemento para el marketplace de Cursor | Disponible |
gsd-cloud |
Espacio de trabajo hospedado, con un demonio que corre en tu máquina | En desarrollo |
gsd-pi es la puerta de entrada más rápida: se describe como un sistema de meta-prompting, ingeniería de contexto y desarrollo guiado por especificación, y funciona con el proveedor de modelos que le configures. Se prueba con un solo comando:
npx @opengsd/gsd-pi@latest
Mi lectura
Me convence el enfoque, en parte porque es el que ya seguimos aquí: si has montado un agente con el SDK de Anthropic o un RAG sobre Postgres, sabes que el cuello de botella no es el modelo, es mantener la concentración durante horas. Aislar cada tarea en un worktree y en un contexto propio es sensato y nada nuevo, pero tenerlo empaquetado con comandos y memoria de proyecto ahorra trabajo. Lo probé en un proyecto pequeño y la diferencia se nota sobre todo en sesiones largas: el plan queda por escrito y cada ejecutor arranca fresco, así que no hay que ir recordándole al agente lo que ya se decidió.
La parte honesta: aunque el catálogo ha crecido, el núcleo sigue siendo gsd-core y gsd-pi, y depende de que tu equipo ya tenga acceso a un proveedor de modelos, porque Open GSD trabaja con el que le configures y no trae uno propio. Si haces cambios pequeños y sueltos, la ceremonia sobra; si encadenas sesiones largas con agentes, compensa probarlo.
Preguntas frecuentes
¿En qué se diferencia de usar un agente a secas?
Un agente a secas lo mantiene todo en una sola conversación, que se degrada según se llena. Open GSD parte el trabajo en fases y ejecuta cada tarea en un subagente con el contexto limpio, así que la sesión principal no se satura. A cambio añade estructura: para un cambio pequeño puede resultar excesivo.
¿Cuesta dinero?
No. gsd-core y gsd-pi son software libre con licencia MIT y se instalan desde npm. Lo que sí necesitas es acceso a un proveedor de modelos (OpenAI, Anthropic u otro), porque Open GSD no incluye ninguno.
¿Con qué editores y agentes encaja?
gsd-core se integra en tu editor y gsd-pi vive en la terminal, así que sirve con Claude, Copilot, Cursor y el flujo que ya uses. El complemento gsd-cursor lo lleva además al marketplace de Cursor.
Conclusión
Open GSD no inventa una técnica nueva, pone orden en una que ya funciona: planificar en pequeño, ejecutar en contextos limpios y verificar antes de cerrar. Con licencia MIT y una instalación de un comando, el coste de probarlo es bajo. Merece un vistazo si trabajas a diario con agentes de programación; esta guía también está en inglés.
