gstack: Pila de Ingeniería de Software con IA

Los agentes de código basados en IA ya pueden escribir funciones, modificar repositorios, ejecutar pruebas y abrir peticiones de extracción (pull requests). El problema más difícil es lograr que un agente siga un proceso de ingeniería repetible antes, durante y después de que se escriba el código.

gstack, un proyecto de Garry Tan construido originalmente en torno a Claude Code, toma una ruta diferente: en lugar de reemplazar tu agente de código por otra plataforma, envuelve el agente que ya usas con habilidades especializadas, herramientas de navegador, revisiones, controles de seguridad y procesos de lanzamiento. El proyecto describe el resultado como un equipo de ingeniería virtual: veintitrés especialistas y ocho herramientas potentes, todos comandos con barra diagonal, todo en Markdown, con licencia MIT.

Los objetivos de la comparación dependen de qué parte de gstack necesites: colecciones de habilidades como Superpowers, sistemas de especificaciones como OpenSpec y GitHub Spec Kit, metodologías como BMAD, plataformas de orquestación como Ruflo, o tu propio conjunto de habilidades de agente mantenido. Varios de estos se combinan con gstack en lugar de reemplazarlo, y el ecosistema más amplio al que todos pertenecen está mapeado en el centro de Herramientas de Desarrollo de IA de este sitio.

¿Qué es gstack?

gstack es una colección de código abierto de flujos de trabajo de ingeniería de IA. En la formulación de gstack, el desarrollo de software consiste en varios tipos diferentes de razonamiento, y pedir a un único prompt de código genérico que realice todos ellos es una mala abstracción; por lo tanto, el proyecto expone habilidades especializadas en su lugar:

• exploración de producto
• revisión de producto y CEO
• revisión de arquitectura
• revisión de experiencia del desarrollador
• revisión de diseño
• revisión de implementación
• QA basado en navegador
• investigación y depuración
• análisis de seguridad
• documentación
• benchmarking
• preparación del lanzamiento
• despliegue
• retrospectivas

El proyecto presenta estos roles como un equipo de ingeniería virtual: un CEO que repiensa el producto, un gerente de ingeniería que cierra la arquitectura, un diseñador que detecta la “basura de IA” (AI slop), un revisor que encuentra errores de producción, un líder de QA que abre un navegador real, un oficial de seguridad que ejecuta auditorías OWASP y STRIDE, e un ingeniero de lanzamientos que envía la PR. La cadena de herramientas alrededor de las definiciones de habilidades es TypeScript y Bun: un script de configuración, documentación de habilidades generada, hooks de sesión, estado bajo ~/.gstack/, un navegador integrado y un conjunto de CLIs independientes.

gstack no es un modelo fundamental ni un reemplazo para Claude Code; es una capa de proceso que se ejecuta sobre un arnés de agente:

Dos propiedades estructurales deciden dónde encaja gstack. Primero, el proyecto lo describe como un proceso en lugar de una colección de herramientas: las habilidades se ejecutan en el orden en que se ejecuta un sprint: pensar, planificar, construir, revisar, probar, lanzar, reflexionar; y cada habilidad entrega sus artefactos a la siguiente, de modo que /office-hours escribe un documento de diseño que /plan-ceo-review lee, y /plan-eng-review escribe un plan de pruebas que /qa recoge. Segundo, gstack no es exclusivo de Claude Code: ./setup autodetecta los agentes instalados en la máquina, y ./setup --host <nombre> apunta a Codex CLI, OpenCode, Cursor, Factory Droid, Kiro, Slate, OpenClaw y Hermes, mientras que un resumen de solo instrucciones de 2 KB en el repositorio cubre a los agentes que leen reglas y no necesitan ninguna instalación.

Por qué existe gstack

Una sesión en blanco de Claude Code es extremadamente flexible, y esa flexibilidad es también una de sus debilidades. Considere una solicitud de función como:

Add organization-level API tokens to the application.

