Get Shit Done: ingeniería de contexto por fases para agentes de código

Todo lo que hay que saber sobre gsd-build/get-shit-done: el repositorio histórico de un flujo de desarrollo guiado por especificaciones que hoy redirige su desarrollo a open-gsd/gsd-core.

Qué es Get Shit Done

Get Shit Done (GSD) fue un sistema ligero de metaprompts, ingeniería de contexto y desarrollo guiado por especificaciones para agentes de programación. Su README histórico lo describe como una propuesta para Claude Code; el repositorio ya no contiene el código activo: desde mayo de 2026 muestra un aviso de traslado a open-gsd/gsd-core, que concentra código, incidencias, publicaciones y contribuciones.

La continuación, GSD Core, busca limitar la degradación de calidad que se acumula cuando una conversación del agente llena su ventana de contexto. Para ello conserva artefactos de proyecto, como STATE.md y CONTEXT.md, y desplaza investigación, planificación y ejecución intensivas a subagentes con contexto nuevo. Su README actual declara compatibilidad con Claude Code, OpenCode, Antigravity CLI, Kimi CLI, Kilo, Codex, Copilot, Cursor y Windsurf, entre otros.

Ventana de contexto traslúcida dividida en cámaras aisladas con agentes procesando tareas, junto a los archivos STATE.md y CONTEXT.md brillando en verde neón.

El origen: un repositorio popular que cambió de casa

La API de GitHub fecha la creación de gsd-build/get-shit-done el 14 de diciembre de 2025. Su descripción atribuye el sistema a TÂCHES, pero las fuentes recuperadas no identifican de forma verificable a una persona concreta tras ese nombre; por tanto, no se le atribuye autoría individual. Los mayores contribuidores de la API son trek-e (1.435 contribuciones), glittercowboy (945) y Tibsfox (127).

La historia reciente es más nítida que el lanzamiento inicial: el README del repositorio histórico comunica que GSD continuó como GSD Core en open-gsd/gsd-core. La API fecha este nuevo repositorio el 22 de mayo de 2026. No se recuperó un anuncio de lanzamiento con anécdotas del origen ni una publicación del equipo que explique la razón organizativa del traslado; más allá del aviso de migración, esa parte permanece sin verificar.

La transición también crea una tensión práctica: el repositorio de gran popularidad sigue siendo el que aparece en búsquedas y enlaces de la comunidad, mientras que las instrucciones actuales dicen explícitamente que no debe usarse para incidencias, versiones ni contribuciones. En otras palabras, las cifras del repositorio histórico no describen por sí solas el mantenimiento actual.

Escena cyberpunk de migración: una torre de servidor envejecida etiquetada gsd-build/get-shit-done conectada por un puente de datos neón a un núcleo nuevo y luminoso etiquetado open-gsd/gsd-core, con las fechas 14 dic 2025 y 22 may 2026 flotando.

Filosofía y principios

La propuesta se apoya en cinco pasos repetibles por fase:

Conversar: fijar decisiones de implementación antes de planificar.
Planificar: investigar, descomponer y comprobar que el plan cabe en un contexto nuevo.
Ejecutar: procesar planes en oleadas paralelas, con ejecutores de contexto limpio.
Verificar: revisar lo construido, diagnosticar fallos y corregirlos antes de declararlo terminado.
Entregar: crear la solicitud de cambios, archivar la fase y repetir el ciclo.

Infografía de cinco paneles holográficos que representan las fases Conversar, Planificar, Ejecutar, Verificar y Entregar, conectados por una línea de neón en bucle.

Es una filosofía de control de contexto y estado persistente, no una promesa de que cualquier agente produzca código correcto. El README actual sostiene que el problema operativo es la pérdida de información entre sesiones y la ausencia de verificación; los artefactos y la fase de verificación son su respuesta explícita.

Cómo funciona

La instalación actual se realiza con:

npx @opengsd/gsd-core@latest

El instalador pregunta por el entorno y por instalación global o local; la documentación desaconseja copiar directamente archivos de agents/ o commands/, porque la instalación adapta el paquete a cada entorno.

Terminal futurista mostrando el comando npx @opengsd/gsd-core@latest en verde neón, con iconos de entornos compatibles como Claude Code, Cursor y Windsurf conectados por hilos de luz.

Para iniciar un proyecto se usan, entre otros, estos comandos:

/gsd-new-project   # proyecto nuevo
/gsd-onboard       # base de código existente

