Harry Tan lanzó gstack — un sistema de workflow para Claude Code con QA, revisión y release

Harry Tan lanzó gstack como código abierto — un conjunto de skills para Claude Code que convierte el trabajo con un agente de IA para código en un proceso más riguroso y predecible. La idea es simple: en lugar de mezclar planificación, revisión de ingeniería, QA y lanzamiento en un único prompt infinito, separar todo en modos distintos con roles claros.

Qué es gstack

En esencia, gstack no es un nuevo modelo ni otro framework de agentes, sino una capa de workflow sobre Claude Code. El proyecto empaqueta etapas típicas de entrega de software en comandos separados y asigna a cada uno su propio modo de pensamiento. En lugar de improvisación en el espíritu de "construye una feature y revísala tú mismo", el desarrollador recibe una secuencia de pasos: primero una formulación de producto, luego un plan de ingeniería, luego revisión, pruebas en navegador y solo después la preparación del lanzamiento. En otras palabras, gstack intenta añadir a desarrollo con IA no magia, sino disciplina de proceso.

"Eight opinionated workflow skills for Claude Code" — así es como el proyecto se describe.

La idea clave aquí no es dar al agente más libertad, sino todo lo contrario — restringir el contexto de cada tarea. Según la descripción del proyecto, esto debe reducir el número de soluciones débiles que aparecen cuando una única IA simultáneamente inventa una feature, escribe código, prueba la interfaz y decide si esto puede lanzarse a producción. gstack separa estos roles y obliga a ejecutarlos secuencialmente, como si personas diferentes con áreas diferentes de responsabilidad estuvieran trabajando en la tarea.

Ocho modos de operación

En el momento del lanzamiento, el repositorio contenía ocho comandos principales, cada uno responsable de una parte separada del proceso, en lugar de "todo de una vez". Esta es la apuesta principal de gstack: la calidad mejora no a través de nueva inteligencia, sino a través de disciplina en torno al agente de código ya existente. Un comando separado verifica la idea del producto, otro verifica arquitectura y pruebas, otro verifica riesgos en el código, y otro más es responsable de la etapa final antes del merge y lanzamiento.

• `/plan-ceo-review` — revisión de producto de idea y prioridades
• `/plan-eng-review` — arquitectura, flujo de datos, casos extremos y pruebas
• `/review` — búsqueda de riesgos en producción y problemas de código
• `/ship` — sincronización de rama, ejecución de pruebas y preparación de PR
• `/browse`, `/qa`, `/setup-browser-cookies`, `/retro` — navegador, QA, importación de cookies y retrospectiva

Esta división en roles parece especialmente lógica ante un problema típico de coding con IA: el agente escribe rápidamente el caso feliz, pero frecuentemente pierde casos extremos, regresiones y fallos de UX. En gstack, estas verificaciones se mueven a modos separados 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 mismo a la práctica de ingeniería común, donde diseño, implementación, pruebas y lanzamiento no se tiran en un único paso.

Navegador, QA y stack

La parte más interesante de gstack no son los skills en markdown, sino el runtime persistente del navegador. En lugar de lanzar un navegador nuevo para cada acción, el sistema inicia un daemon Chromium headless de larga vida y se comunica con él vía HTTP localhost. Esto es necesario tanto para velocidad como para mantener el estado entre pasos.

Según la descripción del proyecto, un cold start de la herramienta de navegador toma alrededor de 3–5 segundos, y las llamadas subsiguientes después del lanzamiento se encajan en aproximadamente 100–200 milisegundos. Debido a esto, cookies, pestañas, localStorage y estado de login se preservan entre comandos. Es especialmente importante cómo este navegador se integra en el flujo de QA.

El comando `/browse` le da al agente la capacidad de entrar en la aplicación, hacer clic por la interfaz, tomar capturas de pantalla y ver dónde falla todo. Y `/qa` va más allá: analiza el diff de la rama, identifica rutas afectadas y prueba precisamente esas páginas y escenarios que podrían haber sido impactados por los cambios. En un ejemplo del repositorio, este modo analizó ocho archivos modificados, encontró tres rutas afectadas y las probó contra una instancia local de la aplicación — vinculando cambios de código al comportamiento real de la interfaz.

Desde una perspectiva técnica, gstack también se construyó pragmáticamente. Para usarlo, necesitas 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 en un binario ejecutable separado. El conjunto puede instalarse en `~/.claude/skills/gstack` o colocarse en el `~/.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 simples: binarios compilables, acceso nativo a SQLite, ejecución de TypeScript sin boilerplate extra, y servidor HTTP integrado a través de `Bun.serve()`.

Qué significa esto

gstack es interesante no como "otro conjunto de prompts", sino como un intento de convertir coding con IA en un pipeline repetible con verificaciones en cada etapa. Si este enfoque prospera, el mercado se moverá no solo hacia modelos más fuertes, sino también hacia capas operacionales más rigurosas sobre ellos — con modos separados para planificación, revisión, QA y lanzamiento. El cambio principal aquí es que la confianza en IA se está construyendo no a través de promesas de modelo, sino a través de etapas de verificación.