Un agente capaz podría inspeccionar inmediatamente el repositorio y comenzar a modificar el código de autenticación, mientras que un ingeniero senior primero preguntaría quién es el propietario de los tokens, si los usuarios pueden pertenecer a múltiples organizaciones, cómo se revocan los tokens, si los permisos se heredan, qué pasa con la autenticación existente, si los tokens deberían expirar, cómo se muestran los secretos y qué eventos de auditoría se requieren. El agente podría descubrir algunas de estas preguntas eventualmente, pero no hay garantía de que las descubre antes de la implementación. gstack mueve esa disciplina a flujos de trabajo reutilizables: en lugar de idea -> coding agent -> code, el cambio pasa por la revisión de producto, planificación técnica, revisión de arquitectura, implementación, revisión de código, QA del navegador y lanzamiento como etapas nombradas, cada una con su propio comando (la secuencia completa está en Un flujo de trabajo práctico de gstack a continuación).

Esto no hace que la IA sea correcta; cambia la distribución de probabilidad de sus errores. El agente se impulsa a desafiar supuestos antes, inspeccionar evidencia, revisar su propio trabajo desde varias perspectivas y verificar la aplicación en lugar de detenerse cuando el código compila.

Cómo gstack convierte habilidades de Markdown en proceso

La mayoría de las capacidades de gstack se originan en definiciones de habilidades de Markdown. Una habilidad de agente puede describir:

• cuándo debe ejecutarse
• qué contexto debe inspeccionar
• qué preguntas debe hacer
• qué herramientas puede usar
• qué comandos debe ejecutar
• qué evidencia debe recopilar
• qué comprobaciones deben superarse
• cómo debe estructurarse el resultado

Tal habilidad actúa en algún lugar entre la documentación, un prompt reutilizable, un procedimiento operativo estándar y la configuración de flujo de trabajo ejecutable. Los mecanismos subyacentes se cubren en Habilidades de Claude y SKILL.md para Desarrolladores; gstack agrega infraestructura sobre ese primitivo: definiciones de habilidades generadas, hooks de inicio y finalización, gestión de estado bajo ~/.gstack/, automatización de navegador, mecanismos de seguridad, inspección de repositorio, telemetría opcional, memoria entre sesiones gestionada por /learn, y conocimiento persistente opcional a través del proyecto separado GBrain, que /setup-gbrain puede establecer como una base de datos PGLite local, un proyecto de Supabase o un extremo MCP remoto.

Las habilidades de gstack más importantes

La colección exacta cambia rápidamente, pero varios flujos de trabajo ilustran cómo se pretende usar el sistema.

office-hours

/office-hours pertenece al principio de un proyecto o función. Ejecuta seis preguntas obligatorias sobre el problema antes de que se escriba código, y en el ejemplo resuelto del README redefine una solicitud de una “app de informes diarios” como una IA de jefatura de personal personal, y luego escribe el documento de diseño que cada habilidad descendente lee. Para una entrada vaga como “necesitamos mejor búsqueda de proyectos”, la salida es un requisito, no código.

plan-ceo-review

/plan-ceo-review examina los supuestos a nivel de producto detrás de un plan. Funciona en cuatro modos de alcance: Expansión, Expansión Selectiva, Mantener Alcance, Reducción; y puede desafiar el alcance, identificar oportunidades perdidas, reducir el trabajo innecesario o sugerir enmarcar el problema de manera diferente. Se ejecuta antes de que los requisitos se fijen, una etapa que la mayoría de las herramientas de agentes de código no tienen.

plan-eng-review

/plan-eng-review cambia la perspectiva hacia la ingeniería: arquitectura, flujo de datos, diagramas, casos extremos, una matriz de pruebas, modos de falla y preocupaciones de seguridad. Se mantiene separado de la revisión de producto porque fusionar ambos en un solo prompt grande hace que el modelo mezcle decisiones de producto con decisiones de implementación.

plan-design-review y design-review

gstack trata el diseño visual y de interacción como una disciplina separada. /plan-design-review califica cada dimensión de diseño de 0 a 10, describe cómo se ve un 10 y edita el plan para cerrar la brecha, con la detección de “basura de IA” como una comprobación nombrada. El posterior /design-review ejecuta la misma auditoría contra la implementación real y corrige lo que encuentra con commits atómicos y capturas de pantalla antes y después. Para aplicaciones web, ambos se combinan con la automatización de navegador de gstack.

