GSD (Git. Ship. Done): guía completa del framework de context engineering para Claude Code

GSD Core (antes “Get Shit Done”) es un sistema open source de meta-prompting e ingeniería de contexto que resuelve el mayor problema de escribir código con IA: la degradación de calidad conforme se llena la ventana de contexto. Se instala con npx @opengsd/gsd-core@latest, funciona con Claude Code, Codex, Gemini CLI, OpenCode, Copilot, Cursor, Windsurf y muchos más, y estructura tu proyecto en fases con subagentes independientes que mantienen la calidad desde la primera hasta la última línea de código.

Si llegaste buscando get-shit-done-cc, ese paquete está descatalogado. El proyecto se movió a la organización OpenGSD, cambió de nombre a GSD Core, adoptó el lema “Git. Ship. Done.” y reinició su numeración de versiones. El acrónimo es el mismo, pero casi todo lo demás se ha movido de sitio. En este artículo te cuento qué es GSD, cómo se instala hoy, cómo funciona paso a paso y por qué está cambiando la forma de construir aplicaciones con IA. También lo comparo con PAUL, BMAD y cc-sdd para que elijas el que encaja con tu forma de trabajar.

Lo que vas a encontrar en este artículo ¶

• Qué es GSD y qué problema resuelve
• Qué ha cambiado tras el movimiento del repositorio y el cambio de nombre
• Cómo instalar y configurar GSD en tu entorno
• El flujo de trabajo completo, desde la idea hasta el pull request
• Cómo funciona la orquestación de subagentes y las oleadas de ejecución
• Comparativa con alternativas: PAUL, BMAD y cc-sdd
• Opiniones reales de developers que usan GSD a diario
• Cuándo usar GSD y cuándo es demasiado para lo que necesitas

¿Qué es GSD y qué problema resuelve? ¶

GSD Core es un framework open source de ingeniería de contexto, meta-prompting y desarrollo guiado por especificaciones (Spec-Driven Development) para agentes de IA. Su repositorio oficial está en GitHub, tiene licencia MIT y acumula miles de estrellas.

El problema que resuelve tiene nombre técnico: context rot. Es la degradación progresiva de la calidad de las respuestas de un modelo de IA conforme la ventana de contexto se va llenando de tokens. Si quieres el detalle de por qué se pudre el contexto de tu agente en sesiones largas y cómo combatirlo, lo desmenuzo en un artículo aparte. Según datos compartidos por la comunidad de Claude Code, la calidad se comporta así:

• 0-30% de contexto ocupado: calidad máxima, respuestas completas y coherentes.
• 50% de contexto ocupado: el modelo empieza a recortar esquinas y a omitir detalles.
• 70%+ de contexto ocupado: aparecen alucinaciones, se olvidan requisitos y el código generado puede contradecir lo anterior.

GSD resuelve esto delegando cada tarea a subagentes con contextos frescos de 200.000 tokens. La tarea 50 se ejecuta con la misma calidad que la tarea 1. Mientras tanto, tu sesión principal se mantiene al 30-40% de ocupación. Si además quieres reducir el consumo en cada sesión, estas 21 técnicas para ahorrar tokens en Claude Code complementan la estrategia de GSD.

🧠 Piensa en el context rot como en un despacho con una mesa pequeña. Cuantos más papeles amontonas, más difícil es encontrar lo que necesitas. Llega un momento en que trabajas mal porque no puedes ni moverte. GSD lo resuelve limpiando la mesa y organizando los papeles en carpetas separadas.

¿Qué ha cambiado con el movimiento del repositorio? ¶

Si seguías GSD desde hace meses, conviene que actualices tus notas. El proyecto ha pasado de ser la herramienta de un developer en solitario a un proyecto comunitario, y el traslado ha tocado bastantes piezas. Estos son los cambios que más te van a afectar:

