G Stack — tu equipo de IA dentro de Claude Code

Garry Tan es el presidente y CEO de Y Combinator, la incubadora de donde salieron Airbnb, Dropbox, Stripe y cientos de startups más. Un día agarró la configuración exacta de Claude Code que usa para construir, y la subió a GitHub gratis. Eso es G Stack: no un programa nuevo que tenés que aprender, sino el mismo Claude Code que ya usás, pero con 23 herramientas encima que lo vuelven un equipo de desarrollo completo.

La idea es simple. Claude de fábrica es como una persona brillante que sabe de todo pero no tiene un proceso. G Stack le da ese proceso: 23 comandos opinados que cubren los seis roles de un equipo real —estratega, diseñador, manager de ingeniería, revisor de seguridad, QA y release manager—. Le escribís /autoplan y Claude ya sabe planear como un equipo; le escribís /qa y prueba tu app en un navegador real; le escribís /ship y la publica. Vos no programás: dirigís.

Y no es teoría: Garry lo usa para construir él solo. Según cuenta, sacó tres servicios en producción y más de cuarenta funciones en sesenta días, medio tiempo, mientras dirige Y Combinator. El repo ya pasó las cien mil estrellas en GitHub. Abajo te explico cada rol, cómo instalarla sin abrir una terminal aparte, y cómo combinarla según lo que quieras lograr.

Según el repositorio oficial, G Stack pasó las 100 mil estrellas en GitHub — una de las herramientas de Claude Code más populares que existen.

La descripción oficial de G Stack lo dice claro: son herramientas que hacen de CEO, diseñador, manager de ingeniería, release manager, doc engineer y QA. En vez de un Claude genérico, tenés seis especialistas que se pasan el trabajo de uno a otro. Acá está qué hace cada uno y con qué comandos lo llamás.

Acá está la clave que mucha gente no agarra: todo pasa adentro de Claude Code. No tenés que abrir una terminal por tu cuenta ni pelearte con comandos. Le pegás un prompt a Claude, él corre lo que haga falta y te va confirmando cada paso. Igual te dejo el comando manual por si lo querés correr vos.

Antes de arrancar necesitás Claude Code andando, Git y Bun (v1.0 o más). En Windows, además, Node. Si te falta algo, el prompt de abajo se lo pide a Claude y él te lo instala. Si recién caés a Claude Code, mirá primero la guía de Claude Code 0 a 100.

Quiero instalar G Stack (el setup de Claude Code de Garry Tan) en esta máquina. Hacelo vos, paso a paso, sin que yo tenga que abrir otra terminal:

1. Revisá si tengo Git y Bun (v1.0 o más). Si me falta alguno, instalámelo y avisame qué corriste.
2. Instalá G Stack con este comando:
   git clone --single-branch --depth 1 https://github.com/garrytan/gstack.git ~/.claude/skills/gstack && cd ~/.claude/skills/gstack && ./setup
3. Agregá al CLAUDE.md de este proyecto una sección que liste las herramientas de gstack disponibles.
4. Verificá que quedó: probá /autoplan y confirmame que responde.

Mostrame cada comando antes de correrlo. Si algo falla, explicame el error en palabras simples y qué hago. No inventes pasos que no estén acá.

Decime si G Stack ya está instalada en esta máquina y lista para usar:

1. Revisá si existe la carpeta ~/.claude/skills/gstack.
2. Probá si el comando /autoplan está disponible.
3. Decime qué versión tengo y si conviene actualizar.

Si está todo bien, resumime con qué comandos arranco. Si falta algo, mostrame el comando para completarlo y esperá mi OK antes de correrlo.

De las 23 herramientas, estas son las nueve que más se usan en el día a día. Para cada una te dejo qué hace, cuándo conviene usarla y un prompt de guía: lo escribís dentro de Claude Code en lenguaje normal y él se encarga. No hace falta memorizar nada.

Quiero construir [describí tu idea en una frase]. Antes de tocar código, usá /office-hours: interrogame con preguntas una por una sobre el alcance, los usuarios, los casos borde y qué NO debe hacer. No escribas nada hasta que el alcance quede cerrado y me lo resumas para que yo confirme.

Ya tengo claro qué quiero construir: [pegá acá lo que cerraste con /office-hours]. Ahora usá /autoplan para armar el plan completo —revisión de producto, diseño e ingeniería— y mostrámelo antes de implementar nada. Marcá los supuestos y los riesgos que veas. No empieces a programar hasta que yo apruebe el plan.