review

/review realiza una revisión de ingeniería contra los cambios del repositorio desde la perspectiva de un ingeniero de personal: corrige automáticamente los hallazgos obvios, marca el resto para aprobación y mantiene una lente consultiva de simplificación para el código sobreconstruido. El código escrito con éxito no es necesariamente código que deba fusionarse.

investigate

/investigate aplica una regla de depuración sistemática que el proyecto llama la Ley de Hierro: no hay correcciones sin investigación. Traza el flujo de datos, prueba hipótesis y se detiene después de tres intentos fallidos de corrección en lugar de seguir luchando. También activa automáticamente /freeze, que bloquea las ediciones al módulo bajo investigación.

qa y qa-only

/qa tiene al agente operar un navegador, interactuar con la aplicación, encontrar errores, corregirlos con commits atómicos, re-verificar y generar una prueba de regresión para cada corrección. /qa-only ejecuta el mismo método solo para el informe. Muchos agentes de código detienen la verificación en “las pruebas pasaron”; para una aplicación web, el navegador es donde los errores de integración, problemas de diseño, flujos incorrectos, fallas de autenticación y excepciones de JavaScript suelen hacerse visibles.

ship, land-and-deploy, y canary

La cadena de lanzamiento son tres habilidades, no una. /ship sincroniza main, ejecuta pruebas, audita la cobertura, empuja y abre la solicitud de extracción, iniciando un marco de pruebas si el proyecto no tiene ninguno. /land-and-deploy fusiona, espera la CI y el despliegue, y verifica la salud de producción. /canary luego ejecuta un bucle de monitoreo posterior al despliegue que observa errores de consola, regresiones de rendimiento y fallas de página.

autoplan, spec, learn, y retro

/autoplan ejecuta automáticamente la tubería de revisión de CEO, diseño, DX e ingeniería; la ingeniería siempre al final, para que la puerta de lanzamiento revise el plan final modificado; y solo muestra las decisiones de gusto para aprobación. /spec convierte la intención vaga en una especificación precisa y ejecutable en cinco fases (por qué, alcance, técnica con lectura de código obligatoria, borrador, archivo) con una puerta de calidad de revisión externa antes de archivar. /learn gestiona lo que gstack ha aprendido entre sesiones: patrones, trampas y preferencias; con revisión, búsqueda, poda y exportación. /retro produce una retro semanal consciente del equipo; /retro global la ejecuta en todos tus proyectos y herramientas de IA.

Automatización de navegador en gstack

En los sistemas macOS compatibles (macOS 15+), gstack maneja primero el navegador Aside: tu navegador real, con tus sesiones iniciadas de forma real, en pestañas que el agente abre para sí mismo y cierra cuando termina. Cuando Aside no está disponible, gstack recurre a su propio motor basado en Chromium, que ./setup construye y que ejecuta un demonio persistente en lugar de lanzar un navegador nuevo para cada comando:

El estado persistente del navegador permite que las cookies, las sesiones de autenticación y las pestañas sobrevivan entre operaciones, lo que hace práctico el QA basado en navegador. /open-gstack-browser expone el motor de respaldo con interfaz visible, con un agente de barra lateral que enruta acciones rápidas (clic, navegación, captura de pantalla) a Sonnet y la lectura o el análisis a Opus. Cuando el agente se enfrenta a un CAPTCHA, un muro de autenticación o un prompt de MFA, $B handoff abre un navegador visible en la misma página con cookies y pestañas intactas; tú lo resuelves, y $B resume continúa donde el agente se quedó. El agente sugiere una transferencia automáticamente después de tres fallas consecutivas. /pair-agent comparte el navegador con otros agentes: OpenClaw, Hermes, Codex, Cursor o cualquier cosa que pueda usar curl; con tokens acotados, aislamiento de pestañas, limitación de velocidad y atribución de actividad por pestaña.