1. Nuevo repositorio y nueva organización. El código vive ahora en github.com/open-gsd/gsd-core, bajo la organización OpenGSD.
2. Nuevo paquete de npm. Se instala con @opengsd/gsd-core. El antiguo get-shit-done-cc (y su variante get-shit-done-redux) está descatalogado en npm.
3. Nuevo nombre y lema. Ahora se llama GSD Core, con el lema “Git. Ship. Done.” El acrónimo GSD se mantiene.
4. Versionado reiniciado. El linaje antiguo llegó hasta la rama 1.42.x. Con el renombrado, la numeración de @opengsd/gsd-core se reinició. Las versiones antiguas se archivaron para que los dos streams no choquen.
5. Comandos con guion. Lo que antes escribías como /gsd:new-project ahora es /gsd-new-project en Claude Code. Más abajo verás las variantes por runtime.
6. Un paso más en el flujo. El ciclo incorpora una fase final de Ship que abre un pull request en GitHub. El loop pasó de “verificar y repetir” a “verificar, enviar y repetir”.

⚠️ No copies a mano ficheros de las carpetas agents/ o commands/ del repositorio. El instalador es obligatorio porque adapta los comandos a cada runtime (no es lo mismo Claude Code que Gemini o Codex). Copiar a pelo te dejará una instalación rota.

¿Quién creó GSD y para quién está pensado? ¶

El GSD original lo creó TÂCHES, un developer en solitario cuya filosofía se resume en una frase: “No escribo código. Claude Code lo hace.” El proyecto nació como reacción a frameworks de desarrollo guiado por especificaciones como BMAD, SpecKit o Taskmaster, que imponen ceremonias de sprint, story points, retrospectivas y flujos de Jira innecesarios para equipos pequeños.

Desde el traslado a la organización OpenGSD, GSD Core se mantiene como un proyecto open source comunitario con licencia MIT, contribuciones abiertas y un Discord propio. La filosofía no ha cambiado: está pensado para developers en solitario, freelancers y equipos pequeños que quieren describir lo que necesitan y obtener código funcional con estructura profesional, sin simular que gestionan una empresa de 50 personas.

¿Cómo se instala GSD? ¶

La instalación requiere un solo comando y tarda menos de 30 segundos:

npx @opengsd/gsd-core@latest

El instalador te hace dos preguntas. Primero, qué runtime usas. La lista ha crecido muchísimo: Claude Code, OpenCode, Gemini CLI, Kimi CLI, Kilo, Codex, Copilot, Cursor, Windsurf, Antigravity, Qwen Code y unos cuantos más. Segundo, si quieres la instalación global (todos tus proyectos) o local (solo el proyecto actual).

Para verificar que funciona, escribe /gsd-help en Claude Code y deberías ver la lista de comandos.

Instalación no interactiva (Docker, CI, scripts) ¶

Para entornos automatizados puedes especificar los flags de runtime y ámbito:

# Instalar para Claude Code de forma global
npx @opengsd/gsd-core --claude --global

# Instalar para Codex de forma local
npx @opengsd/gsd-core --codex --local

# Instalar para todos los runtimes a la vez
npx @opengsd/gsd-core --all --global

Perfiles de instalación: no instales 86 skills si no las necesitas ¶

GSD Core ha crecido tanto que cargar todas las skills tiene un coste en tokens al arrancar cada sesión. Por eso el instalador permite elegir un perfil de skills y reducir ese coste de arranque:

# Solo el núcleo del flujo principal (mínimo coste de arranque)
npx @opengsd/gsd-core --claude --global --profile=core

# Núcleo + revisión + configuración
npx @opengsd/gsd-core --claude --global --profile=standard

# Todas las skills (comportamiento por defecto)
npx @opengsd/gsd-core --claude --global --profile=full

El perfil core es un alias de --minimal y recorta el coste de arranque de varios miles de tokens a unos cientos. El perfil queda guardado y se respeta cuando actualices.

Cómo desinstalar GSD ¶

# Desinstalar de Claude Code (global)
npx @opengsd/gsd-core --claude --global --uninstall

# Desinstalar de Claude Code (local)
npx @opengsd/gsd-core --claude --local --uninstall