Usá /design-shotgun para [la pantalla o componente, ej. la landing]. Generame varias versiones distintas para comparar, pensadas para [tu público o producto]. Cuando elija una, aprendé de mi elección y dejá las demás como referencia. No pases a código todavía: primero quiero ver las opciones.

Ya elegí el diseño de [la pantalla]. Usá /design-html para convertirlo en HTML y CSS listos para producción, que se vean bien en celular y en escritorio. Mantené el estilo de la versión que aprobé y mostrame el resultado antes de integrarlo al proyecto.

Acabás de implementar [la función]. Usá /review para revisar el código como un ingeniero senior: buscá bugs de producción, arreglá los obvios vos mismo y marcame lo dudoso para que yo decida. Resumime qué arreglaste y qué dejaste pendiente, en palabras simples.

Usá /cso para revisar la seguridad de este proyecto antes de publicarlo. Buscá vulnerabilidades comunes (OWASP, STRIDE), enfocate en [logins / pagos / datos de usuarios] y mostrame solo los riesgos reales, ordenados por gravedad, con qué hago para arreglar cada uno en palabras simples.

Usá /qa sobre [la URL de tu app, ej. http://localhost:3000]. Probá los flujos principales —[ej. registro, login, crear algo]— como lo haría un usuario real. Si encontrás errores, arreglalos y dejá una prueba para que no vuelvan. Al final, resumime qué probaste, qué falló y qué arreglaste.

El cambio de [la función] ya está revisado y probado. Usá /ship: sincronizá con la rama principal, corré las pruebas, subí el código y abrí el Pull Request. Antes de subir, mostrame un resumen de qué incluye el PR. Si algo de las pruebas falla, pará y avisame.

El Pull Request de [la función] ya está aprobado. Usá /land-and-deploy: fusionalo, esperá a que pase el CI, desplegá a producción y verificá que la página quede sana. Si el despliegue falla o la verificación da problemas, pará, explicame qué pasó y no sigas hasta que yo confirme.

No siempre necesitás todo el equipo. Lo bueno de G Stack es que encadenás los comandos según el objetivo. Acá van cuatro combos que cubren la mayoría de los casos — cada uno con un prompt que orquesta toda la cadena de un tirón.

Quiero construir [la función] de cero a producción usando G Stack. Seguí este flujo y pará en cada paso para que yo apruebe antes de seguir:

1. /office-hours para cerrar el alcance conmigo.
2. /autoplan para armar el plan completo. Mostrámelo y esperá mi OK.
3. Implementá contra ese plan.
4. /review para revisar el código.
5. /qa sobre [la URL] para probarlo en un navegador real.
6. /ship para subirlo y abrir el PR.
7. /land-and-deploy cuando yo apruebe el PR.

Hablame en español y, si algo falla, explicámelo simple antes de seguir.

Quiero mejorar el diseño de [la pantalla] sin tocar la lógica. Combiná así:

1. /design-shotgun para darme varias versiones y que yo elija.
2. /design-html para convertir la que elija en código listo.
3. /design-review para pulir detalles y corregir lo que quede flojo.

Pará después del paso 1 para que yo elija la versión. Mostrame el resultado de cada paso.

Tengo este problema: [describí el bug y, si tenés, pegá el error]. Combiná así para resolverlo:

1. /investigate para encontrar la causa de raíz, probando hipótesis paso a paso.
2. /review para arreglar el código sin romper lo que ya andaba.
3. /qa sobre [la URL] para confirmar que el flujo afectado ya funciona y dejar una prueba.

Explicame en palabras simples cuál era la causa y qué cambiaste.

Antes de publicar [la función, que maneja logins/pagos/datos], quiero una pasada de seguridad. Combiná así:

1. /cso para revisar vulnerabilidades (OWASP, STRIDE) y mostrarme solo los riesgos reales, por gravedad.
2. /review para arreglar lo que salga.
3. /ship recién cuando no queden riesgos altos.

Pará después del paso 1 para que yo vea los riesgos antes de tocar nada.

Por debajo de todo, G Stack sigue siempre el mismo proceso: siete pasos que van de la idea a publicado y de vuelta. No tenés que usarlos todos siempre, pero este es el orden en el que el equipo se pasa el trabajo.

Acá tenés las herramientas agrupadas por fase, como referencia. Cada una es un comando que le escribís a Claude y él ya sabe qué hacer. No hace falta usarlas todas: con las nueve de arriba ya construís de cero a publicado.