El motor persistente también aumenta la superficie de seguridad, ya que un agente con acceso a sesiones autenticadas retiene un privilegio significativo. gstack incorpora una defensa contra inyección de prompts en capas para esto: filtros de contenido (marcado de datos, eliminación de elementos ocultos, limpieza de ARIA, lista de bloqueos de URL) en cada lectura de página, más un clasificador de ML local en un subproceso auxiliar que escanea el contenido derivado de la página antes de que el agente lo vea, con un combinador de veredictos que requiere el acuerdo del clasificador antes de bloquear. El contenido de la página se trata como entrada no confiable: el agente toma sintaxis de una página, nunca instrucciones. Comprobaciones antes y durante el uso de QA impulsado por navegador:

• Decide por adelantado en qué entornos autenticados puede operar el agente, y prefiere un perfil aislado para el trabajo de QA cuando se use el motor de respaldo.
• Conoce el interruptor de apagado de emergencia: GSTACK_SECURITY_OFF=1 deshabilita la capa de seguridad; no lo dejes establecido.
• El demonio persistente retiene cookies y sesiones entre ejecuciones, así que deténgalo cuando termine y confirme que no queda nada corriendo, por ejemplo ps aux | grep -i chrom.
• Lea los hooks y mecanismos de seguridad en el repositorio clonado antes de habilitarlos: son archivos planos, así que revíselos de la manera en que revisaría la configuración de CI.
• Después de actualizar el clon, vuelva a ejecutar ./setup para que los componentes generados se mantengan sincronizados con las definiciones de habilidades.

Barreras de seguridad y segundas opiniones

Tres herramientas potentes actúan como interruptores de seguridad a nivel de sesión. /careful avisa antes de comandos destructivos: rm -rf, DROP TABLE, fuerza-push, git reset --hard; y se activa diciendo “tenga cuidado”; las eliminaciones recursivas de la raíz o el directorio de inicio y los fuerza-push a la rama predeterminada se niegan rotundamente. /freeze restringe las ediciones de archivos a un directorio para que el agente no “corrige” código no relacionado mientras depura, y /guard activa ambos a la vez.

Las revisiones de segunda opinión cruzan arneses: en Claude Code, /codex envía el trabajo a OpenAI Codex CLI para una revisión, desafío o consulta independiente; en los otros arneses, /claude-code hace lo contrario. Cada informe identifica al proveedor que completó realmente la revisión.

Un flujo de trabajo práctico de gstack

No necesita cada habilidad de gstack para cada cambio. Un flujo de trabajo de función razonable:

1. /office-hours
2. /plan-ceo-review
3. Crear el plan de implementación
4. /plan-eng-review
5. Implementar
6. /review
7. /qa
8. /ship

Qué habilidades de revisión agregar depende de para quién es el software:

Para una corrección de errores trivial, ir directamente a investigar, implementar, revisar y probar suele ser suficiente. Una versión neutral de herramientas de la misma forma: especificación, diseño, tareas, implementar, validar; está en Flujo de Trabajo de Desarrollo Guiado por Especificaciones de Requisitos a Código. El README del proyecto describe ejecutar diez a quince de estos sprints en paralelo, cada uno en su propio espacio de trabajo aislado; la estructura del sprint es lo que el proyecto dice mantiene a los agentes paralelos de convertirse en fuentes de caos.

Instalando gstack

La instalación actual espera una configuración de Claude Code funcional, Git, Bun v1.0+, y, en Windows, Node.js; Bun tiene un error conocido con el transporte de tubería de Playwright en Windows, por lo que el servidor de navegación recurre a Node.js allí. Si aún no ha configurado Claude Code, comience con el resumen de Claude Code primero. En macOS, el navegador Aside (macOS 15+) es recomendado para las habilidades de navegador; sin él, se usa el demonio de Chromium integrado.

1. Verifique sus pre-requisitos: git --version y bun --version (la cadena de herramientas se basa en Bun).

2. Clone gstack en el directorio de habilidades de Claude:

   git clone --single-branch --depth 1 \
     https://github.com/garrytan/gstack.git \
     ~/.claude/skills/gstack
   