GSD evoluciona con rapidez. Para actualizar basta con volver a lanzar npx @opengsd/gsd-core@latest.

¿Es necesario desactivar los permisos de Claude Code? ¶

GSD recomienda ejecutar Claude Code con el flag --dangerously-skip-permissions para evitar tener que aprobar cada operación de git, lectura de fichero o marca temporal. Los creadores argumentan que detener el flujo 50 veces para aprobar un git commit o un date anula el propósito de la automatización.

Si prefieres no desactivar permisos por completo, puedes configurar permisos granulares en .claude/settings.json para permitir solo las operaciones que GSD necesita (git, echo, cat, ls, mkdir y similares).

¿Cómo funciona el flujo de trabajo de GSD? ¶

El flujo gira en torno a un bucle de cinco pasos que repites una fase tras otra, dentro de cada milestone: discutir, planificar, ejecutar, verificar y enviar. Antes de ese bucle, inicializas el proyecto una sola vez. Esta es la secuencia completa.

Una nota sobre la sintaxis de los comandos antes de empezar: en Claude Code, Copilot, OpenCode y Kilo usas la forma con guion (/gsd-plan-phase). En Gemini CLI se usan dos puntos (/gsd:plan-phase). En Codex se invocan con $ ($gsd-plan-phase). El instalador escribe la forma correcta en tu runtime, así que no tienes que recordarlas todas.

Paso 0: Inicializar el proyecto (/gsd-new-project) ¶

GSD te entrevista hasta que entiende tu idea por completo: objetivos, restricciones, preferencias técnicas, casos límite. Después lanza agentes de investigación en paralelo, extrae requisitos (qué es v1, qué es v2, qué queda fuera) y crea un roadmap organizado en fases.

Los ficheros que genera son: PROJECT.md (visión del proyecto), REQUIREMENTS.md (requisitos con trazabilidad), ROADMAP.md (fases de desarrollo), STATE.md (estado actual y memoria entre sesiones) y un config.json con la configuración. Estos ficheros trabajan junto al sistema de memoria y reglas de Claude Code para mantener la coherencia del proyecto.

🗂️ El fichero STATE.md es el cerebro persistente de GSD. Cada vez que limpias el contexto y empiezas una nueva sesión, GSD lee ese fichero y sabe en qué punto del proyecto te quedaste. Sin él, cada sesión sería empezar de cero.

Paso 1: Discutir la fase (/gsd-discuss-phase N) ¶

Tu roadmap tiene una o dos frases por fase. Eso no es contexto suficiente para que Claude construya lo que tú imaginas. Este paso captura tus preferencias antes de que nada se investigue o planifique.

GSD analiza la fase e identifica zonas grises según el tipo de funcionalidad. Si es visual, te pregunta por layouts, interacciones y estados vacíos. Si es una API, te pregunta por formatos de respuesta, gestión de errores y verbosidad. La profundidad que pongas aquí es proporcional a la calidad del resultado. Si tienes prisa, --auto elige los valores recomendados; si quieres revisarlo todo, --all recorre cada zona gris una por una.

Paso 2: Planificar la fase (/gsd-plan-phase N) ¶

El sistema investiga cómo implementar la fase, guiado por las decisiones del paso anterior. Crea uno o varios planes de tareas atómicas con estructura XML. Cada plan es lo bastante pequeño para ejecutarse en una ventana de contexto limpia.

Un plan típico tiene esta estructura:

<task type="auto">
  <name>Create login endpoint</name>
  <!-- Ficheros que se van a modificar -->
  <files>src/app/api/auth/login/route.ts</files>
  <action>
    <!-- Instrucciones de implementación -->
    Use jose for JWT (not jsonwebtoken - CommonJS issues).
    Validate credentials against users table.
    Return httpOnly cookie on success.
  </action>
  <!-- Verificación automática integrada -->
  <verify>curl -X POST localhost:3000/api/auth/login returns 200 + Set-Cookie</verify>
  <done>Valid credentials return cookie, invalid return 401</done>
