Guía práctica de GSD

Introducción

En el artículo anterior, exploramos los principios fundamentales de GSD: ingeniería de contexto, orquestación de subagentes, planificación por objetivos inversos y commits atómicos. Estos conceptos suenan elegantes, pero entre "comprender la teoría" y "entregar un proyecto real" hay muchos detalles operativos que resolver.

En este artículo, pasamos a la práctica. Aprenderá el sistema completo de comandos de GSD, las opciones de configuración, la estructura de archivos generados y cómo utilizarlo para entregar una funcionalidad completa desde cero.

Instalación y configuración

Instalación

npx get-shit-done-cc@latest

El instalador le pedirá que seleccione:

1. Entorno de ejecución — Claude Code, OpenCode, Gemini CLI o todos
2. Alcance — Global (todos los proyectos) o local (proyecto actual)

Después de la instalación, escriba /gsd:help en su entorno de ejecución para verificar que la instalación fue exitosa.

Recomendado: modo sin permisos

GSD está diseñado para automatización sin fricciones. La forma recomendada de ejecutar Claude Code:

claude --dangerously-skip-permissions

Si prefiere no usar esta opción, puede configurar permisos detallados en .claude/settings.json.

Actualización

/gsd:update

Las actualizaciones de GSD son muy frecuentes (TÂCHES publica entre 15 y 20 actualizaciones casi todos los días). Se recomienda ejecutar este comando regularmente para mantenerse en la última versión.

Referencia completa de comandos

Todas las interacciones con GSD se realizan mediante comandos de barra (slash commands) con el prefijo /gsd:. A continuación se presenta la referencia completa organizada por función.

Comandos del flujo de trabajo principal

Estos cinco comandos forman el ciclo principal de GSD y se usan en secuencia.

[N] indica un parámetro opcional — el sistema detecta automáticamente la fase actual si se omite. <N> indica un parámetro obligatorio.

Gestión de hitos

Gestión de fases

Quick Mode y herramientas

Gestión de sesión y configuración

Configuración detallada

Perfiles de modelo

GSD soporta tres perfiles de modelo, que se cambian con /gsd:set-profile:

Configuración principal

Consulte y modifique mediante /gsd:settings:

Interruptores de flujo de trabajo

Los siguientes agentes pueden activarse o desactivarse individualmente para equilibrar velocidad y calidad:

Desactivar research y plan_check puede acelerar significativamente el proceso, pero podría reducir la calidad de la planificación. Se recomienda considerar desactivarlos solo después de familiarizarse con el proyecto.

Estructura de archivos generados

Todo el estado y las salidas de GSD se almacenan en el directorio .planning/. Comprender esta estructura ayuda con la depuración y la intervención manual.

Archivos a nivel de proyecto

Archivos a nivel de fase

Cada fase produce los siguientes archivos (usando la Fase 1 como ejemplo):

Ejemplo de estructura de directorios

.planning/
├── PROJECT.md
├── REQUIREMENTS.md
├── ROADMAP.md
├── STATE.md
├── research/
│   ├── tech-stack.md
│   ├── features.md
│   ├── architecture.md
│   └── pitfalls.md
├── 01-CONTEXT.md
├── 01-RESEARCH.md
├── 01-01-PLAN.md
├── 01-02-PLAN.md
├── 01-01-SUMMARY.md
├── 01-02-SUMMARY.md
├── 01-VERIFICATION.md
├── 01-UAT.md
├── 02-CONTEXT.md
├── 02-RESEARCH.md
├── 02-01-PLAN.md
│   ...
└── todos.md

Demostración del flujo de trabajo

A continuación, se demuestra el flujo completo desde la inicialización hasta la entrega, usando como ejemplo "agregar una funcionalidad de comentarios a un sistema de blog".

Paso 1: Inicializar el proyecto

/gsd:new-project

El sistema comenzará a hacer preguntas:

> ¿Qué desea construir?
"Quiero agregar un sistema de comentarios a mi blog en Next.js. Que soporte
 comentarios anónimos y con inicio de sesión, renderizado de Markdown y un
 panel de administración. Stack tecnológico: Prisma + PostgreSQL."

Cuanto más detallada sea su descripción, menos preguntas de seguimiento hará el sistema. TÂCHES recomienda preparar un documento de visión aproximado describiendo lo que desea, sin necesidad de conocer los detalles técnicos.

Una vez completado, el sistema genera cuatro archivos y le solicita aprobar la hoja de ruta. Una vez aprobada, comienza la fase de construcción.

¿Ya tiene una base de código? Ejecute primero /gsd:map-codebase. El sistema analizará su arquitectura y convenciones existentes, y luego new-project podrá planificar basándose en su código actual.

Paso 2: Fase de discusión

/gsd:discuss-phase 1

El sistema identifica las zonas grises y formula preguntas una por una:

> Anidación de comentarios: ¿soportar múltiples niveles o solo un nivel de respuesta?
> Comentarios anónimos: ¿requiere CAPTCHA o envío directo?
> Panel de administración: ¿necesita operaciones masivas o moderación individual?

