Get Shit Done - sistema de desarrollo basado en metaprompts y especificaciones

 (github.com/gsd-build)
12 puntos por GN⁺ 2026-03-19 | 1 comentarios | Compartir por WhatsApp
  • Claude Code y otros usan este sistema ligero para automatizar el desarrollo basado en especificaciones (SDD), ayudando a completar proyectos sin flujos de trabajo complejos
  • Mediante ingeniería de contexto, estructuración de prompts basada en XML y orquestación multiagente, evita la degradación de la calidad del código generada por la IA (context rot)
  • Con comandos como /gsd:new-project, /gsd:plan-phase, /gsd:execute-phase, automatiza todo el ciclo de desarrollo: definición de la idea → planificación → ejecución → validación
  • Asegura trazabilidad y eficiencia con commits atómicos de Git por cada unidad de trabajo y ejecución en paralelo (wave execution)
  • Es una herramienta usada por ingenieros de Amazon, Google, Shopify y Webflow, orientada a mejorar la confiabilidad y productividad del desarrollo impulsado por IA

Resumen general

  • Get Shit Done (GSD) es un sistema ligero de metaprompts y gestión de contexto que funciona en diversos entornos de desarrollo con IA como Claude Code, OpenCode, Gemini CLI, Codex, Copilot y Antigravity
  • Resuelve el problema de context rot, donde la IA pierde calidad de contexto mientras escribe código, y genera resultados consistentes a partir de especificaciones
  • Funciona en Mac, Windows y Linux, y puede instalarse con el comando npx get-shit-done-cc@latest

Contexto de creación (Why I Built This)

  • Fue creado para resolver el problema de las herramientas para grandes organizaciones que exigen procesos innecesariamente complejos
  • GSD está diseñado bajo la idea de mantener la complejidad dentro del sistema y el flujo de trabajo simple
  • Internamente realiza ingeniería de contexto, formateo de prompts en XML, orquestación de subagentes y gestión de estado
  • El usuario puede completar un proyecto con comandos simples

Funciones principales y flujo de trabajo (How It Works)

  • Todo el proceso de desarrollo se compone de 6 etapas

    1. Inicialización del proyecto: consulta idea, restricciones, stack tecnológico, etc., y genera PROJECT.md, ROADMAP.md y más
    2. Etapa de discusión: define los detalles de implementación y genera CONTEXT.md
    3. Etapa de planificación: investigación en paralelo y elaboración del plan, con creación de unidades de trabajo en estructura XML
    4. Etapa de ejecución: ejecución paralela por waves basada en dependencias, con commit y validación por tarea
    5. Etapa de validación: pruebas automáticas y confirmación del usuario; si falla, genera automáticamente un plan de corrección
    6. Iteración y cierre de hitos: repetición de cada etapa y etiquetado de release al completar hitos

  • Quick Mode procesa rápidamente una sola tarea, y permite control detallado con los flags --discuss, --research y --full

Tecnología clave (Why It Works)

  • Ingeniería de contexto: gestiona el contexto completo del proyecto por archivos (PROJECT.md, REQUIREMENTS.md, STATE.md, etc.)
  • Formateo de prompts en XML: define claramente cada tarea e incluye procedimientos de validación
  • Orquestación multiagente: opera en paralelo con agentes especializados para investigación, planificación, ejecución y validación
  • Commits atómicos de Git: asegura trazabilidad y facilidad de recuperación con commits por cada unidad de trabajo
  • Diseño modular: permite agregar, insertar o modificar etapas libremente para una gestión flexible del proyecto

Sistema de comandos (Commands)

  • Flujo principal: /gsd:new-project, /gsd:plan-phase, /gsd:execute-phase, /gsd:verify-work
  • Soporte para diseño de UI: /gsd:ui-phase, /gsd:ui-review
  • Análisis del codebase: /gsd:map-codebase
  • Gestión del proyecto: /gsd:add-phase, /gsd:insert-phase, /gsd:complete-milestone
  • Utilidades: /gsd:quick, /gsd:health, /gsd:stats, /gsd:debug, /gsd:note, etc.

Ajustes y configuración (Configuration)

  • El archivo de configuración .planning/config.json permite controlar modo, nivel de detalle de las etapas, perfiles de modelo, agentes de flujo, paralelización y estrategia de branching en Git
  • Los perfiles de modelo pueden ser quality, balanced, budget o inherit
  • La calidad y velocidad pueden ajustarse con toggles como workflow.research, workflow.plan_check y workflow.verifier