</task>

Instrucciones precisas. Sin ambigüedad. Con verificación integrada. Cada tarea incluye cuatro campos obligatorios: ficheros a modificar, acción a realizar, verificación y criterio de finalización.

Esta fase trae dos modos nuevos que merece la pena conocer. El flag --mvp cambia la planificación de capas horizontales (primero toda la base de datos, luego toda la API…) a rebanadas verticales de funcionalidad (interfaz → API → base de datos en una sola secuencia de tareas). El flag --tdd hace que cada tarea que añade comportamiento empiece por un test que falla. Y se pueden combinar: --mvp --tdd produce rebanadas verticales donde cada paso arranca en rojo.

🛡️ Novedad importante en seguridad de la cadena de suministro: cuando el investigador recomienda instalar paquetes externos, GSD los pasa por un control de legitimidad. Marca cada paquete como [OK], [SUS] o [SLOP]. Los sospechosos exigen una verificación humana antes de instalarse y los detectados como basura se eliminan del plan. Es una defensa directa contra el “slopsquatting”, esos paquetes inventados por la IA que alguien registra con mala fe.

Paso 3: Ejecutar la fase (/gsd-execute-phase N) ¶

GSD ejecuta los planes en oleadas (waves). Las tareas independientes van en paralelo. Las que tienen dependencias esperan a que sus prerequisitos terminen. Cada tarea se ejecuta en una instancia fresca de Claude con 200.000 tokens de contexto limpio.

Cada tarea genera su propio commit atómico en git:

abc123f feat(01-02): add email confirmation flow
def456g feat(01-02): implement password hashing
hij789k feat(01-02): create registration endpoint

Tu sesión principal se mantiene al 30-40% de contexto mientras todo el trabajo pesado ocurre en contextos de subagentes. Puedes marcharte y volver. El código estará hecho con historial de git limpio. Si quieres ir un paso más allá en la coordinación, puedes combinar GSD con Agent Teams para orquestar múltiples instancias de Claude Code en paralelo.

Paso 4: Verificar el trabajo (/gsd-verify-work N) ¶

La verificación automática comprueba que el código existe y los tests pasan. Pero, ¿funciona como tú esperabas? GSD extrae los entregables testeables y te guía uno a uno: “¿Puedes iniciar sesión con email?” Si algo falla, lanza agentes de depuración para diagnosticar la causa raíz y crea planes de corrección listos para volver a ejecutar.

Para las pruebas que necesitan navegador, GSD se apoya en un servidor MCP. El compañero oficial de Open GSD es gsd-browser, que aporta navegación determinista, capturas, diffs visuales y la posibilidad de que tú tomes el control a mano. Los servidores Playwright MCP que ya tuvieras configurados siguen valiendo.

Paso 5: Enviar (/gsd-ship N) ¶

Aquí está la novedad más visible del nuevo flujo. Cuando la fase está verificada, /gsd-ship crea el pull request en GitHub con un cuerpo generado a partir de tus artefactos de planificación: el objetivo de la fase, el resumen de cambios, los requisitos cubiertos, el estado de verificación y las decisiones clave. Si aún no quieres abrirlo del todo, --draft lo crea como borrador.

Necesitas tener el CLI gh instalado y autenticado. El estado del proyecto en STATE.md se actualiza al terminar.

Y vuelta a empezar ¶

El ciclo se repite: discuss → plan → execute → verify → ship hasta completar todas las fases. /gsd-complete-milestone archiva el milestone y etiqueta el release. /gsd-new-milestone inicia el siguiente ciclo sobre tu código existente.

El método que vive debajo de GSD

GSD es un sabor de Spec Driven Development: aquí tienes el método entero, paso a paso

Cinco fases con ejemplo guiado real, autodiagnóstico y plantilla para que el agente deje de improvisar y entregue lo que pediste.

Abrir la guía →

Incluye autodiagnóstico + plantilla descargable · Web Reactiva Premium · 15€/mes