3. Ejecute el script de configuración desde el directorio clonado:

   cd ~/.claude/skills/gstack
   ./setup
   

   Setup instala y genera los componentes requeridos por las habilidades compatibles y construye el navegador integrado; un fallo en la instalación de Chromium es de mejor esfuerzo, setup registra la razón, termina registrando cada habilidad e imprime qué habilidades se ven afectadas.

4. Agregue una sección ## gstack al CLAUDE.md del proyecto. Las instrucciones de instalación del proyecto incluyen este paso, y es lo que hace que Claude Code enroute las habilidades: use /browse de gstack para toda la navegación web, nunca use las herramientas mcp__claude-in-chrome__*, y liste las habilidades disponibles.

5. Verifique la instalación: compruebe que los archivos generados están presentes en el directorio clonado, inicie una sesión de Claude Code y ejecute /office-hours en un proyecto de descarte para confirmar que la habilidad se reconoce.

Modo de equipo

Para repositorios, gstack ofrece una configuración orientada al equipo donde los desarrolladores comparten un flujo de trabajo en lugar de entornos configurados individualmente:

(cd ~/.claude/skills/gstack && ./setup --team) && \
  ~/.claude/skills/gstack/bin/gstack-team-init required && \
  git add .claude/ CLAUDE.md && \
  git commit -m "require gstack for AI-assisted work"

required bloquea el trabajo asistido por IA en el repositorio sin gstack; cámbielo por optional para alentar a los compañeros de equipo en lugar de bloquearlos. No se venden archivos en el repositorio: cada sesión de Claude Code comienza con una comprobación de actualización automática rápida (limitada a una vez por hora, segura ante fallas de red, silenciosa), lo que elimina la deriva de versiones en el equipo. La configuración personal mejora a un desarrollador; la configuración a nivel de repositorio crea una convención de ingeniería compartida.

Otros arneses, actualizaciones y desinstalación

• Otros agentes: ./setup --host codex, --host opencode, --host cursor, --host factory, --host kiro, --host slate, --host openclaw, y --host hermes instalan las habilidades en el directorio de habilidades propio de cada agente. El resumen de solo instrucciones de 2 KB en agents-digest/gstack-AGENTS.md cubre a los agentes que solo leen archivos de reglas.
• Nomenclatura de comandos: las habilidades se registran con nombres cortos por defecto (/qa, /review); ./setup --prefix cambia a nombres con espacio de nombres (/gstack-qa), lo que importa cuando ejecutas otros paquetes de habilidades junto con gstack.
• Actualizaciones: vuelva a ejecutar ./setup después de un git pull (obligatorio en Windows, donde las instalaciones son copias de archivos), o use la habilidad /gstack-upgrade; establecer auto_upgrade: true en ~/.gstack/config.yaml mantiene la instalación actualizada automáticamente.
• La telemetría está desactivada por defecto y pregunta por la participación en la primera ejecución. Si participa, envía el nombre de la habilidad, duración, éxito/fallo, versión de gstack y SO; nunca código, rutas de archivos, nombres de repositorios o prompts. gstack-config set telemetry off la desactiva en cualquier momento.
• Desinstalación: ~/.claude/skills/gstack/bin/gstack-uninstall elimina habilidades, enlaces simbólicos, el estado de ~/.gstack/, el estado local del proyecto, los demonios de navegación y las registraciones de hooks.

Verificar la instalación y corregir fallas comunes

• ./setup falla – confirme que Bun está en su PATH con bun --version; los componentes generados se construyen con la cadena de herramientas de Bun.
• Las habilidades no son reconocidas por Claude Code – confirme que el clon vive realmente en ~/.claude/skills/gstack, que el CLAUDE.md del proyecto tiene una sección de gstack, y vuelva a ejecutar ./setup.
• /browse informa NEED_ASIDE o ASIDE_NOT_RUNNING – la sonda le está diciendo que usará el navegador de respaldo. Eso es normal en Linux y Windows; en macOS significa que Aside no está abierto o no ha iniciado sesión.
• El navegador de respaldo falla – cd ~/.claude/skills/gstack && bun install && bun run build.
• Instalación obsoleta después de una actualización – ejecute /gstack-upgrade, o establezca auto_upgrade: true en ~/.gstack/config.yaml.

