Lo viviste. Abrís Claude Code, te quedás mirando un prompt en blanco, y empezás a escribir alguna versión de “armame esta feature”. Funciona… más o menos. La arquitectura es la que Claude tuvo ganas de hacer ese día. Nadie revisó el plan. El QA sos vos haciendo clic por todos lados rezando que no se rompa nada. Y hacer ship es cruzar los dedos con el PR.
Ahora imaginate que, antes de que se escriba una sola línea, un CEO te cuestiona el scope, un eng manager fija la arquitectura, un diseñador caza el AI slop, un reviewer persigue los bugs que pasan el CI pero explotan en producción, un QA lead abre un browser real y hace clic por todos tus flows, y un release engineer hace ship del PR — todos disponibles, todos disparados con slash commands.
Eso es gstack. Y es el setup que Garry Tan —presidente y CEO de Y Combinator— usa para construir todos los días. Lo abrió como open source. Licencia MIT. Gratis, sin tier premium, sin waitlist.
Qué es realmente
gstack convierte a Claude Code en un equipo de ingeniería virtual. Veintitrés especialistas más ocho power tools, todos en Markdown, todos slash commands. Cada uno cumple un rol que normalmente necesitarías un equipo entero para cubrir:
/office-hours— el tratamiento de las office hours de YC. Seis preguntas que te fuerzan a replantear tu producto antes de escribir código. Te discute el enfoque y te cuestiona las premisas./plan-ceo-review— repiensa el problema y busca el producto 10-star escondido dentro de tu pedido./plan-eng-review— fija arquitectura, data flow, edge cases y tests. Saca a la luz los supuestos ocultos./review— el staff engineer que encuentra los bugs que pasan el CI pero explotan en prod. Auto-arregla los obvios./qa— abre un browser real, hace clic por tus flows, encuentra bugs, los arregla y genera tests de regresión para cada fix./cso— un chief security officer que corre un threat model OWASP Top 10 + STRIDE, con un escenario de exploit concreto para cada hallazgo./ship— sincroniza main, corre los tests, audita la cobertura y abre el PR. Te arma un framework de tests desde cero si no tenés uno.
Eso es apenas una parte. También está /investigate para debugging sistemático de root-cause, /design-shotgun para generar variantes de mockups, /document-release para que tus docs no queden desactualizados, y más.
La idea de fondo: es un proceso, no una pila de herramientas
Esta es la parte que importa. gstack no son 23 comandos sueltos — es un sprint. Las skills corren en el orden en que corre un sprint real:
Think → Plan → Build → Review → Test → Ship → Reflect
Y cada paso alimenta al siguiente. /office-hours escribe un design doc que lee /plan-ceo-review. /plan-eng-review escribe un plan de tests que toma /qa. /review caza bugs que /ship verifica que realmente estén arreglados. Nada se cae por las grietas, porque cada paso sabe lo que vino antes.
Y si no querés correrlos uno por uno, /autoplan encadena las reviews de CEO, diseño e ingeniería de forma automática y solo te trae las decisiones de criterio que realmente necesitan tu input.
Cómo se ve una sesión
Decís “quiero armar una app de briefing diario para mi calendario”. Corrés /office-hours. En vez de simplemente darte la razón, el agente te discute: dijiste “app de briefing diario”, pero lo que describiste es una IA tipo chief of staff personal. Extrae capacidades que no te habías dado cuenta que estabas describiendo, te cuestiona las premisas y te entrega tres enfoques de implementación con estimaciones de esfuerzo.
Después /plan-eng-review dibuja el data flow y mapea los failure modes. Aprobás el plan. Claude escribe el código. /review auto-arregla dos problemas y te marca un race condition para que apruebes el fix. /qa abre un browser contra staging, encuentra un bug, lo arregla. /ship abre el PR con los tests nuevos agregados.
Ocho comandos, de punta a punta. Eso no es un copilot. Es un equipo.
No es solo para Claude Code
Aunque está construido alrededor de Claude Code, el setup detecta automáticamente qué agentes tenés instalados y funciona en diez de ellos — Codex CLI, OpenCode, Cursor, Factory Droid y otros. Además hay un power tool /codex que trae una segunda opinión independiente desde el Codex CLI de OpenAI, así tenés un modelo distinto mirando el mismo diff y una comparación cross-model de lo que marcó cada uno.
Cómo instalarlo
Abrí Claude Code y pegá la instrucción de instalación — clona el repo en ~/.claude/skills/gstack, corre el setup script y agrega una sección de gstack a tu CLAUDE.md con la lista de skills disponibles. Treinta segundos, y Claude hace el resto.
Una vez que lo tenés, el primer recorrido recomendado es bien simple:
/office-hours— describí qué estás construyendo/plan-ceo-reviewsobre cualquier idea de feature/reviewsobre cualquier branch con cambios/qasobre tu URL de staging
Pará ahí. Bastante rápido vas a saber si es para vos.
Por qué importa para nuestro workflow
La afirmación interesante detrás de gstack no es un número — es un cambio en cómo una sola persona puede trabajar. Todo el argumento de Tan es que un builder solo con el tooling correcto se mueve más rápido que un equipo tradicional, y está shippeando el output de un equipo entero para demostrarlo. Para los equipos de desarrollo de Iberoamérica, esa es la misma palanca, apuntada a la eficiencia: roles estructurados y un pipeline de review forzado significan que un equipo chico puede shippear con el rigor de uno mucho más grande, sin tener que sumar headcount para lograrlo.
Y como es un proceso —no un prompt ingenioso que copiás una vez y te olvidás— se sostiene a lo largo de todo un sprint en vez de evaporarse después de la primera respuesta.
Todo está en GitHub, con licencia MIT, gratis para siempre.
¿Vos cómo venís usando Claude Code hoy — prompt en blanco o ya armaste tu propio flujo de skills? Contanos en los comentarios.