¿Qué es el modo rápido de GSD? ¶

No todo necesita planificación completa. El comando /gsd-quick ofrece las mismas garantías (commits atómicos, seguimiento de estado) con un camino directo: sin investigación, sin verificador de planes, sin agente de validación.

/gsd-quick                          # Tarea rápida básica
/gsd-quick --validate               # Añade verificación de plan y comprobación posterior
/gsd-quick --full                   # Pipeline de calidad completo

Los flags son componibles: puedes añadir --discuss o --research a la carta. Es perfecto para bugs, features pequeñas, cambios de configuración y tareas que no justifican la maquinaria completa.

¿Cómo es la experiencia real de construir con GSD? ¶

En un tutorial práctico documentado en vídeo, un developer construyó desde cero “ClearList” (una lista de tareas potenciada con IA) usando GSD combinado con Supabase, OpenAI y Vercel. El proyecto pasó del 0% al 100% en aproximadamente 3 horas de trabajo activo.

Algunos patrones que merece la pena destacar de esa experiencia:

El proceso no es instantáneo.
Hay espera entre fases mientras los agentes trabajan. Esa espera es intencional: así se construye software de calidad. Un usuario en la comunidad lo resumía así: “Los resultados son buenos, pero el progreso se siente lento por toda la espera.”

Necesitas supervisar.
El developer tuvo que corregir credenciales de Supabase mal colocadas, ajustar URLs de redirección y resolver problemas de autenticación con capturas de pantalla. GSD no elimina tu responsabilidad sobre el código ni sobre la estructura.

El progreso es visible.
STATE.md muestra el porcentaje de avance en cada momento. Ver ese número crecer del 7% al 40%, al 67% y hasta el 100% es una motivación real durante sesiones largas.

Combinar GSD con la extensión de Chrome de Claude Code es potente.
El developer dejaba que Claude navegara por Supabase para crear bases de datos, obtener claves API y configurar variables de entorno directamente desde el terminal.

⚡ Lo que varios usuarios destacan como la mayor fortaleza de GSD: puedes ejecutar una fase entera con investigación profunda, múltiples planes, miles de líneas de código en ejecutores paralelos, y verificación automática, mientras tu ventana de contexto principal nunca supera el 40%. El trabajo ocurre en contextos frescos de subagentes.

¿Qué alternativas existen a GSD? ¶

El ecosistema de herramientas de Spec-Driven Development ha crecido con fuerza. Estas son las tres alternativas más relevantes y sus diferencias con GSD; si quieres el panorama completo con los cinco frameworks cara a cara, lo despliego en la comparativa de frameworks SDD.

PAUL (Plan, Apply, Unify Loop) ¶

PAUL comparte filosofía con GSD pero difiere en un punto clave: mantiene el desarrollo en la sesión principal y reserva los subagentes exclusivamente para descubrimiento e investigación.

El ciclo es PLAN → APPLY → UNIFY. La diferencia está en que cada plan debe cerrarse con UNIFY, un paso de reconciliación donde se compara lo planificado con lo ejecutado, se actualiza el estado y se documentan las decisiones. Los creadores de PAUL argumentan que los subagentes devuelven trabajo con una calidad aproximada del 70% que luego necesita limpieza.

PAUL incluye a CARL (Context Augmentation & Reinforcement Layer), un sistema de inyección dinámica de reglas que activa contexto relevante bajo demanda en lugar de cargar prompts estáticos. Tu ventana de contexto se mantiene ligera.

Cuándo elegir PAUL sobre GSD:
si te preocupa la calidad del código generado por subagentes y prefieres más control directo sobre la implementación.

Tengo una comparativa detallada entre PAUL y GSD con un caso práctico completo (una API de chistes de Chiquito) donde verás el flujo Plan-Apply-Unify en acción y entenderás por qué UNIFY no es opcional.

BMAD Method (Breakthrough Method for Agile AI-Driven Development) ¶