Seguridad y resolución de problemas (Security & Troubleshooting)

  • Archivos sensibles como .env, secrets/, *.pem, *.key, etc., deben añadirse a la deny list de Claude Code para bloquear el acceso
  • Si después de la instalación hay errores de reconocimiento de comandos, se recomienda reiniciar el runtime o reinstalar
  • En entornos Docker, los problemas de ruta pueden resolverse configurando CLAUDE_CONFIG_DIR
  • La opción --uninstall permite eliminar todos los componentes

Comunidad y licencia

  • Cuenta con ports comunitarios para OpenCode, Gemini CLI y Codex
  • Se publica bajo licencia MIT
  • “Claude Code is powerful. GSD makes it reliable.” — una herramienta para reforzar la confiabilidad de Claude Code

Lecturas relacionadas

1 comentarios

 
GN⁺ 2026-03-19
Opiniones en Hacker News

  • Antes usaba Plan mode junto con Superpowers, pero al final sentí que solo con Plan mode bastaba
    Estos frameworks son buenos para tareas de fire-and-forget que requieren investigación, pero sentía que consumían más de 10 veces más tokens
    La diferencia en la calidad del resultado tampoco era tan grande, así que seguido me topaba con el límite de Max plan

    • Yo tomé las funciones de brainstorm·design·implementation planning de Superpowers y las conecté a una capa de implementación basada en Ralph
      Cuando termina el plan de implementación, sigue automáticamente sin pedirme input, pero tiene que ejecutarse dentro de un Docker sandbox
      Es por una configuración de permisos riesgosa, aunque de todos modos creo que así es más seguro
      Por ahora funciona bien y la productividad ha subido, pero siento que esto es una etapa intermedia del camino
    • Yo hice lo contrario: me pasé de Plan mode a Superpowers
      Volví a probarlo después del anuncio de la versión más reciente, y como tiene varias capas de cross-check y self-review, el resultado fue más estable
      Podría hacerlo manualmente, pero Superpowers automatiza ese proceso y fue mucho más cómodo
    • Probé la misma tarea con GSD y Plan Mode: Plan Mode terminó una implementación básica en 20 minutos, mientras que GSD tardó varias horas
      GSD produjo código considerando el contexto completo del proyecto, mientras que Plan Mode implementó justo lo necesario a nivel MVP
      Según el flujo de trabajo o el tamaño de la tarea, las ventajas y desventajas son muy claras
    • El Plan mode de GitHub Copilot se puso raro recientemente desde que agregaron plan memory
      La salida se volvió más verbosa y, al mismo tiempo, más vaga en los detalles
      Solo aumentaron pasos como “design” o “figure out”, y luego pasa directo a implementar sin preguntas de seguimiento
    • A mí me pasó algo parecido. Me gasté toda una semana de suscripción de Claude y créditos de API para sacar apenas unas 500 líneas de código
      A veces manipulaba las pruebas o producía resultados sin sentido
      Al final terminé guiándolo manualmente para completar el MVP, y eso fue mucho más eficiente

  • Últimamente hay demasiados meta frameworks de este tipo, pero casi no he visto ninguno que realmente demuestre productividad
    La mayoría solo desperdicia tokens y contamina la context window
    Al final, lo que mejor me funcionó fue mantenerlo simple: dar solo la información necesaria e iterar en el orden Plan → Code → Verify

    • En el texto de Apenwarr “The AI Developer’s Descent Into Madness”, se satiriza la situación en la que “el agente crea su propio framework”
    • Yo mismo hice un mini framework combinando Claude y Codex
      Cuando ves que Codex detecta errores que Claude por sí solo dejó pasar, sientes que no puedes confiar completamente en un solo agente
    • Yo uso un enfoque de diseño visual de especificaciones
      Diseño el flujo de pantallas de la app como imágenes y luego lo exporto a markdown estructurado; así el LLM entiende el contexto por pantalla
      Comparado con una especificación basada en texto, esto permite detectar antes estados faltantes o flujos de error
    • Al final, estos meta frameworks no son más que herramientas de personalización como .vimrc o .emacs.d
      Son útiles para quien los crea, pero a los demás pueden parecerles inútiles

  • Yo creo que los sistemas Spec-Driven están condenados al fracaso
    Las especificaciones escritas en inglés no logran conectar el código real con el comportamiento
    Este problema ya está resuelto con pruebas automatizadas
    Hay que codificar el comportamiento del sistema como pruebas ejecutables
    Incluso cuando el LLM genera la implementación, primero debería escribir las pruebas y validar la consistencia con mutation testing
    Reuní material relacionado en este artículo y en este ejemplo de GitHub

    • Las especificaciones en lenguaje natural no escalan, pero si a partir de ellas se construye una especificación formal (formal spec), sí podría haber posibilidades
      Al final tiene que expresarse en forma de código
    • También había un texto que decía “A sufficiently detailed spec is code”, pero no pude reproducir los resultados de OpenAI
      Consulta este enlace
    • Spec Driven Development se parece a TDD en el nombre, pero en dirección es exactamente lo contrario
    • Ver las pruebas solo como el resultado de la especificación es una lógica equivocada
      La especificación cubre un campo mucho más amplio que las pruebas
      Además, muchas veces el LLM ignora las pruebas o las modifica arbitrariamente

  • Estoy usando un sistema de IA personal y estoy pensando si hacerlo público o no
    Está tan personalizado para mi trabajo que mantener una versión pública por separado sería una carga
    Más que hacer que otros lo usen directamente, me gustaría compartir solo los patrones, tomando mi sistema como referencia

    • No es obligatorio darle mantenimiento
      En la era de la IA, compartir simplemente inspiración e ideas ya tiene bastante valor

  • Probé GSD en un hackatón de equipo, pero tardó demasiado en entender el codebase y el consumo de tokens fue brutal
    Además, hubo muchos errores al generar los transcripts del agente
    Para crear unas cuantas funciones pequeñas era una herramienta excesiva
    La lección fue simple: escribir buenas especificaciones + iterar en Plan mode fue mucho más eficiente

  • Las restricciones de diseño de Beads me parecían frustrantes, así que hice una herramienta parecida por mi cuenta
    Mi versión está basada en SQLite y además le agregué sincronización bidireccional con GitHub
    La clave está en conversar primero con el modelo para crear un archivo de especificación claro
    Si ese archivo existe, el modelo no se olvida, y mientras más detalles tenga, mejor sale la calidad de la salida
    Implementé como prototipo una idea que llevaba mucho tiempo imaginando con Claude, y salió mejor de lo esperado

    • Como “salsa secreta”, RPI (research-plan-implement) no da para tanto; ya es un concepto que aparece en la documentación oficial
      El modelo sigue siendo un sistema estocástico, así que tener memoria perfecta es imposible
      Presentarlo como si fuera un nuevo truco revolucionario es exagerado

  • Probé Superpowers y este GSD también se ve parecido, así que me daba curiosidad compararlos

    • He usado ambos, y GSD es excesivamente complejo y lento
      Quick mode hace que pierda su propósito original, y Superpowers me pareció un punto medio razonable
    • Los prompts estructurados sí ayudan
      Si metes este tipo de framework en el repositorio y haces que la IA mejore el propio framework, también puede servir para trabajo creativo
      Aun así, este tipo de estructura parece más bien un hack temporal; cuando los modelos estén suficientemente entrenados, probablemente desaparezca de forma natural
    • En la etapa de planificación, Superpowers escribe todo el código de una vez, y luego los subagentes solo lo copian tal cual, así que era ineficiente
      GSD resolvió ese problema, pero como tiene demasiadas etapas, termina siendo lento
    • Probé Superpowers migrando mi blog de Hugo a Astro
      La especificación que generó Superpowers era detallada, pero le faltaban algunas funciones (por ejemplo, RSS y analítica), mientras que una especificación colaborativa que proponía migración en paralelo era más flexible
      Al final hice que Claude comparara e integrara ambas especificaciones para obtener la versión final
      Consulta la comparación detallada
    • No sé si realmente hace falta un wrapper de CLI
      Con Claude skills también se puede implementar suficientemente bien

  • He usado GSD intensivamente durante 3 meses, y está mucho más pulido que speckit, que era lo que usaba antes
    Incluso tareas complejas las automatiza hasta un 95%
    El 5% restante lo cierro con pruebas manuales
    Con esto incluso lancé un producto SaaS (whiteboar.it)
    El modelo en sí también ha mejorado, pero el aumento de productividad fue evidente

    • Yo tuve una experiencia parecida
      Como me dolía pagar la suscripción de FreshBooks, hice mi propia app de macOS en Swift con GSD
      Implementé extracción automática de recibos y clasificación por categorías con la API de Anthropic
      Empezó como webapp, pero al agregar funciones como integración con cámara terminó evolucionando a una app de escritorio completa
      Gracias a GSD pude terminar mi app personal de contabilidad

  • Al final, la herramienta que de verdad hace falta es una que ahorre tokens
    Pero todavía no existe algo así
    Claude Code también gasta demasiados tokens en proyectos grandes

  • El nombre de “este paquete de archivos Markdown” da demasiado cringe

    • Tal vez habría quedado mejor si estuviera bajo una carpeta llamada “Languages”
    • Aun así, no es peor que “gstack”, ¿o sí?