El resultado del ciclo no es solo una conversación: GSD conserva decisiones y estado en archivos, divide el trabajo en fases y puede ejecutar planes en paralelo. La documentación de GSD Core afirma que cada ejecutor recibe un contexto limpio de hasta 200.000 tokens; esa es una característica declarada por el proyecto, no una medición independiente.

La última versión estable recuperada de GSD Core, v1.9.1 (31 de julio de 2026), añade un tipo de entrada para revisores externos y corrige, entre otros elementos, aislamiento de árboles de trabajo, instalación limpia para Codex y resolución de la raíz del proyecto. La versión histórica más reciente de gsd-build/get-shit-done fue la candidata v1.43.0-rc2, del 17 de mayo de 2026.

Estado oficial y semioficial

No se recuperó evidencia de que gsd-build/get-shit-done haya sido aceptado en un mercado oficial de Anthropic, OpenAI, GitHub, Cursor u otro proveedor. Tampoco se recuperó una declaración de aval de un fabricante. Por ello, no corresponde describirlo como plugin oficial ni como estándar formal.

Sí puede calificarse de referencia de facto dentro de una parte de la comunidad de flujos para agentes: el hilo de Hacker News de marzo de 2026 lo situó junto a Superpowers, OpenSpec y Spec Kit, y varios comentaristas lo utilizaron como punto de comparación. Esta condición describe uso y reconocimiento comunitario, no certificación de un proveedor ni validación de resultados.

El ecosistema

Repositorios mantenidos por las organizaciones de GSD

La API de GitHub recuperada el 2 de agosto de 2026 muestra una familia activa alrededor de la continuación Open GSD:

open-gsd/gsd-core: continuación principal; 7.558 estrellas y 518 bifurcaciones.
open-gsd/gsd-pi: adaptación para Pi; 989 estrellas y 88 bifurcaciones.
open-gsd/gsd-path: evolución disciplinada desde la idea hasta código entregado; 0 estrellas en la respuesta consultada.
open-gsd/gsd-spec-build-loop: habilidad de ciclo especificación → construcción → revisión; 5 estrellas.
open-gsd/gsd-browser: interfaz de línea de comandos para automatización de navegador basada en Chrome DevTools Protocol; 36 estrellas.
open-gsd/gsd-test-runner: ejecutor remoto de pruebas Node en contenedores; 9 estrellas.
open-gsd/gsd-cursor: plugin para el mercado de Cursor; 1 estrella.
open-gsd/marketplace-gsd-dev: mercado de OpenGSD; 2 estrellas.
open-gsd/gsd-cloud-daemon: demonio de GSD Cloud; 3 estrellas.

La organización anterior gsd-build conserva también gsd-2 (7.749 estrellas), agent-inbox (57), gsd-browser (251), daemon (8), context-packet (50), docs (2) y protocol-go (1). Los nombres y cifras proceden de la consulta de repositorios de esas organizaciones; no implican que todos tengan el mismo estado de soporte.

Puertos, bifurcaciones y extensiones de la comunidad

rokicool/gsd-opencode aparece en el README de GSD Core como el puerto original para OpenCode. No se recuperó su cifra de estrellas en esta ejecución.
itsjwill/gsd-pro, una bifurcación que anuncia enrutamiento multimodelo, recuperación y contexto adaptativo, tenía 79 estrellas y 16 bifurcaciones.
sudokku/gsd-watch, tablero en tiempo real para fases, tareas y sesiones con tmux, tenía 19 estrellas.
lgwanai/spec-skill se presenta en chino como una recreación profunda del flujo GSD y afirma interoperar los documentos de .planning con GSD; tenía 6 estrellas. Es un ejemplo verificable de adaptación no inglesa.
PCJIRON/gsd-qwen adapta GSD a la extensión Qwen Code; tenía 2 estrellas.
buildtheturfu/turfu-gsd declara en francés que parte de GSD y conserva fases de investigación, conversación, planificación, ejecución, verificación y entrega; su resultado de búsqueda mostraba 0 estrellas.
uublive/GSD-Locksmith añade coordinación de equipos para evitar colisiones de hitos y fases; el resultado mostraba 0 estrellas.
snipcodeit/mgw se define como orquestación de proyectos de GitHub sobre GSD, de incidencia a solicitud de cambios; mostraba 5 estrellas.

Estas bifurcaciones y extensiones son proyectos de terceros. Su existencia no equivale a aprobación del equipo de Open GSD.