Cada decisión que tome aquí afecta directamente la calidad de la planificación. Si no está seguro, puede dejar que el sistema use valores predeterminados, pero una discusión más profunda reduce significativamente el retrabajo durante la ejecución.

Paso 3: Fase de planificación

/gsd:plan-phase 1

El sistema:

1. Investiga cómo implementar un sistema de comentarios con Prisma + PostgreSQL
2. Crea 2-3 planes de tareas atómicas (por ejemplo: modelo de datos, rutas API, componentes del frontend)
3. Verifica automáticamente que los planes cubran todos los requisitos

Cada plan es lo suficientemente pequeño para completarse en una sola ventana de contexto nueva.

Paso 4: Fase de ejecución

/gsd:execute-phase 1

El sistema comienza la ejecución por oleadas:

• Oleada 1 (sin dependencias): Esquema de base de datos, modelos Prisma — ejecución en paralelo
• Oleada 2 (depende de la Oleada 1): Rutas API, CRUD de comentarios — ejecución en paralelo
• Oleada 3 (depende de la Oleada 2): Componente de comentarios del frontend — ejecución independiente

Cada tarea se ejecuta en un contexto nuevo de 200k tokens y recibe un commit de git independiente.

Paso 5: Fase de verificación

/gsd:verify-work 1

El sistema le guía en la confirmación:

> ✅ Tablas de base de datos creadas
> ✅ Las rutas API devuelven códigos de estado correctos
> ❓ ¿Puede ver el campo de entrada de comentarios debajo de las publicaciones? [sí/no/describir problema]
> ❓ ¿La página se actualiza en tiempo real después de enviar un comentario? [sí/no/describir problema]

Si alguna verificación falla, el sistema diagnostica automáticamente y crea un plan de corrección. Ejecute /gsd:execute-phase 1 nuevamente para aplicar la corrección.

Escenarios comunes

Insertar una fase urgente: Los requisitos cambiaron y necesita insertar nuevo trabajo antes de la fase actual.

/gsd:insert-phase 2

Las fases posteriores se renumeran automáticamente (la Fase 2 original se convierte en Fase 3, y así sucesivamente).

Pausar y reanudar: Necesita interrumpir el trabajo para atender otro asunto.

/gsd:pause-work    # Guardar estado actual
# ... atender otro asunto ...
/gsd:resume-work   # Reanudar desde donde lo dejó

Revertir resultados insatisfactorios:

git reset --hard HEAD~3    # Volver al estado previo a la ejecución

/gsd:remove-phase 2        # Eliminar en cascada todos los archivos de salida de esta fase

TÂCHES demostró esta operación múltiples veces en sus transmisiones en vivo: si no le gusta, revierta. Limpio y decisivo.

Flujo de depuración

Cuando la verificación encuentra problemas, o cuando se encuentra con errores durante el desarrollo, GSD proporciona un flujo de depuración dedicado.

/gsd:debug La página no se actualiza en tiempo real después de enviar un comentario

El sistema lanza un subagente de depuración aislado con el siguiente flujo de trabajo:

1. Hipótesis — Genera múltiples hipótesis de causas raíz basadas en la descripción del problema
2. Recopilación de evidencia — Verifica las hipótesis una por una, revisando código, registros y solicitudes de red
3. Resolución — Después de identificar la causa raíz, crea un plan de corrección

Características clave:

• Aislamiento de contexto: El agente de depuración tiene su propia ventana de contexto y no contamina su contexto principal de desarrollo
• Documentación: Crea documentos de depuración independientes que registran todo el proceso de investigación
• Plan de corrección: Produce un plan de corrección directamente ejecutable después del diagnóstico

Esto es mucho más eficiente que depurar en el contexto principal: la información de depuración no se acumula en su ventana principal.

Experiencia práctica

Basándonos en las transmisiones en vivo de TÂCHES y la experiencia práctica de Chase AI, a continuación se presentan algunas recomendaciones prácticas.

Ir más lento para ir más rápido

TÂCHES reconoce que cuando comenzó a usar GSD, su mentalidad era "rápido, rápido, rápido", pero luego descubrió que dedicar más tiempo a las fases de investigación y discusión en realidad reducía el retrabajo durante la ejecución. Las versiones más recientes de GSD agregaron los pasos research-project y define-requirements precisamente para asegurar la dirección correcta antes de escribir código.

"I was definitely when I first started doing things with GSD, I was very much like move fast, move fast, move fast. But I'm just finding that taking these extra steps... I think you're going to really really love to see the results."

—— TÂCHES

Limpiar el contexto entre fases

El hábito de TÂCHES es ejecutar clear entre cada fase para mantener el contexto principal ligero. Utiliza el terminal Warp, con cada ventana a pantalla completa (Command+Shift+Enter), ejecutando la fase actual en una ventana mientras investiga la siguiente fase en otra.

La compensación del costo de tokens