Probando gstack sin adoptar todo

Use gstack en una función real pero no crítica, en lugar de migrar su proceso de desarrollo. El inicio rápido del proyecto es el mismo ensayo, y termina con “detente allí”:

1. /office-hours – definición del problema
2. /plan-ceo-review – razonamiento de producto
3. /review – verificación de ingeniería, después de la implementación
4. /qa – verificación en tiempo de ejecución, para proyectos web

Si esas etapas revelan hallazgos que su flujo de trabajo normal de Claude Code omite, el resto del sistema vale la pena explorarlo; si en su mayoría producen texto adicional sin cambiar las decisiones de ingeniería, adoptar todo el stack probablemente no ayudará.

Lo que gstack hace bien

Roles de ingeniería separados. En lugar de una única instrucción gigante de “sé un ingeniero senior”, la estrategia de producto, la arquitectura, la UX, el QA, la seguridad y la ingeniería de lanzamientos cada una obtienen su propio modo de razonamiento.

Verificación, no solo generación. La revisión, el QA del navegador con generación de pruebas de regresión, las auditorías de seguridad, el benchmarking y la cadena de lanzamiento-despliegue-sentinela son flujos de trabajo de primera clase en gstack, no pensamientos posteriores opcionales.

Inspeccionable. Gran parte de la capa de comportamiento son archivos de Markdown planos que los desarrolladores pueden leer y modificar, a diferencia de los flujos de trabajo internos de un agente autónomo propietario. El repositorio también incorpora herramientas de auditoría para el stack mismo: gstack-context-bill informa cuánto cuesta en tokens un árbol de habilidades instalado, y gstack-egress escribe un recibo encadenado por hash para cada envío fuera de la máquina, incluida la telemetría.

Infraestructura de equipo. Las habilidades pueden codificar convenciones de ingeniería; en lugar de teclear

Remember to check API compatibility, run integration tests,
inspect the browser console, and update the changelog.

en cada sesión, los requisitos viven en un flujo de trabajo reutilizable, y el modo de equipo hace que ese flujo de trabajo sea un requisito del repositorio.

Donde gstack puede ser demasiado

gstack es intencionalmente opinado, y eso limita su ajuste: una organización madura puede ya tener procedimientos de revisión de arquitectura, herramientas de lanzamiento, puertas de CI, automatización de QA, escaneo de seguridad, convenciones de ADR, plantillas de especificación y políticas de revisión de código, y agregar otra metodología completa encima crea superposición en lugar de claridad.

También hay un costo de contexto y tokens: cada etapa de revisión adicional agrega inspección de repositorio, razonamiento del modelo y potencialmente más llamadas a modelos externos. El objetivo es el proceso confiable mínimo necesario para lanzar software correcto, no un número máximo de revisiones de IA; gstack-context-bill puede cuantificar lo que su conjunto de habilidades instalado cuesta realmente por sesión antes de decidir cuánto de ello mantener.

gstack funciona mejor como una caja de herramientas cuyos flujos de trabajo selecciona y adapta, no como una ceremonia para cada commit.

Alternativas y combinaciones de gstack

Las alternativas más cercanas, y la capa que cada una ocupa:

gstack + Superpowers: disciplina de implementación dentro de los roles

Ambos son marcos de habilidades, por lo que se superponen más. La división del trabajo al combinarlos: gstack proporciona los roles circundantes: producto, diseño, QA, lanzamiento; mientras que Superpowers proporciona la disciplina dentro de la fase de implementación (TDD, planificación antes de la implementación, depuración sistemática, revisión subagente). Instale ambos conjuntos de habilidades, luego recorte las habilidades superpuestas para que el agente nunca vea dos instrucciones contradictorias para la misma fase; si los nombres de comandos colisionan, instale gstack con ./setup --prefix para que sus habilidades se registren como /gstack-* y coexistan con el otro paquete. Los detalles de instalación y flujo de trabajo están en el inicio rápido de Superpowers.