Núcleo hexagonal luminoso de open-gsd/gsd-core rodeado de nodos satélite que representan repositorios como gsd-pi, gsd-browser, gsd-test-runner, gsd-pro y gsd-watch.

Números del repositorio

Medición: 2 de agosto de 2026, API pública de GitHub.

Métrica	`gsd-build/get-shit-done` histórico	`open-gsd/gsd-core` activo
Estrellas	64.783	7.558
Bifurcaciones	5.463	518
Suscriptores reales	266	31
Commits	2.928	4.898
Incidencias abiertas indicadas por API	0	150
Licencia	MIT	MIT
Creación	14 de diciembre de 2025	22 de mayo de 2026
Última actualización de metadatos	2 de agosto de 2026	2 de agosto de 2026
Última publicación recuperada	`v1.43.0-rc2`, 17 de mayo de 2026	`v1.9.1`, 31 de julio de 2026

Los totales de commits se derivan de la última página indicada por los enlaces de paginación de la API. En el repositorio histórico, el lenguaje principal de la API es JavaScript y el desglose recuperado contiene JavaScript, TypeScript y Shell. La API general replica las estrellas en watchers_count; por eso se informa subscribers_count como suscriptores reales. Su campo open_issues_count puede incluir solicitudes de cambios abiertas; no debe interpretarse como un conteo exclusivo de incidencias.

Los principales contribuidores del repositorio activo son trek-e (2.982 contribuciones), glittercowboy (945), Tibsfox (127), davesienkowski (125) y jeremymcs (122).

Como señal adicional de uso, npm informó 41.372 descargas de get-shit-done-cc entre el 2 y el 31 de julio de 2026, y 38.843 de @opengsd/gsd-core en el mismo intervalo. Las descargas no identifican instalaciones únicas ni éxito de uso.

Panel de control con dos gráficos de barras holográficos comparando las métricas del repositorio histórico y del repositorio activo, junto a una gráfica de descargas de npm.

Cómo contribuir

Las contribuciones deben dirigirse a open-gsd/gsd-core, no al repositorio archivado. La guía exige Node según .nvmrc, npm run check:env, npm ci y npm test; npm ci es obligatorio para respetar el archivo de bloqueo.

El proceso es explícitamente «incidencia antes de código». Para una corrección se abre primero un informe y se espera confirmación; para una mejora se necesita la etiqueta approved-enhancement; para una función nueva, una especificación aprobada y approved-feature. Después se crea una solicitud de cambios con la plantilla adecuada, pruebas y referencia a la incidencia. Casi todas las solicitudes se dirigen a la rama next; main queda para producción, correcciones críticas y lanzamientos. La guía indica que las solicitudes sin incidencia aprobada se cierran automáticamente y que CI debe quedar en verde.

Diagrama de flujo cyberpunk del proceso de contribución: un informe de incidencia avanza hacia una mejora aprobada, una solicitud de cambios y finalmente un estado de CI en verde, con las ramas next y main divergiendo al final.

Cómo lo recibió la comunidad

El envío de Hacker News 47417804, publicado por stefankuehnel el 17 de marzo de 2026, alcanzó 473 puntos y 253 comentarios según la búsqueda de Algolia; la consulta directa del elemento recuperó 65 comentarios en la respuesta disponible. La discrepancia es una limitación observable de las respuestas recuperadas, por lo que no se usa el segundo número como total definitivo.

Terminal de Hacker News con un contador de puntos subiendo a 473 y burbujas de comentarios que mezclan reacciones favorables y críticas sobre coste y límites de sesión.

La recepción fue claramente mixta y ofrece ejemplos concretos:

yoaviram afirmó que GSD le llevaba «el 95 %» en tareas complejas y que lo usaron para lanzar un producto SaaS; añadió que los modelos también habían mejorado durante el período. Es entusiasmo basado en experiencia personal, no una evaluación controlada.
schnitzelstoat, en el hilo 48019025, dijo que la herramienta le ayudó a planificar y a mantener el contexto pequeño, aunque era más lenta que usar Claude directamente. Ese hilo registraba 270 puntos y 40 comentarios en el elemento recuperado.
anentropic valoró que el sistema haga preguntas y gestione contexto, pero señaló que no permite simplemente lanzar una tarea y olvidarse de ella, y que relee bastante sus propios archivos de planificación.
La crítica más repetida fue el coste. MeetingsBrowser dijo que no obtuvo una mejora medible frente a instrucciones directas y alcanzó límites de sesión en unos 30 minutos; gtirloni estimó en su experiencia un consumo de diez veces más tokens; vinnymac criticó el tiempo de interacción y la planificación excesiva.
ibrahim_h objetó que la recomendación histórica de ejecutar con --dangerously-skip-permissions puede abrir una superficie de riesgo: según su lectura, el comprobador de planes revisa completitud lógica, no todos los comandos generados. Es una crítica técnica atribuida a ese comentarista; no se validó mediante auditoría independiente en esta ejecución.
Andrei_dev cuestionó que generar mucho código equivale a revisarlo bien y citó riesgos como credenciales codificadas y rutas sin autenticación. joegaebel sostuvo que las especificaciones en lenguaje natural no sustituyen pruebas automatizadas. Ambas son objeciones de participantes, no defectos confirmados del proyecto.

Get Shit Done frente a otras propuestas

Propuesta	Coincidencia verificable	Diferencia verificable o límite de la comparación
`obra/superpowers`	En el hilo de HN, varios participantes lo compararon con GSD como flujo estructurado para agentes.	`gtirloni` dijo preferir el modo de planificación nativo y asoció ambos marcos con mayor gasto de tokens; no se recuperó una prueba independiente que establezca un ganador.
`github/spec-kit`	`bgnm2000` y `ochronus` lo enumeraron junto a GSD como herramienta de planificación o desarrollo guiado por especificaciones.	Las fuentes recuperadas solo prueban que la comunidad los agrupa; no bastan para afirmar equivalencia de arquitectura o rendimiento.
OpenSpec	`gbrindisi` afirmó preferirlo porque permite ajustar el flujo progresivamente.	Esa es una preferencia de usuario, no una comparación experimental; GSD se diferencia aquí por su ciclo de fases y artefactos documentados.
`ChristopherKahler/paul`	`jankhg` lo presentó como otra alternativa y enlazó una comparación en su repositorio.	El comentarista dijo que PAUL evita subagentes y por ello podría requerir menos tokens; no se recuperó ni verificó el estudio enlazado.
`buildomator/buildomator`	Se describe como un flujo planificar → ejecutar → verificar para Claude Code y declara evolucionar desde GSD.	La descripción de GitHub anuncia estado de proyecto mediante MCP y detección de desviaciones; tenía 83 estrellas, pero sus promesas de ahorro de tokens no fueron verificadas.

Casos de uso y a quién puede ayudar este repositorio

Equipos que inician una base de código o incorporan un proyecto existente a un flujo de agentes pueden instalar la continuación activa con npx @opengsd/gsd-core@latest y comenzar con /gsd-new-project o /gsd-onboard. El ciclo de conversar, planificar, ejecutar, verificar y entregar deja decisiones y estado en artefactos como CONTEXT.md y STATE.md, divide el trabajo por fases y permite que ejecutores con contexto nuevo procesen planes en oleadas.

Mantenedores que necesitan contribuir o actualizar GSD deben trabajar en open-gsd/gsd-core, no en el repositorio histórico: preparar el entorno con .nvmrc, ejecutar npm run check:env, npm ci y npm test, abrir una incidencia antes del código y dirigir la mayoría de solicitudes a next. El repositorio también puede servir a quienes comparan flujos guiados por especificaciones, pero conviene valorar el coste de tokens, la planificación adicional y los permisos de ejecución antes de aplicarlo a tareas pequeñas o sensibles.

Recursos

Repositorio histórico: https://github.com/gsd-build/get-shit-done
Código, incidencias y publicaciones actuales: https://github.com/open-gsd/gsd-core
Documentación e instalación: https://github.com/open-gsd/gsd-core#quickstart
Comandos y configuración: https://github.com/open-gsd/gsd-core/tree/main/docs
Guía oficial de contribución: https://github.com/open-gsd/gsd-core/blob/main/CONTRIBUTING.md
Habilidades y flujo oficiales: https://github.com/open-gsd/gsd-core/tree/main/agents
Comunidad Discord: https://discord.gg/mYgfVNfA2r
Conversación y reseñas comunitarias: https://news.ycombinator.com/item?id=47417804, https://news.ycombinator.com/item?id=48019025

Nota: este artículo combina los README y guías de contribución de GSD, la API de GitHub, la API de npm y datos de Hacker News recuperados el 2 de agosto de 2026. Las cifras cambian con el tiempo.