El enfoque de subagentes de GSD efectivamente consume más tokens que usar Claude Code directamente. Pero Chase AI presenta un argumento convincente: "plan twice, prompt once" (planificar dos veces, ejecutar una vez) es más económico a largo plazo que "ejecutar una vez y luego parchear y parchear". Hacer las cosas bien en un contexto nuevo es mucho más eficiente que reparar repetidamente en un contexto degradado.

Manejo de resultados insatisfactorios

Si no está satisfecho con los resultados de una fase, puede usar git reset --hard y luego /gsd:remove-phase para eliminar en cascada todos los archivos de salida de esa fase. TÂCHES demostró esto en vivo: no le gustó un efecto visual particular, así que revirtió al último estado satisfactorio, limpio y decisivo.

El sistema de pendientes

/gsd:add-todo le permite registrar ideas en una lista de pendientes en cualquier momento sin modificar la hoja de ruta. Estas ideas pueden recuperarse durante /gsd:discuss-milestone como entrada para el siguiente hito. La estrategia de TÂCHES es "primero construir las funcionalidades, pulir la interfaz en el hito 2".

Preguntas frecuentes y mejores prácticas

Mejores prácticas

Proporcione descripciones iniciales detalladas. La calidad de /gsd:new-project depende de la calidad de su entrada. Prepare un documento de visión aproximado: describa objetivos, usuarios, funcionalidades principales y restricciones conocidas. Cuanto más precisa sea su descripción, menos preguntas de seguimiento y mejor la planificación.

Limpie el contexto entre fases. Después de completar cada fase, ejecute clear o /compact para mantener la ventana de contexto principal ligera. El hábito de TÂCHES es mantener el contexto principal entre el 30-40%.

Pruebe primero con Quick Mode. Para funcionalidades pequeñas de las que no esté seguro, use /gsd:quick para probar. Si funciona bien, incorpórelo en la hoja de ruta formal.

Mapee primero las bases de código existentes. Antes de usar GSD en una base de código existente, ejecute /gsd:map-codebase. El sistema analizará el stack tecnológico, la arquitectura y las convenciones, lo que hará que la planificación posterior se alinee mejor con el código existente.

Preguntas frecuentes

P: ¿Qué entornos de ejecución soporta GSD?

R: Claude Code, OpenCode y Gemini CLI. Puede elegir uno o todos durante la instalación.

P: ¿Cuál es la diferencia entre Quick Mode y el modo completo?

R: Quick Mode proporciona las protecciones básicas de GSD (commits atómicos, seguimiento de estado), pero omite los pasos de investigación, verificación del plan y validación. Es ideal para correcciones de errores, funcionalidades pequeñas y cambios de configuración que no necesitan una planificación completa.

P: ¿Se puede pausar durante la ejecución?

R: Sí. /gsd:pause-work guarda el estado actual en STATE.md. La próxima vez que ejecute /gsd:resume-work, el sistema continuará desde donde lo dejó.

P: ¿Cómo se controla el costo de tokens?

R: Tres enfoques: (1) Cambiar al perfil budget: /gsd:set-profile budget; (2) Desactivar los agentes research o plan_check; (3) Usar /gsd:quick para tareas simples.

P: ¿Se puede usar GSD junto con Ralph?

R: Sí. GSD y Ralph resuelven problemas diferentes: GSD se encarga de la planificación y la ejecución estructurada, Ralph se encarga de la ejecución en ciclo autónomo. Puede usar new-project y plan-phase de GSD para generar un plan completo, y luego usar los ciclos de Ralph para ejecutar las fases que no requieren intervención humana.

P: ¿Qué pasa con la colaboración entre múltiples personas?

R: El directorio .planning/ puede incluirse en Git. Varias personas pueden ejecutar diferentes fases y fusionar los resultados a través de Git. Sin embargo, se recomienda evitar ejecutar la misma fase simultáneamente.

Resumen

El valor fundamental de GSD radica en ocultar la complejidad dentro del sistema mientras mantiene la simplicidad para el usuario. Solo necesita unos pocos comandos — new-project, discuss-phase, plan-phase, execute-phase, verify-work — mientras el sistema se encarga en segundo plano de toda la gestión de contexto, la orquestación de subagentes y la verificación de calidad.

Desde la instalación hasta la entrega, GSD proporciona un camino claro: describa lo que desea, discuta los detalles de implementación, genere planes atómicos, ejecute en paralelo y verifique los entregables. Cada paso le da la oportunidad de intervenir, y cada paso queda documentado.

Esto no es magia de "presione un botón y listo". Es un sistema que requiere su participación pero asume la mayor parte de la carga cognitiva. Como dice TÂCHES: usted es el gerente de proyecto de alto nivel, GSD es su equipo de ejecución.

Lectura adicional:

• Análisis profundo de GSD — Principios fundamentales, flujos de trabajo y arquitectura técnica
• Análisis profundo de Ralph Wiggum — Context Rot y la metodología Ralph
• Guía práctica de Ralph — Instalación de Ralph, redacción de PRD y guía práctica
• ¿Qué es el desarrollo dirigido por especificaciones? — De Vibe Coding al desarrollo dirigido por especificaciones
• Guía práctica de Speckit — Referencia de comandos de Speckit y ejemplos completos