⚡ En 30 segundos
gstack (de Garry Tan, CEO de Y Combinator) es un conjunto de skills para Claude Code —y otros 9 agentes de coding— que convierten al modelo en un equipo de ingeniería virtual: un CEO que repiensa el producto, un eng manager que cierra la arquitectura, un diseñador que caza "AI slop", un reviewer que encuentra bugs de producción, un QA lead que abre un navegador real y un release engineer que abre el PR.
Por qué importa: no es un copilot ni una colección de prompts sueltos. Es un proceso de sprint encadenado (Think → Plan → Build → Review → Test → Ship → Reflect) donde cada skill escribe un artefacto que la siguiente lee. Todo es Markdown + slash commands, MIT, gratis. La única pieza pesada de verdad es un daemon de navegador Chromium persistente escrito en Bun.
Para quién: fundadores técnicos que aún quieren shippear, usuarios primerizos de Claude Code que prefieren roles estructurados a un prompt en blanco, y tech leads que quieren review/QA/release automatizados en cada PR. Para Raúl: es exactamente un "harness" de generación/ejecución solo-founder + IA — el mismo patrón que su Factory, pero centrado en ejecutar producto, no en filtrar ideas.
bin/ (telemetría, memoria, redact, deploy…)🧠 El problema que resuelve
Un prompt en blanco frente a Claude Code es potente pero sin estructura: el agente hace lo que le pides literalmente, no lo que necesitas. Pides una "app de briefing diario" y te construye exactamente eso, en vez de cuestionarte que lo que describiste es en realidad un "chief of staff AI". Falta juicio de producto, rigor de review y disciplina de proceso — justo lo que aporta un equipo senior.
La tesis de Tan (citando a Karpathy) es que la barrera de ingeniería desapareció: lo que queda es taste, criterio y la voluntad de "hacer la cosa completa". Su archivo ETHOS.md lo formaliza con una tabla de ratios de compresión humano-vs-IA (boilerplate ~100×, tests ~50×, features ~30×) y un principio provocador: "Boil the Ocean" — el viejo "no abarques demasiado" era válido cuando el tiempo de ingeniería era el cuello de botella; ahora el último 10% de completitud cuesta segundos, así que hazlo siempre.
gstack resuelve esto inyectando roles opinados que reintroducen la fricción buena (preguntas forzadas, review adversarial, QA en navegador real) sin reintroducir la lentitud del equipo humano. Todo el repo gira en torno a una idea: encadenar especialistas en un sprint reproducible donde nada se cae entre etapas porque cada skill conoce el artefacto que dejó la anterior.
🏗 Arquitectura
Hay dos capas muy distintas. La capa de proceso es trivial técnicamente (puro Markdown: cada skill es un SKILL.md generado desde un .tmpl). La capa difícil es el navegador: un daemon Chromium persistente para que el agente clique webs reales con latencia sub-segundo.
Cómo leerlo: el agente nunca habla con Chromium directamente. Emite un comando ($B …), el CLI (binario compilado) lee un state file para encontrar el server y hace un POST autenticado con Bearer token a localhost. El server (Bun.serve) traduce ese comando a CDP (Chrome DevTools Protocol) y mantiene tabs, cookies y sesiones vivas. La clave de diseño: arrancar un navegador por comando costaría 40s+ en una sesión de QA de 20 clics y perderías todo el estado entre comandos. El daemon resuelve ambas cosas.
Eligieron Bun por tres razones concretas: bun build --compile da un binario único sin node_modules (instala en ~/.claude/skills/ sin que gestiones un proyecto Node), SQLite nativo para desencriptar cookies de Chromium sin addons nativos, y Bun.serve() integrado sin Express.
El sprint es la idea central del repo: gstack es un proceso, no una caja de herramientas. El encadenamiento por artefactos (el design doc de /office-hours alimenta a /plan-ceo-review; el test plan de /plan-eng-review lo recoge /qa) es lo que diferencia esto de tener 23 prompts sueltos.
🔑 Conceptos / técnicas clave
.tmpl (bun run gen:skill-docs) y se reescriben por host (Claude, Codex…). Editas la plantilla, no el output.ETHOS.md ("Boil the Ocean", "Search Before Building", tres capas de conocimiento) se inyecta en el preámbulo de cada skill. Es el "carácter" compartido que hace que todos los roles empujen hacia completitud y rigor./qa, /canary, /scrape: el agente clica webs de verdad con login real importando cookies de tu navegador.agents/openai.yaml, docs/ADDING_A_HOST.md). gstack se posiciona como capa neutral por encima del agente./context-save, /learn, sync cross-máquina vía gbrain/Supabase, decision-log, telemetry-log. La factoría recuerda decisiones entre sesiones (paralelo directo a tu MEMORY.md).Los especialistas más importantes, agrupados por fase:
| Comando | Rol | Qué hace |
|---|---|---|
/office-hours | YC Office Hours | Punto de partida. Seis preguntas forzadas que re-enmarcan el producto antes de escribir código. Cuestiona premisas, genera alternativas de implementación, escribe el design doc. |
/plan-ceo-review | CEO / Founder | Busca el "producto de 10 estrellas" escondido en la petición. 4 modos: Expansión, Expansión selectiva, Mantener scope, Reducción. |
/plan-eng-review | Eng Manager | Cierra arquitectura, data flow, diagramas ASCII, edge cases y matriz de tests. Saca a la luz suposiciones ocultas. |
/autoplan | — | Un comando corre CEO → design → eng → DX review en cadena. |
/review | Staff Engineer | Encuentra bugs que pasan CI pero explotan en producción. Auto-arregla los obvios, marca gaps de completitud. |
/cso | Security Officer | Auditoría OWASP Top 10 + STRIDE. |
/investigate | Debugger | Root-cause sistemático. Ley de hierro: sin investigación no hay fix. Para tras 3 fixes fallidos. |
/qa / /qa-only | QA Lead | Abre navegador real, clica flujos, encuentra bugs, los arregla con commits atómicos y genera tests de regresión. -only = solo reporta. |
/design-shotgun + /design-html | Diseñador | Genera 4-6 variantes de mockup, board de comparación en el navegador, "taste memory" que aprende lo que te gusta, y convierte el elegido en HTML de producción. |
/ship / /land-and-deploy / /canary | Release Engineer | Tests + review + push + abre PR; mergea, espera CI/deploy y verifica salud; monitoriza post-deploy. |
/careful / /freeze / /guard | Safety | Avisa antes de comandos destructivos (rm -rf, DROP TABLE, force-push) y bloquea edición fuera de un directorio. |
🗂 Mapa de ficheros importantes
| Fichero / carpeta | Para qué sirve |
|---|---|
README.md | Manifiesto + quick start + tabla completa de skills. La "venta" del proyecto y la demo de sesión end-to-end. |
ETHOS.md | Los principios ("Boil the Ocean", tabla de compresión IA) que se inyectan en cada skill. El "alma" del repo. |
ARCHITECTURE.md | El "por qué" técnico. Daemon model, elección de Bun, state file, y un modelo de seguridad muy detallado (dual-listener tunnel, sanitización de surrogates, defensa anti prompt-injection). |
AGENTS.md | Catálogo de todas las skills por categoría + build commands + convenciones (SKILL.md se genera de .tmpl). |
*/SKILL.md + SKILL.md.tmpl | Cada skill vive en su carpeta (autoplan/, benchmark/, browse/…). El .tmpl es la fuente; el .md es output generado. |
browse/src/*.ts | El corazón técnico: server.ts, cdp-bridge.ts, browser-manager.ts, content-security.ts (defensa prompt-injection), cli.ts. ~22 ficheros TypeScript. |
bin/ (72 scripts) | Toda la fontanería: gstack-paths (resuelve rutas de estado), gstack-redact (no filtrar secretos), gstack-telemetry-log, gstack-brain-* (memoria), gstack-team-init, gstack-decision-log. |
agents/openai.yaml | Ejemplo de config de host: así se añade soporte para otro agente de coding sin tocar código. |
docs/ON_THE_LOC_CONTROVERSY.md | Defensa de Tan ante las críticas a sus métricas de LOC con IA: metodología, caveats y script de reproducción. |
setup / ./setup --team / --host | Instalador. Auto-detecta qué agentes tienes y dónde colocar las skills. |
🎯 Qué puedes aplicar tú
- Roba el patrón "artefacto encadenado". Tu Factory ya tiene etapas (E1, E2…). gstack demuestra el valor de que cada etapa escriba un fichero que la siguiente lee obligatoriamente — design doc → test plan → bug report. Aplícalo a tus
DECISIONS.md/briefspara que ninguna señal se caiga entre gates. - Adopta
/office-hourscomo gate de re-encuadre. Las "seis preguntas forzadas que cuestionan tu framing" son justo lo que tu principio "Make something people want" pide antes de construir. Es un complemento directo a tuinterest-interview. - Mira
browse/si necesitas validar MVPs con web real. El daemon Chromium persistente con import de cookies es exactamente lo que necesitarías parawebapp-testingautenticado a ~100ms/comando, en vez de arrancar Playwright por comando. - Copia el "team mode auto-update". Chequeo de versión throttled 1/hora, silencioso, fail-safe de red: patrón limpio para distribuir tu propio harness sin vendar ficheros ni sufrir drift.
- Estudia el modelo multi-host. "Un fichero YAML, cero código" para soportar 10 agentes es una lección de diseño de plugin: separa la lógica del rol del agente que la ejecuta.
- Aplica
/csoy/carefula tu flujo. Tienes la regla "no commits con secretos" en CLAUDE.md; gstack la operacionaliza congstack-redact-prepushy un security officer OWASP/STRIDE. Inspírate para hooks de pre-push.
⚠️ Limitaciones / cuándo NO usarlo
- Es ejecución de producto, no generación/filtrado de ideas. gstack asume que ya sabes qué construir y te ayuda a construirlo bien. Tu Factory hace lo contrario (descartar ideas con disciplina). Son complementarios, no sustitutos: gstack entraría después de que una idea pase E2.
- Dependencias y plataforma. Requiere Bun, Git y Claude Code (o uno de los 10 agentes). El soporte Windows es un subconjunto curado;
setupaún necesita Git Bash/MSYS, no PowerShell nativo. - El navegador es superficie de ataque real. El propio
ARCHITECTURE.mdadmite un non-goal pendiente (#1136): en Windows con App-Bound Encryption v20, el path de import de cookies abre Chrome con--remote-debugging-portTCP, exfiltrable por un proceso local del mismo usuario. Si vas a usarpair-agent/tunnel, lee la sección de seguridad entera primero. - Sesgo cultural fuerte. El ethos "Boil the Ocean / completitud es barata" empuja a la IA a expandir scope. Para un portfolio bootstrap de MVPs ≤€3k a 2 semanas como el tuyo, ese sesgo puede ir en contra de tu "Shipping > perfection" y "One hypothesis per MVP". Úsalo con criterio, no a ciegas.
- Métricas de marketing discutibles. Los "810×" y "11.417 líneas/día" son contestados (de ahí el doc de la "LOC controversy"). Toma las cifras como narrativa de venta, no como benchmark objetivo del valor del tooling.