Imagina que pudieras clonar a 20 ingenieros seniors, cada uno especialista en algo distinto, y ponerlos a trabajar en tu proyecto al mismo tiempo. Uno revisa código, otro hace QA con un navegador real, otro audita seguridad, otro te cuestiona la idea de producto antes de escribir una línea. No es un pitch de startup, es lo que Garry Tan dice que construyó con gstack, y 37,000 personas en GitHub parecen estar de acuerdo.
Pero antes de que pienses que esto es otro hilo de Twitter vendiendo humo, vamos a desarmarlo pieza por pieza. Lo bueno, lo cuestionable, y lo que realmente importa si trabajas en tecnología, marketing o producto.
tabla de contenido
- qué es gstack, explicado sin jerga
- la filosofía "boil the lake" y por qué importa
- los 28 skills explicados para humanos normales
- qué dicen los usuarios reales
- el "es solo markdown" y por qué eso importa
- el workflow completo en la práctica
- para no-programadores: por qué esto te importa
- gstack vs. el resto
- cómo instalarlo y empezar
- el veredicto honesto
qué es gstack, explicado sin jerga
gstack es un conjunto de 28 archivos Markdown que le dicen a Claude Code (la herramienta de programación con IA de Anthropic) cómo comportarse en diferentes situaciones. Piensa en ellos como "modos" o "personalidades especializadas" que activas con un comando.
Cuando abres Claude Code normalmente, tienes un asistente genérico que puede hacer de todo pero no es experto en nada. gstack le da instrucciones específicas para cada tarea: cuando le dices /review, se convierte en un ingeniero senior revisando código. Cuando le dices /qa, se convierte en un tester que abre un navegador real y hace clic en cosas. Cuando le dices /office-hours, se convierte en un mentor de Y Combinator que te hace preguntas incómodas sobre tu producto.
Para los que no programan: imagina que tienes un empleado muy capaz pero sin experiencia. gstack es como darle un manual de procedimientos para cada rol. "Cuando hagas QA, sigue estos 15 pasos, verifica estas cosas, genera este reporte." El empleado es el mismo, pero su output cambia completamente según el manual que le das.
Técnicamente, gstack incluye un navegador headless (Chromium que corre sin interfaz gráfica) construido con Bun y Playwright que responde en ~100 milisegundos por comando. Esto es lo que permite hacer QA real: navegar páginas, llenar formularios, tomar screenshots, verificar que los botones funcionan.
los datos duros
- Creador: Garry Tan, CEO de Y Combinator
- Lanzamiento: 12 de marzo de 2026
- Licencia: MIT (código abierto, gratis, para siempre)
- GitHub stars: ~37,300 (23,000+ en la primera semana)
- Forks: 2,200+
- Skills: 28 modos especializados
- Compatibilidad: Claude Code, Codex CLI, Gemini CLI, Cursor
la filosofía "boil the lake" y por qué importa
Garry tiene una tesis simple que sustenta todo gstack: la completitud ahora es barata.
Históricamente, cuando un equipo de software planificaba un feature, siempre había un tradeoff. "Podemos cubrir el 90% de los casos en 3 días, o el 100% en 2 semanas. Vamos con el 90%." Esa decisión existía porque el tiempo de ingeniería humana era caro y escaso. Cada hora de programador costaba dinero real.
Con IA asistiendo el código, ese cálculo cambia. La diferencia entre escribir 80 líneas (solución parcial) y 150 líneas (solución completa) es cuestión de segundos. Agregar tests, manejar edge cases, escribir documentación, todo eso que los equipos "dejaban para después" (y nunca hacían) ahora cuesta minutos.
Garry lo llama "boil the lake": hervir el lago. Puedes hacerlo. Lo que no puedes es hervir el océano, y la clave está en distinguir cuándo algo es un lago (alcanzable, finito) y cuándo es un océano (reescribir todo desde cero, migración de plataforma de 6 meses).
Del ETHOS.md de gstack:
"Una sola persona con IA puede construir ahora lo que antes requería un equipo de veinte. La barrera de ingeniería desapareció. Lo que queda es gusto, juicio, y la voluntad de hacer la cosa completa."
Las ratios de compresión que documenta gstack son agresivas:
| Tipo de tarea | Equipo humano | Con IA + gstack | Compresión |
|---|---|---|---|
| Boilerplate / scaffolding | 2 días | 15 min | ~100x |
| Escritura de tests | 1 día | 15 min | ~50x |
| Implementación de features | 1 semana | 30 min | ~30x |
| Bug fix + test de regresión | 4 horas | 15 min | ~20x |
| Arquitectura / diseño | 2 días | 4 horas | ~5x |
| Investigación / exploración | 1 día | 3 horas | ~3x |
Antes de que alguien pregunte: sí, estas cifras son cuestionables. Pero el punto no es si es exactamente 50x o 30x, sino que la dirección es correcta. Tareas repetitivas y bien definidas se comprimen dramáticamente. Tareas que requieren juicio humano (arquitectura, investigación) se comprimen menos. Eso tiene sentido.
Lo interesante de "boil the lake" como filosofía de producto es que cambia las decisiones de un equipo. En lugar de "vamos con el MVP mínimo", la pregunta pasa a ser "si completar esto cuesta solo 15 minutos más, por qué no hacerlo bien desde el principio?"
los 28 skills explicados para humanos normales
Aquí es donde gstack deja de ser un concepto y se vuelve tangible. Los 28 skills se agrupan naturalmente por lo que hacen, no por cómo están implementados.
planificación y estrategia de producto
Estos skills son para antes de escribir código. Son los que más valor tienen para fundadores, PMs y marketers que trabajan con equipos técnicos.
/office-hours es probablemente el skill más original. Simula una sesión de Office Hours de Y Combinator, el formato donde fundadores presentan su idea y los partners de YC les hacen preguntas difíciles. El skill te hace 6 preguntas forzadas que reencuadran tu producto antes de tocar código.
El ejemplo del README es revelador: alguien dice "quiero hacer una app de briefing diario para mi calendario." El skill responde: "Lo que describiste no es un briefing diario. Es un chief of staff personal con IA." Y extrae 5 capacidades que el usuario no sabía que estaba describiendo.
Garry tuiteó que "Twitter chino dijo que /office-hours en gstack no era suficientemente duro con los fundadores, así que los hice más duros." Y hay reportes de aplicantes a YC S26 usando /office-hours para validar sus aplicaciones.
/plan-ceo-review toma un plan o diseño de producto y lo revisa como lo haría un CEO/fundador. Tiene 4 modos: expansión (pensar más grande), expansión selectiva (expandir partes específicas), mantener scope, y reducción (cortar lo innecesario). Corre una revisión de 10 secciones buscando el "producto 10 estrellas" escondido dentro del requerimiento.
/plan-eng-review es el complemento técnico. Genera diagramas ASCII de flujo de datos, máquinas de estado, caminos de error. Fuerza a que las suposiciones escondidas salgan a la luz. Produce una matriz de tests, modos de fallo y preocupaciones de seguridad.
/plan-design-review califica cada dimensión de diseño del 0 al 10, explica cómo se vería un 10, y edita el plan para llegar allá. Incluye detección de "AI slop" (ese aspecto genérico y plástico que tienen las interfaces generadas por IA sin dirección).
/autoplan corre los tres reviews automáticamente en secuencia (CEO, diseño, ingeniería), aplicando principios de decisión codificados. Solo te muestra las decisiones que requieren gusto humano.
desarrollo y código
/review es el code review automatizado. Busca bugs que pasan CI pero explotan en producción. Auto-corrige los obvios y marca los que necesitan atención. Garry tuiteó que un amigo CTO le mandó mensaje: "Tu gstack es una locura. Esto es como god mode. Tu revisión de ingeniería descubrió un ataque de cross-site scripting sutil."
/investigate es debugging sistemático. Tiene una "ley de hierro": no arregles nada sin investigar primero. Traza flujo de datos, prueba hipótesis, y se detiene automáticamente después de 3 intentos fallidos para escalar al humano. "El trabajo malo es peor que no trabajar," dice la documentación.
/codex es la segunda opinión. Usa OpenAI Codex CLI para hacer una revisión independiente del código. Tres modos: revisión (pasa/no pasa), desafío adversarial, y consulta abierta. Cuando tanto /review como /codex han corrido, genera un análisis cruzado entre modelos.
/ship es el release engineer. Sincroniza con main, corre tests, audita cobertura, push, abre PR. Si no tienes framework de testing, te bootstrapea uno.
/document-release actualiza toda la documentación del proyecto para reflejar lo que acabas de enviar. Detecta READMEs obsoletos automáticamente.
QA y testing
Aquí es donde el navegador headless de gstack brilla.
/browse es un navegador Chromium real, corriendo headless, con ~100ms por comando. Puedes navegar URLs, hacer clic en elementos, llenar formularios, tomar screenshots, verificar estados de elementos. Es persistente entre llamadas: las cookies, sesiones de login y tabs se mantienen.
Un usuario de Hacker News (madrox) lo describió como "superior a la extensión built-in de Claude en todos los sentidos excepto gestión de cookies." Y la gestión de cookies tiene su propio skill.
/qa usa el navegador para testear tu app, encontrar bugs, arreglarlos con commits atómicos, y re-verificar. Auto-genera tests de regresión para cada fix. No es solo "mira si se ve bien", sino "llena el formulario, envíalo, verifica que apareció el mensaje de éxito, revisa la consola por errores de JavaScript."
/qa-only es la versión "solo reportar". Misma metodología que /qa pero sin tocar código. Genera un reporte de bugs puro, útil cuando quieres revisar antes de autorizar cambios.
Growth MarketingEl 95% de los pilotos de IA fallan. Este sistema es para el otro 5%.
Inmersión presencial con tus datos, tus campañas y tu equipo. Salen operando agentes desde la primera sesión, no con apuntes.
Ver si aplica para mi equipo →/design-review audita el diseño visual y luego arregla lo que encuentra. Commits atómicos, screenshots de antes y después.
/setup-browser-cookies importa cookies de tu navegador real (Chrome, Arc, Brave, Edge) a la sesión headless. Esto permite testear páginas autenticadas sin tener que hacer login manualmente cada vez.
seguridad
/cso (Chief Security Officer) corre una auditoría OWASP Top 10 + modelo de amenazas STRIDE. Tiene 17 exclusiones de falsos positivos para reducir ruido, un gate de confianza de 8/10+, y verificación independiente de cada hallazgo. Cada finding incluye un escenario concreto de exploit, no solo "esta línea podría ser vulnerable."
/careful activa guardrails de seguridad. Alerta antes de comandos destructivos como rm -rf, DROP TABLE, force-push. Lo activas diciendo "be careful" y puedes hacer override de cualquier alerta.
/freeze restringe ediciones de archivo a un directorio específico. Previene cambios accidentales fuera del scope mientras debuggeas. /guard combina /careful + /freeze en un solo comando. /unfreeze quita las restricciones.
productividad y operaciones
/retro genera una retrospectiva semanal con datos reales. Breakdown por persona, rachas de envío, tendencias de salud de tests, oportunidades de crecimiento. /retro global corre a través de todos tus proyectos y herramientas de IA (Claude Code, Codex, Gemini).
Garry tuiteó: "Aunque no usaras nada más de gstack, es útil usar retro para visualizar tu última semana." Ese tweet tuvo 16,800 vistas.
/gstack-upgrade es el auto-actualizador. Detecta instalación global vs vendored, sincroniza ambas, muestra qué cambió.
despliegue
/land-and-deploy hace merge del PR, espera CI y deploy, verifica salud de producción. Un solo comando desde "aprobado" hasta "verificado en producción."
/canary es monitoreo post-deploy. Vigila errores de consola, regresiones de performance, y fallas de página en un loop.
/benchmark establece baselines de tiempos de carga, Core Web Vitals, y tamaño de recursos. Compara antes/después en cada PR.
/setup-deploy es configuración de una sola vez para el deploy. Detecta tu plataforma, URL de producción, y comandos de deploy.
qué dicen los usuarios reales
lo bueno
Los usuarios que reportan resultados positivos tienden a ser desarrolladores que ya estaban usando Claude Code y buscaban más estructura.
"Le di una oportunidad ayer, y resultó ser muy efectivo para mí... La aplicación que he estado desarrollando se ve mucho más pulida ahora."
madrox en Hacker News fue más específico sobre cuáles skills le sirvieron:
"Los skills de plan ayudan a detectar vacíos en los planes de Claude (que frecuentemente tienen puntos ciegos enormes)."
Sobre el navegador:
"Superior a la extensión built-in de Claude en todos los sentidos excepto gestión de cookies."
Luong Nguyen documentó en Substack una experiencia interesante: empezó con un script básico de deduplicación, pero el modo CEO replanteó el proyecto completo como "npm para skills de agentes de IA" con descubrimiento, versionado, y resolución de dependencias. gstack le dijo, básicamente, "tu idea es mucho más grande de lo que crees."
Hay un ecosistema emergente de forks y extensiones. gstack++ fue adaptado para desarrollo en C++. K9 Audit fue creado como complemento de seguridad. Aplicantes a YC S26 están usando /office-hours para preparar sus aplicaciones.
lo malo
La crítica más común y más justa es que gstack, en su esencia, son archivos Markdown con instrucciones. fdghrtbrt en Hacker News:
"Es un montón de archivos diciéndole a Claude que pretenda ser diferentes personas."
Mammoth-Error1577 en Reddit fue al grano:
"Proporcionarle numerosos prompts motivacionales como 'Eres un experto élite de control de calidad' parece innecesario."
Y tienen un punto. La pregunta real es: funciona o no funciona? El prompt engineering con LLMs es contraintuitivo. A veces darle un rol específico a un modelo produce resultados mediblemente mejores, aunque la razón exacta sea difícil de explicar. Pero es válido cuestionar si 28 roles diferentes realmente producen 28 outputs diferentes, o si muchos convergen en lo mismo.
lo controversial
Hay tres controversias que vale la pena examinar.
Las líneas de código como métrica. Garry afirma ~10,000 LOC/día y 600,000 líneas en 60 días. En Hacker News, esto fue criticado duramente. Las líneas de código como métrica de productividad han sido descartadas por la industria de software durante décadas. Fred Brooks lo decía en 1975: más líneas no significan más valor. Un refactor que elimina 500 líneas puede ser más valioso que uno que agrega 5,000.
La defensa de Garry: con IA, las líneas incluyen tests (35% del total), documentación y cobertura completa de edge cases, cosas que normalmente se cortan. No es code bloat, es completitud. Pero la métrica sigue siendo discutible.
La fama vs. el mérito. Sherveen lo dijo directo: "Si no fueras el CEO de YC, esto no estaría en Product Hunt." Y probablemente tiene razón. 23,000 stars en una semana no es orgánico puro, es el efecto de red de ser una de las personas más conectadas en Silicon Valley. Eso no invalida la herramienta, pero sí contextualiza la adopción.
El "cyber psychosis" y dormir 4 horas. Mo Bitar publicó un video titulado "AI is making CEOs delusional" donde argumenta que la IA está creando una ilusión de productividad en ejecutivos que no pueden evaluar la calidad del código que "producen." Garry ha mencionado sesiones de programación a altas horas y dormir poco, lo cual generó preocupación legítima sobre la diferencia entre productividad real y adicción a la dopamina de ver código aparecer en pantalla.
Esto toca un nervio real en la industria: hay una diferencia entre construir rápido y construir bien. gstack intenta cerrar esa brecha con skills de review, QA y seguridad, pero el hecho de que necesites 28 modos diferentes para compensar los riesgos de velocidad dice algo sobre el problema subyacente.
La plataforma vs. el valor directo. Un análisis del skill /office-hours mostró que ~35% del contenido es infraestructura de la plataforma (telemetría, configuración, detección de modo), no valor directo para el usuario. Esto es normal en software, pero es relevante cuando el pitch es "son solo archivos Markdown."
el "es solo markdown" y por qué eso importa
Garry respondió a la crítica "es solo markdown" de una forma que merece desempacarse:
"Es solo markdown. Pero ahora markdown ES CÓDIGO. Los LLMs significan que la inteligencia está disponible como un grifo."
Esta es una observación genuinamente importante, independientemente de lo que pienses de gstack. Históricamente, el código tenía que ser ejecutable por una máquina. Python, JavaScript, Rust: instrucciones que una computadora puede seguir paso a paso. Markdown no era código, era documentación.
Con LLMs, eso cambió. Un archivo Markdown con instrucciones bien escritas puede producir comportamiento tan específico y reproducible como un script de Python. La diferencia es que el "intérprete" no es una máquina determinística sino un modelo de lenguaje probabilístico, lo cual tiene implicaciones enormes sobre confiabilidad, pero el punto base es válido: las instrucciones en lenguaje natural ahora son una forma de programación.
Esto tiene consecuencias prácticas para gente que no programa. Si sabes escribir instrucciones claras y específicas (que es exactamente lo que hacen buenos marketers, PMs y fundadores), puedes "programar" comportamiento de IA sin saber Python. gstack es un ejemplo extremo de esto: 28 "programas" escritos en lenguaje natural.
el workflow completo en la práctica
Para entender gstack hay que verlo como un proceso, no como una colección de herramientas. Los skills corren en el orden en que corre un sprint de desarrollo:
Pensar, planificar, construir, revisar, testear, enviar, reflexionar.
Cada skill alimenta al siguiente. /office-hours escribe un documento de diseño que /plan-ceo-review lee. /plan-eng-review escribe un plan de tests que /qa recoge. /review detecta bugs que /ship verifica como arreglados. Nada se cae entre las grietas porque cada paso sabe lo que vino antes.
Un flujo típico se ve así:
Tú: Quiero construir un dashboard de analytics para mi blog.
Tú: /office-hours
Claude: [te hace preguntas difíciles sobre el dolor real, no el feature]
Tú: No sé qué artículos convierten, cuáles traen tráfico orgánico,
cuáles debería actualizar...
Claude: Espera. No quieres un dashboard de analytics. Quieres un
sistema de decisión editorial basado en datos.
[extrae 5 capacidades que no sabías que necesitabas]
[cuestiona 4 premisas, aceptas, rechazas o ajustas]
[genera 3 enfoques de implementación con estimados]
RECOMENDACIÓN: envía la cuña más estrecha mañana, aprende
de uso real.
[escribe documento de diseño]
Tú: /plan-ceo-review
[lee el documento, cuestiona scope, corre revisión de 10 secciones]
Tú: /plan-eng-review
[matriz de tests, modos de fallo, preocupaciones de seguridad]
Tú: Apruebo el plan. Salir del modo plan.
[escribe 2,400 líneas en 11 archivos, ~8 minutos]
Tú: /review
[AUTO-FIX] 2 issues. [PREGUNTAR] Race condition, apruebas fix.
Tú: /qa https://staging.miapp.com
[abre navegador real, navega flujos, encuentra y arregla un bug]
Tú: /ship
Tests: 42 → 51 (+9 nuevos). PR: github.com/tu/app/pull/42El README lo resume así: "Dijiste 'app de briefing diario.' El agente dijo 'estás construyendo un chief of staff personal con IA' porque escuchó tu dolor, no tu feature request. Ocho comandos, de inicio a fin. Eso no es un copilot. Es un equipo."
sprints en paralelo
gstack funciona bien con un sprint. Se pone interesante con diez corriendo al mismo tiempo.
Conductor (conductor.build) corre múltiples sesiones de Claude Code en paralelo, cada una en su propio workspace aislado. Una sesión en /office-hours, otra en /review, una tercera implementando un feature, una cuarta corriendo /qa. Todo al mismo tiempo. La estructura de sprint es lo que hace que el paralelismo funcione: sin proceso, diez agentes son diez fuentes de caos. Con proceso, cada agente sabe exactamente qué hacer y cuándo parar.
para no-programadores: por qué esto te importa
Si no programas, probablemente estás pensando "esto es para devs, no me sirve." Y parcialmente tienes razón: la mayoría de gstack es infraestructura de desarrollo. Pero hay 4 skills que son directamente útiles si eres fundador, PM, o marketer.
/office-hours: validar ideas antes de gastar plata
No necesitas saber programar para correr /office-hours. Lo que hace es aplicar el framework de Y Combinator para evaluar ideas: cuál es el dolor real, por qué lo que existe no funciona, cuál es la cuña más estrecha para empezar, qué suposiciones estás haciendo sin darte cuenta.
Si alguna vez has pagado un consultor para que te diga "eso no va a funcionar, pero esto sí", /office-hours hace algo parecido. No va a reemplazar a un advisor humano con experiencia en tu industria, pero sí te fuerza a pensar con más rigor antes de invertir tiempo y dinero.
Aplicantes a YC S26 ya lo están usando para preparar sus aplicaciones. Eso dice algo.
/plan-ceo-review: pensar en producto, no en features
/plan-ceo-review es útil para cualquier persona que tome decisiones de producto. No revisa código, revisa la lógica del producto: estás resolviendo el problema correcto? El scope es el adecuado? Hay algo más grande escondido dentro de lo que estás pidiendo?
/browse: QA visual sin tocar código
Si tu equipo de desarrollo te pide que "hagas QA" de algo, /browse te deja hacerlo de manera sistemática. Navega a la URL, toma screenshots anotados con cada elemento interactivo identificado, genera un reporte de qué funciona y qué no. No necesitas abrir herramientas de desarrollador ni entender JavaScript.
/retro: tracking de productividad
Incluso Garry dice que si no usaras nada más de gstack, /retro vale la pena. Genera una retrospectiva semanal basada en datos reales: commits, PRs, qué se envió, qué quedó pendiente. /retro global agrega datos de múltiples proyectos y herramientas.
el workshop para no-programadores
Marily Nika creó un workshop específico para personas que "nunca realmente usan bien" herramientas de IA para código. Está enfocado en el uso práctico de gstack para personas de producto y negocio. Si te interesa el tema pero no sabes por dónde empezar, es un buen punto de entrada.
gstack vs. el resto
vs. Claude Code sin gstack
Claude Code sin gstack es un asistente de programación genérico muy capaz. Puede escribir código, responder preguntas, debuggear problemas. Pero no tiene estructura. Cada sesión empieza de cero, no hay proceso, no hay revisión sistemática.
gstack agrega exactamente eso: estructura y proceso. El tradeoff es complejidad. Con Claude Code vanilla, le dices "haz esto" y lo hace. Con gstack, hay 28 modos, un flujo recomendado, principios de operación. Para proyectos simples, es overhead innecesario. Para proyectos serios (una startup, una app en producción, algo con usuarios reales), la estructura previene la clase de errores que aparecen a las 3 AM cuando tu landing está caída.
vs. Cursor
Cursor es un IDE completo con IA integrada. Es un producto pulido, con interfaz gráfica, autocomplete en tiempo real, y un modelo de negocio claro (suscripción mensual). gstack es un conjunto de archivos Markdown que corren dentro de una terminal.
La diferencia filosófica: Cursor busca hacer la experiencia de programar más fluida segundo a segundo. gstack busca crear un proceso de desarrollo end-to-end que produce software de mayor calidad. No son mutuamente excluyentes: puedes usar Cursor como tu editor y gstack para el proceso de revisión, QA y deploy.
Un dato relevante: gstack funciona con Cursor. No es exclusivo de Claude Code. También funciona con Codex CLI y Gemini CLI. La compatibilidad multi-agente es un punto a favor.
vs. GitHub Copilot
Copilot es autocomplete con esteroides. Completa la línea que estás escribiendo, sugiere funciones, genera boilerplate. Es excelente para productividad línea a línea pero no tiene opinión sobre tu arquitectura, no revisa tu código, no hace QA, no te cuestiona el producto.
gstack opera a un nivel completamente diferente. No te ayuda a escribir una línea de código más rápido, te ayuda a decidir si esa línea debería existir.
cómo instalarlo y empezar
requisitos previos
- Claude Code instalado y funcionando (necesitas una cuenta de Anthropic)
- Git (probablemente ya lo tienes)
- Bun v1.0+ (runtime de JavaScript rápido,
curl -fsSL https://bun.sh/install | bash) - Node.js (solo en Windows)
instalación (30 segundos)
Abre Claude Code y pega esto:
Instalar gstack: ejecuta git clone https://github.com/garrytan/gstack.git
~/.claude/skills/gstack && cd ~/.claude/skills/gstack && ./setupClaude hace el resto. El setup compila el navegador headless, registra los skills, y queda listo.
primer uso recomendado
El README de gstack sugiere este orden:
- Corre
/office-hoursy describe lo que estás construyendo - Corre
/plan-ceo-reviewsobre cualquier idea de feature - Corre
/reviewen cualquier branch con cambios - Corre
/qaen tu URL de staging - Para ahí. Vas a saber si esto es para ti.
para equipos
Si quieres que tus compañeros de equipo tengan gstack al clonar el repo:
cp -Rf ~/.claude/skills/gstack .claude/skills/gstack &&
rm -rf .claude/skills/gstack/.git &&
cd .claude/skills/gstack && ./setupEsto copia gstack dentro de tu repositorio. Se commitea como archivos normales (no es un submódulo), así que git clone simplemente funciona para cualquier persona del equipo.
para Codex, Gemini CLI o Cursor
git clone https://github.com/garrytan/gstack.git ~/.codex/skills/gstack
cd ~/.codex/skills/gstack && ./setup --host codexO deja que el setup auto-detecte qué agentes tienes:
git clone https://github.com/garrytan/gstack.git ~/gstack
cd ~/gstack && ./setup --host autotelemetría y privacidad
gstack incluye telemetría opt-in. Por defecto está apagada. En el primer uso te pregunta si quieres compartir datos anónimos de uso (qué skills usas, cuánto tardan, si fallan). Nunca se envía código, rutas de archivos, nombres de repo, nombres de branches, prompts, ni contenido generado.
Puedes desactivarla en cualquier momento con gstack-config set telemetry off.
el veredicto honesto
gstack es tres cosas al mismo tiempo, y vale la pena separar la evaluación.
Como colección de prompts: es una de las mejores que existen para desarrollo de software. Los skills están bien diseñados, cubren el ciclo completo de desarrollo, y la filosofía detrás (completitud, búsqueda antes de construir, escalar problemas en lugar de producir trabajo malo) es sólida. No es magia, son instrucciones, pero son instrucciones escritas por alguien que ha construido productos durante 20 años y lleva meses iterando sobre ellas.
Como herramienta técnica: el navegador headless es genuinamente útil y bien construido. ~100ms por comando, persistencia de sesión, integración con cookies de navegadores reales. Si haces QA o testing, esto tiene valor concreto e inmediato.
Como fenómeno cultural: gstack es tanto un producto como una declaración. Garry está diciendo "así es como construyo software ahora, y tú también deberías." Las 37,000 stars son en parte producto, en parte marca personal, en parte la fascinación (o el miedo) de la industria por la velocidad que permite la IA. Las métricas infladas, la falta de sueño, el "god mode", todo eso es parte del show.
La verdad incómoda: gstack probablemente funciona mejor de lo que sus críticos dicen y menos de lo que Garry afirma. Los prompts bien diseñados sí producen mejores outputs de LLMs. Un proceso de desarrollo estructurado sí produce mejor software. Un navegador headless rápido sí mejora el QA. Pero 28 modos especializados pueden ser un placebo que te hace sentir que estás siendo más riguroso sin serlo realmente.
Mi recomendación: instálalo, prueba /office-hours y /review en un proyecto real, y evalúa con tus propios datos. Son 30 segundos de instalación, gratis, open source. Si te sirve, úsalo. Si no, lo borras y listo.
Lo que sí es innegable: estamos en un momento donde una persona con las herramientas correctas puede producir lo que antes requería un equipo. Que la herramienta sea gstack, otra cosa, o algo que todavía no existe, ese tren ya salió de la estación.
Artículo actualizado a marzo de 2026. gstack v0.11.1.0, ~37,300 GitHub stars.
© 2026 Andres Ospina