gstack + OpenSpec: especificaciones duraderas, revisiones en vivo

OpenSpec mantiene alineados a humanos y agentes alrededor de especificaciones de cambios explícitas: artefactos para el cambio propuesto, especificaciones, decisiones de diseño y tareas de implementación. La propiedad clave es la persistencia: una conversación de chat desaparece en el historial de contexto, pero una especificación permanece en el repositorio donde humanos y sesiones de agentes futuras pueden revisarla. gstack agrega la revisión de producto antes de que exista la especificación y la revisión y el QA después de que se implementa:

Una secuencia concreta: ejecute /office-hours y /plan-ceo-review, capture el resultado como un cambio de OpenSpec, implemente contra él, luego ejecute /review y /qa. Tenga en cuenta que gstack también incorpora su propia habilidad /spec, que archiva especificaciones bajo ~/.gstack; si OpenSpec posee la especificación, mantenga la /spec de gstack fuera del bucle para que los dos no diverjan. El inicio rápido de OpenSpec cubre el bucle de explorar-proponer-aplicar-archivar en detalle.

gstack + GitHub Spec Kit: elija una columna vertebral de planificación

El flujo de trabajo central de Spec Kit es una secuencia de etapas explícitas: constitución, especificar, planificar, tareas, implementar, converger; y se ha expandido a corrección de errores, evaluación de ideas, extensiones, presets e integraciones. Dado que tanto Spec Kit como gstack centran la etapa de planificación, ejecutar ambos flujos completos duplica el trabajo. Si la trazabilidad de requisitos y las etapas formales importan, deje que Spec Kit posea la columna vertebral de la especificación y use gstack para las capas que Spec Kit no aplica: revisión de producto, revisión de diseño, QA de navegador y lanzamiento. Una comparación más amplia de configuraciones guiadas por especificaciones, incluyendo Kiro y Claude Code, está en GitHub Spec Kit vs Kiro vs Claude Code SDD Workflows.

BMAD y Ruflo: ejes diferentes

BMAD es una metodología de desarrollo impulsada por IA más amplia cuyos flujos de trabajo adaptativos cubren el pensamiento de producto, especificaciones, arquitectura e implementación, escalando la ceremonia al tamaño del trabajo. Tanto BMAD como gstack juegan el rol de columna vertebral de proceso, así que elija uno como columna vertebral en lugar de ejecutar ambos a todo; las habilidades individuales de gstack aún pueden seleccionarse junto con una metodología.

Ruflo apunta a la orquestación multi-agente: trabajadores coordinados, memoria compartida, enjambres. gstack aplica múltiples perspectivas especializadas a un flujo de trabajo de ingeniería; una plataforma de orquestación aplica múltiples agentes ejecutores a un objetivo de ingeniería. La frontera se difumina: gstack puede llamar a herramientas externas y modelos adicionales, y los orquestadores pueden implementar roles de ingeniería estructurados; pero la decisión es independiente: si el problema es que el agente omite la disciplina de ingeniería, un marco de habilidades es la corrección directa; si es ejecutar diez agentes simultáneamente en muchas tareas y repositorios, un orquestador se sitúa por encima de un flujo de trabajo como gstack, en lugar de reemplazarlo.

Habilidades personalizadas: la capa más personalizable

También puede omitir el marco por completo y crear una pequeña colección de habilidades para los procedimientos que su equipo ya sigue:

skills/
  architecture-review/
  api-review/
  database-migration-review/
  incident-analysis/
  release-check/
  security-review/

Cada habilidad codifica el conocimiento específico de la organización que un marco genérico no puede saber. Una habilidad de migración de base de datos puede requerir análisis de revocación, análisis de bloqueo de tablas, revisión de impacto de índices, estimación de duración de migración, orden de despliegue y compatibilidad con la versión anterior de la aplicación; una habilidad de revisión de API puede requerir compatibilidad hacia atrás, comprobaciones de autenticación, consistencia de paginación, análisis de idempotencia, comportamiento de limitación de velocidad y cambios de OpenAPI. Una ruta práctica: comience de las habilidades de gstack que realmente usa, copie su estructura a su propio directorio skills/, y reescriba las comprobaciones alrededor de sus convenciones.

