Garry Tan lanza gstack, un sistema de flujo de trabajo para Claude Code con QA, revisión y release

Garry Tan ha publicado en código abierto gstack, un conjunto de skills para Claude Code que convierte el trabajo con un agente de IA para programar en un proceso más estricto y predecible. La idea es sencilla: no mezclar planificación, revisión de ingeniería, QA y release en un prompt interminable, sino repartirlos en modos distintos con roles claros.

Qué es gstack

Gstack no es un modelo nuevo ni otro framework de agentes, sino una capa de flujo de trabajo sobre Claude Code. El proyecto empaqueta las etapas típicas de la entrega de software en comandos separados y define para cada uno un modo de pensar propio. En lugar de improvisar con un «haz la funcionalidad y revísate tú mismo», el desarrollador recibe una secuencia de pasos: primero la formulación de producto, después el plan de ingeniería, luego la revisión, la verificación en navegador y solo al final la preparación del release. Es decir, gstack intenta aportar al desarrollo con IA disciplina de proceso, no magia.

«Eight opinionated workflow skills for

Claude Code» es como se describe el propio proyecto.

La idea clave no es dar más libertad al agente, sino lo contrario: acotar el contexto de cada tarea. Según la descripción del proyecto, esto debería reducir las decisiones flojas que aparecen cuando la misma IA inventa la funcionalidad, escribe el código, prueba la interfaz y decide si se puede desplegar a producción. Gstack separa esos roles y obliga a recorrerlos en secuencia, como si en la tarea trabajaran personas distintas con distintas áreas de responsabilidad.

Ocho modos de trabajo

En el momento del lanzamiento, el repositorio tenía ocho comandos principales, y cada uno cubría una parte del proceso, no «todo a la vez». Esa es la apuesta central de gstack: la calidad mejora no con una inteligencia nueva, sino con disciplina en torno a un agente de programación ya existente. Un comando revisa la idea de producto, otro la arquitectura y las pruebas, otro los riesgos en el código, y uno más se encarga de la última etapa antes del merge y el release.

• `/plan-ceo-review` — revisión de producto de la idea y las prioridades
• `/plan-eng-review` — arquitectura, data flow, edge cases y pruebas
• `/review` — búsqueda de riesgos en producción y problemas en el código
• `/ship` — sincronización de la rama, ejecución de pruebas y preparación del PR
• `/browse`, `/qa`, `/setup-browser-cookies`, `/retro` — navegador, QA, importación de cookies y retrospectiva

Este reparto de roles resulta especialmente lógico ante un problema típico de la programación con IA: el agente escribe rápido el happy path, pero a menudo se salta casos límite, regresiones y fallos de UX. En gstack estas comprobaciones se sacan a modos independientes para que no compitan con la tarea de «escribir código lo más rápido posible». Esto no garantiza la ausencia de errores, pero acerca el proceso a la práctica de ingeniería habitual, donde diseño, implementación, verificación y publicación no se amontonan en un solo paso.

Navegador, QA y stack

Lo más interesante de gstack no son las skills en markdown, sino el runtime de navegador persistente. En lugar de lanzar un navegador nuevo para cada acción, el sistema levanta un daemon de Chromium headless de larga duración y se comunica con él por HTTP en localhost. Esto sirve tanto para la velocidad como para conservar el estado entre pasos. Según los datos de la descripción del proyecto, el arranque en frío de la herramienta de navegador tarda unos 3–5 segundos, y las llamadas posteriores se resuelven en aproximadamente 100–200 milisegundos. Así se conservan entre comandos las cookies, las pestañas, el localStorage y el estado de la sesión.

También importa cómo se integra este navegador en el flujo de QA. El comando `/browse` permite al agente entrar en la aplicación, recorrer la interfaz, hacer capturas de pantalla y ver dónde falla algo. `/qa` va más allá: analiza el diff de la rama, determina las rutas afectadas y comprueba justo las páginas y los escenarios que podrían haberse visto perjudicados por los cambios. En el ejemplo del repositorio, este modo analizó ocho archivos modificados, encontró tres rutas afectadas y las ejecutó contra una instancia local de la aplicación, es decir, vinculó los cambios de código con el comportamiento real de la interfaz.

En lo técnico, gstack también es pragmático. Para funcionar necesita Claude Code, Git y Bun 1.0+, y en el momento de la publicación el repositorio usaba Playwright y el paquete `diff`, con el comando `/browse` compilado como un binario ejecutable independiente. El conjunto puede instalarse en `~/.claude/skills/gstack` o colocarse en un `.claude/skills/gstack` local dentro del proyecto, para que todo el equipo use el mismo proceso. Los autores explican la elección de Bun por razones sencillas: binarios compilados, acceso nativo a SQLite, ejecución de TypeScript sin andamiaje adicional y servidor HTTP integrado mediante `Bun.serve()`.

Qué significa

Gstack resulta interesante no como «otro conjunto de prompts», sino como un intento de convertir la programación con IA en una cadena repetible con comprobaciones en cada etapa. Si este enfoque cuaja, el mercado avanzará no solo hacia modelos más potentes, sino también hacia capas operativas más estrictas por encima de ellos, con modos separados para planificación, revisión, QA y release. El cambio principal es que la confianza en la IA se intenta construir no sobre las promesas del modelo, sino sobre etapas de verificación.