BMAD es la opción más completa y la más compleja. Simula un equipo ágil entero con más de 9 agentes especializados: Business Analyst, Product Manager, Architect, Scrum Master, Developer, QA, UX Designer y más.

El flujo es formal: el Analyst recoge requisitos, el PM crea el PRD (Product Requirements Document), el Architect diseña la arquitectura, el Scrum Master transforma todo en historias de desarrollo y el Developer las implementa. Cuenta con un gate de calidad automático que no permite avanzar si la arquitectura no alcanza el 90% de completitud.

BMAD es open source con licencia MIT, gratuito y sin contenido de pago. Se instala con npx bmad-method install y funciona con Claude Code, Cursor y Windsurf.

Cuándo elegir BMAD sobre GSD:
en equipos con requisitos de documentación formal, compliance o auditorías donde la trazabilidad completa es obligatoria.

cc-sdd ¶

cc-sdd destaca por dos razones: soporta varios agentes distintos (Claude Code, Cursor, Gemini CLI, Codex, GitHub Copilot, Qwen, OpenCode y Windsurf) y está disponible en múltiples idiomas.

Sigue el estilo de Kiro (el framework SDD de AWS), con comandos como /kiro:spec-init, /kiro:spec-requirements y /kiro:spec-design.

Cuándo elegir cc-sdd sobre GSD:
si tu equipo usa herramientas de IA variadas y necesitas un flujo unificado entre todas ellas.

Tabla comparativa: GSD vs PAUL vs BMAD vs cc-sdd ¶

🎯 Mi recomendación: empieza con GSD en un proyecto personal pequeño. Entiende el flujo, familiarízate con los conceptos de context engineering y oleadas de ejecución. Si tus necesidades crecen, evalúa las alternativas con criterio.

¿Qué opinan los developers que ya usan GSD? ¶

Las opiniones sobre GSD son consistentes en tres puntos: funciona bien, requiere paciencia y cambia la forma de pensar sobre el desarrollo con IA.

En The New Stack, una de las publicaciones técnicas de referencia, analizaron cómo GSD gestiona la planificación de forma detallada, extrayendo pasos coherentes a partir de especificaciones vagas. Destacaron que la estructura de planificación está gestionada por el propio GSD y no por el usuario, lo cual reduce la carga cognitiva del proceso.

Un developer compartió en Threads su experiencia tras completar un proyecto con 23 planes distribuidos en 4 fases durante 4 días. Cada tarea recibió la atención completa de Claude sin degradación de contexto ni compactación.

En la comunidad School of AI, un usuario contó que había probado claude-flow antes de GSD y que la diferencia era notable: “GSD es más simple y crea una estructura clara de roadmap e implementación fase por fase. Más tiempo en planificación, mejor resultado final.”

En Medium, un ingeniero de automatización describió GSD como la solución al dilema del developer en solitario: o haces vibe coding y esperas lo mejor, o adoptas frameworks pesados que te hacen simular una organización de 50 personas. GSD ofrece estructura sin esa ceremonia.

También hay voces críticas legítimas. Algunos argumentan que el Spec-Driven Development en general es un regreso al waterfall disfrazado, enterrando la agilidad bajo capas de Markdown. Para prototipos rápidos y exploraciones, la estructura de GSD puede ser excesiva. Para proyectos complejos con múltiples funcionalidades interconectadas, esa estructura marca la diferencia entre un producto funcional y un desastre.

Referencia rápida de comandos GSD ¶

Recuerda que en Gemini la forma es /gsd:comando y en Codex $gsd-comando; abajo van con guion (Claude Code).

Flujo principal ¶

• /gsd-new-project — Inicializa el proyecto: preguntas → investigación → requisitos → roadmap
• /gsd-discuss-phase N — Captura decisiones de implementación antes de planificar
• /gsd-plan-phase N — Investiga, planifica y verifica la fase (admite --mvp y --tdd)
• /gsd-execute-phase N — Ejecuta todos los planes en oleadas paralelas
• /gsd-verify-work N — Tests de aceptación manuales con diagnóstico automático
• /gsd-ship N — Crea el pull request a partir del trabajo de la fase
• /gsd-complete-milestone — Archiva el milestone y etiqueta el release
• /gsd-new-milestone — Inicia el siguiente ciclo de desarrollo