Cuatro Capas: Habilidades, Especificaciones, Metodologías, Orquestadores

Cuatro capas cubren la mayoría de estas herramientas, y muestran cómo encajan las combinaciones anteriores:

Las habilidades responden “¿cómo debe comportarse el agente?”

gstack, Superpowers y habilidades de agente personalizadas.

Los sistemas de especificación responden “¿qué exactamente estamos construyendo?”

OpenSpec y GitHub Spec Kit; los conceptos y terminología subyacentes de especificación están definidos en ¿Qué es el Desarrollo Guiado por Especificaciones?.

Las metodologías responden “¿cómo debe moverse el proyecto de la idea al software?”

BMAD, Superpowers y partes de gstack.

Los orquestadores responden “¿cómo deberían ejecutar el trabajo múltiples agentes?”

Ruflo y otros runtime multi-agente.

Las capas se componen; un entorno de desarrollo puede contener las cuatro:

gstack ya abarca varias de estas fronteras.

¿Deberías usar gstack?

El README del proyecto describe al público objetivo como fundadores técnicos y CEOs que aún quieren lanzar, usuarios de Claude Code por primera vez que quieren roles estructurados en lugar de un prompt en blanco, y líderes técnicos e ingenieros de personal que quieren una revisión, QA y automatización de lanzamiento rigurosos en cada PR. gstack vale la pena probar si usa agentes de código extensivamente y el factor limitante ya no es la generación de código en sí. Síntomas típicos:

• el agente comienza a implementar antes de entender el problema
• los planes de implementación omiten implicaciones arquitectónicas
• el código generado pasa las pruebas pero falla en el navegador
• las revisiones son inconsistentes entre sesiones
• los pasos de lanzamiento se olvidan repetidamente
• diferentes desarrolladores hacen prompts al agente de maneras completamente diferentes
• las instrucciones de ingeniería útiles permanecen enterradas en archivos CLAUDE.md
• repite manualmente los mismos prompts de revisión

Si su automatización ya proporciona puertas deterministas fuertes y el agente solo maneja tareas pequeñas y bien especificadas, gstack agrega poco.

gstack y la dirección del desarrollo de software de IA

El cambio en el que gstack se sitúa se rastrea en generaciones: finalización de código (2022-2023), agentes de código (2024-2025), especificaciones y flujos de trabajo de agente (2025-2026), y organizaciones de ingeniería de IA programables. Los productos cambiarán, pero el modelo permanece como un componente; la calidad de ingeniería depende cada vez más del sistema circundante:

• especificaciones persistentes
• habilidades reutilizables
• conocimiento del repositorio
• acceso al navegador
• pruebas
• herramientas deterministas
• bucles de revisión
• controles de seguridad
• memoria
• límites de aprobación humana
• orquestación

Conclusión

gstack es el proceso de ingeniería alrededor de un agente de código, empacado como habilidades inspeccionables y controladas por versión, y su valor está en forzar ese proceso sobre el agente, no en ninguna habilidad individual.

Comience con la secuencia de prueba y mantenga solo las habilidades que ganan su lugar. Más allá de ello, la dirección son capas componibles: especificación, habilidades, verificación determinista, orquestación; cada una haciendo lo que las otras no pueden.

Referencias

• repositorio de gstack – fuente, definiciones de habilidades y configuración
• análisis en profundidad de habilidades de gstack – filosofía, ejemplos y flujo de trabajo de cada habilidad
• navegador Aside – el navegador que gstack maneja primero en macOS
• repositorio de Superpowers – fuente, habilidades y manifiestos de plugin
• repositorio de OpenSpec – fuente, documentos y el paquete CLI
• documentación de GitHub Spec Kit – referencia oficial del flujo de trabajo de Spec Kit
• repositorio de BMAD-METHOD – la metodología ágil adaptativa impulsada por IA
• repositorio de Ruflo – la plataforma de orquestación multi-agente