GSD: romper el trabajo antes de que el contexto se pudra

Hay una patología silenciosa en cualquier sesión larga con un agente de código: conforme la ventana de contexto se llena, la calidad baja. No de golpe, no con un error visible. Baja como baja la pila de un celular viejo — de pronto el modelo “olvida” una decisión que tomó hace veinte turnos, reinventa un archivo que ya existía, o insiste en un patrón que ya habíamos descartado.

Ese fenómeno tiene nombre: context rot. Y GSD — Get Shit Done — es un framework open source que lo toma como el enemigo principal. No promete magia. Promete disciplina: partir el trabajo en unidades atómicas y darle a cada una un subagente con contexto limpio de 200k tokens. Lo revisamos sin instalarlo, para saber si vale la pena el paso siguiente.

· gsd-build/get-shit-done · MIT

Qué hace realmente

La etiqueta de moda es context engineering. Traducido: no le metas todo al agente, cúrale el contexto que recibe en cada paso. GSD lleva eso a una forma concreta — lo que llama fases atómicas. En lugar de una sesión monolítica donde el agente arrastra cada decisión, cada archivo leído y cada error antiguo, GSD obliga a que el trabajo se divida en fases con inicio, fin y verificación. Cada fase corre en su propia cabeza.

La filosofía hermana es Superpowers — de hecho GSD se posiciona como complemento, no reemplazo. Donde Superpowers empuja skills horizontales (TDD, code review, debugging como práctica), GSD empuja gestión vertical del ciclo de trabajo: planear una fase, ejecutarla, verificarla, despachar PR. Superpowers te hace mejor dentro de una tarea; GSD te obliga a tener tareas bien delimitadas antes de empezar.

No es un wrapper más de Claude Code. Es un protocolo sobre Claude Code.

Cómo funciona por dentro

El núcleo es un sistema de archivos de contexto que vive en el repo. Cada archivo tiene un trabajo específico y se carga — o no — según la fase:

• PROJECT.md — la visión, siempre presente.
• REQUIREMENTS.md — requisitos versionados con trazabilidad por fase.
• ROADMAP.md — las fases y su estado.
• STATE.md — decisiones tomadas, bloqueos activos, dónde nos quedamos.
• PLAN.md — la tarea atómica actual, estructurada en XML con criterios de verificación.
• HANDOFF.json — estado de máquina para pausar y reanudar entre sesiones.

El flujo típico, una vez instalado:

npx get-shit-done-cc@latest --claude --local

Después las fases se invocan con comandos /gsd-*:

1. /gsd-new-project (greenfield) o /gsd-map-codebase (brownfield, cosa rara de ver bien hecha).
2. /gsd-discuss-phase N — conversación para capturar preferencias antes de planear.
3. /gsd-plan-phase N — investigación + plan + criterios de verificación.
4. /gsd-execute-phase N — ejecución en oleadas, paralelizable con worktrees de git.
5. /gsd-verify-work N — verificación hacia atrás contra el objetivo, en cuatro niveles.
6. /gsd-ship N — crea el PR, con preflight checks.

El detalle que nos llamó la atención no es el workflow — son las salvaguardas. GSD codifica anti-patrones conocidos de agentes como reglas duras:

• Ship refusal — /gsd-ship se niega a abrir PR si hay tareas pendientes. No “te avisa”. Se niega.
• Scope reduction detection — frases como “versión simplificada” o “placeholder” disparan alarma. El agente no puede declarar victoria recortando el alcance a escondidas.
• Analysis paralysis guard — si acumula cinco lecturas sin una sola escritura, se le fuerza a parar y decidir.
• HANDOFF.json con anti-patrones — cuando reanudas una sesión, el agente debe pasar un test de tres preguntas sobre el estado antes de seguir. Evita que retome el trabajo a tientas.

Debajo de todo hay 34 agentes especializados (gsd-planner, gsd-verifier, gsd-code-reviewer, gsd-security-auditor, y así), cada uno con un prompt y un rol acotado. No los invocas a mano — los orquesta el flujo.

Pros

• Ataca el problema correcto. El context rot es real y poca gente lo nombra. Partir en fases atómicas es la respuesta honesta.
• Brownfield support de verdad. /gsd-map-codebase asume que llegaste a un repo que no conoces — no a un proyecto en blanco. Eso es raro y es valioso.
• Commits atómicos como subproducto natural. Cada fase termina con PR propio. La trazabilidad la regala la arquitectura.
• Anti-patrones codificados como bloqueos. No son consejos en un README. Son reglas que el agente tiene que obedecer. Esa es la diferencia entre documentación y proceso.
• Pausar y reanudar funciona. HANDOFF.json más el test de tres preguntas es la mejor respuesta que hemos visto al problema de sesiones largas.
• MIT y sin telemetría opaca. Puedes leerlo.

Contras

• El ship automation asume gh CLI. Si trabajas en Gitea, GitLab self-hosted o Bitbucket, te toca adaptar. No es trivial.
• Curva de aprendizaje media-alta. 34 agentes, seis archivos de contexto, un vocabulario propio. El primer proyecto se siente burocrático antes de sentirse productivo.
• Un solo mantenedor activo. TâCHES (@glittercowboy) empuja el repo. Con 56 mil estrellas ya no es un experimento — pero tampoco es un proyecto con bus factor cómodo.
• El overhead no vale la pena para tareas cortas. Un script de 200 líneas no necesita fases atómicas. Necesita que te sientes a escribirlo.
• Opinado hasta el hueso. Si tu equipo ya tiene su propia metodología de fases, adoptar GSD significa reemplazarla, no extenderla.

Cuándo sí, cuándo no

Sí, cuando el proyecto dura más de una tarde — migraciones grandes, features multi-módulo, cualquier cosa que vas a retomar mañana y la próxima semana. También si tu pareja de pair programming es un agente y notas que después de dos horas de sesión empieza a alucinar decisiones. Ahí el context rot está pagando renta en tu ventana.

No, para un fix rápido, un prototipo de fin de semana, o cuando ya tienes un flujo disciplinado que funciona. GSD cobra overhead al inicio — te pide estructurar antes de tocar código. Si el trabajo cabe en una sesión limpia, ese overhead es pura fricción.

Veredicto

Lo usaríamos. No como reemplazo de Superpowers, sino al lado — GSD arriba, Superpowers adentro. GSD resuelve “¿qué es una unidad de trabajo y cómo sé que terminó?”; Superpowers resuelve “¿cómo lo hago bien mientras lo hago?”. Son ejes distintos.

La apuesta honesta de GSD no es escribir más código, más rápido. Es llegar al final de una fase sin que el contexto se haya podrido y sin que el agente haya cambiado el alcance a escondidas. Esa apuesta nos parece correcta. Es la diferencia entre un agente que impresiona en un demo y un agente que sobrevive un sprint real.

Lo que aún no sabemos: si el costo de adopción vale la pena para un lab chico comparado con escribir nuestras propias reglas. Para equipos de tres o más personas con agentes corriendo en paralelo, la respuesta probablemente es sí. Para un solo dev con un solo agente, quizá baste con imitar dos o tres de sus salvaguardas en un CLAUDE.md propio.

Lo seguimos mirando. Si lo probamos en un proyecto real, escribimos la segunda parte.

TL;DR — GSD no te hace escribir más rápido; te obliga a partir el trabajo en pedazos que tu agente pueda terminar sin que el contexto se pudra a medio camino.