Día a día ¶

• /gsd-quick — Tareas sueltas con garantías de GSD (commits atómicos, tracking)
• /gsd-progress — Muestra dónde estás y qué viene después (con --next auto-avanza)
• /gsd-pause-work — Crea un handoff cuando paras a mitad de fase
• /gsd-resume-work — Recupera el estado de la última sesión
• /gsd-help — Muestra los comandos disponibles, con --full para la referencia completa

Gestión de fases y exploración ¶

• /gsd-phase — Añade, inserta, elimina o edita fases del roadmap desde un solo comando
• /gsd-mvp-phase N — Planificación guiada de MVP con historia de usuario y troceado SPIDR
• /gsd-map-codebase — Analiza una base de código existente antes de empezar
• /gsd-explore — Sesión de ideación socrática para dar forma a una idea

¿Cómo se configuran los perfiles de modelo en GSD? ¶

GSD permite ajustar calidad versus coste de tokens mediante el campo model_profile en config.json. Estos son los perfiles disponibles:

• quality: Opus para todo el trabajo de decisión, Sonnet para verificación. Máxima calidad, mayor consumo.
• balanced (por defecto): Opus solo para planificación, Sonnet para el resto. Buen equilibrio.
• budget: Sonnet para escribir código, Haiku para investigación y verificación. Menor coste.
• adaptive: ajusta el modelo por agente buscando un punto medio razonable.
• inherit: todos los agentes usan el modelo de la sesión actual. Útil con proveedores que no son de Anthropic (OpenRouter, modelos locales).

Lo configuras de forma interactiva con /gsd-settings, que agrupa los toggles del flujo y el perfil de modelo en secciones. También puedes afinar el modelo por tipo de fase (planificación, investigación, ejecución, verificación…) sin tener que aprenderte los nombres internos de cada agente.

Los agentes de flujo de trabajo también son configurables. El investigador estudia el dominio antes de planificar, el verificador de planes comprueba coherencia antes de ejecutar y el verificador post-ejecución confirma que los entregables existen. Puedes activarlos o desactivarlos según la complejidad de tu proyecto.

¿Cuándo NO deberías usar GSD? ¶

GSD no es la respuesta a todo. Añade complejidad sin beneficio en estos casos:

• Prototipos rápidos de una o dos horas donde solo necesitas validar una idea.
• Scripts pequeños o utilidades de una sola función.
• Cambios triviales como ajustar un color, modificar un texto o actualizar una dependencia.
• Aprendizaje exploratorio donde estás probando un framework nuevo y quieres iterar rápido.

En esos escenarios, el vibe coding directo con Claude Code es más eficiente. GSD brilla cuando el proyecto tiene múltiples funcionalidades interconectadas, cuando necesitas consistencia a lo largo de cientos o miles de líneas de código, o cuando vas a trabajar en el proyecto durante días o semanas.

Para terminar ¶

GSD representa un cambio de mentalidad en la forma de construir con IA. No se trata de dar instrucciones vagas y esperar que salga algo bueno. Se trata de invertir en planificación para que la ejecución sea predecible y de calidad.

El traslado a la organización OpenGSD, el cambio de nombre y la fase de Ship no son maquillaje. Son la señal de un proyecto que ha pasado de ser la herramienta de una persona a una pieza comunitaria con su propio ecosistema. La ingeniería de contexto, los subagentes con contextos frescos de 200.000 tokens, las oleadas de ejecución paralela y los commits atómicos no son conceptos teóricos. Son soluciones prácticas a problemas que cualquiera que haya trabajado con Claude Code durante más de una hora ha experimentado.

¿Es perfecto? No. Hay espera. Hay supervisión manual. Hay curva de aprendizaje. Pero la alternativa es construir proyectos que se degradan conforme crecen, con código inconsistente y sin rastro de las decisiones tomadas.

Si usas Claude Code para algo más que scripts sueltos, dale una oportunidad a GSD en tu próximo proyecto. Algo pequeño, sin presión. Y después de ver el roadmap generado, los planes XML y los commits atómicos en tu historial de git, decide si quieres seguir escribiendo código a ciegas.

Claude Code es potente. GSD Core lo hace fiable.

Recursos y enlaces ¶

• Repositorio oficial de GSD Core en GitHub — Código fuente, documentación y guía de usuario completa
• Paquete @opengsd/gsd-core en npm — Versión estable actual y notas de cada release
• PAUL Framework — Alternativa con enfoque en calidad y desarrollo en sesión
• BMAD Method — Framework ágil completo con 9+ agentes especializados
• cc-sdd — Spec-Driven Development compatible con múltiples agentes e idiomas
• Artículo en The New Stack sobre GSD y context rot — Análisis técnico independiente
• Comparativa completa de frameworks SDD — GSD, BMAD, Ralph Loop, Kiro y más

Preguntas frecuentes sobre GSD ¶

¿Por qué ya no encuentro get-shit-done-cc en npm?
Porque el proyecto se renombró y se trasladó a la organización OpenGSD. El paquete actual es @opengsd/gsd-core y se instala con npx @opengsd/gsd-core@latest. El antiguo get-shit-done-cc quedó descatalogado.

¿GSD solo funciona con Claude Code?
No. GSD Core soporta una larga lista de runtimes: Claude Code, OpenCode, Gemini CLI, Kimi CLI, Kilo, Codex, Copilot, Cursor, Windsurf y más. El instalador detecta el runtime y escribe los comandos en su formato correcto.

¿Han cambiado los nombres de los comandos?
Sí. En Claude Code ahora usan guion (/gsd-new-project en lugar de /gsd:new-project). En Gemini se mantiene la forma con dos puntos y en Codex se invocan con $. El instalador escribe la variante correcta para tu runtime.

¿Qué es el nuevo paso de Ship?
Es la fase que cierra el bucle de trabajo. /gsd-ship crea un pull request en GitHub con un cuerpo generado a partir de tus artefactos de planificación. Necesitas el CLI gh instalado y autenticado.

¿Qué versión de GSD debería instalar?
Instala siempre con @latest, que apunta a la última versión estable publicada en npm. El versionado se reinició tras el renombrado, así que no te fíes de números antiguos del linaje get-shit-done-cc.

¿Puedo usar GSD con un proyecto que ya tiene código?
Sí. El comando /gsd-map-codebase analiza tu stack, arquitectura, convenciones y posibles problemas. Después, /gsd-new-project incorpora ese conocimiento para que las preguntas se centren en lo que vas a añadir.

¿Cuánto cuesta usar GSD en tokens?
Depende del perfil de modelo elegido. El perfil “budget” (Sonnet + Haiku) consume bastante menos que el “quality” (Opus). Además, elegir un perfil de instalación core reduce el coste de arranque de cada sesión.

¿Qué es el control de legitimidad de paquetes?
Es una comprobación que GSD ejecuta cuando recomienda instalar dependencias externas. Clasifica cada paquete y exige verificación humana ante los sospechosos, como defensa frente a paquetes inventados por la IA que un atacante podría registrar.

¿GSD funciona para proyectos que no son web?
Sí. Es agnóstico respecto al tipo de proyecto. Funciona para backends, CLIs, librerías y cualquier proyecto gestionable desde un agente de terminal.

¿Puedo combinar GSD con otras herramientas como Cursor o GitHub Copilot?
Ahora sí, de forma nativa. La lista de runtimes soportados incluye Cursor, Copilot, Windsurf y más, además de los CLIs de terminal. El instalador adapta los comandos a cada uno.

🧨 Última oprtunidad para recibir la dinamita que mereces sobre programación con IA el próximo domingo: Suscríbete gratis a Web Reactiva en https://webreactiva.com/newsletter