Source: https://aiprimetech.io/es/blog/gstack-claude-code-setup-guide/ Jul 15, 2026 · 7 min · Herramientas # gstack para Claude Code: qué hace realmente su flujo de trabajo con 23 agentes A Por [AI Prime Tech](https://aiprimetech.io/es/) · Con asistencia de IA Una solicitud de incorporación de cambios de 14 archivos puede superar las pruebas unitarias y aun así fallar por tres motivos totalmente distintos: el comportamiento del producto no está suficientemente definido, la interfaz resulta incómoda y las notas de la versión omiten un paso de migración. Ejecutar Claude Code una sola vez con «revisa esta solicitud de incorporación de cambios» concentra esas cuestiones en una única conversación sobrecargada. gstack adopta un enfoque más prescriptivo. Sus 23 herramientas basadas en roles dividen la entrega de software en planificación, diseño, implementación, revisión, control de calidad en el navegador, trabajo de publicación y documentación. En lugar de pedir a un asistente de programación de propósito general que improvise un proceso, invocas una secuencia de flujos de trabajo específicos de Claude Code, como /plan-ceo-review, /plan-eng-review, /review, /qay /ship. Esa distinción importa. gstack no es simplemente un directorio de prompts útiles, y sus «23 agentes» no son 23 trabajadores autónomos que se coordinan continuamente en segundo plano. Son habilidades de Claude Code específicas para cada rol, que se invocan en momentos concretos de un flujo de trabajo de ingeniería. El valor proviene del modelo operativo que imponen; también la mayor parte de la carga adicional. ## gstack para Claude Code es un sistema operativo, no un paquete de prompts El modelo mental útil para gstack para Claude Code es el de un sistema operativo de ingeniería superpuesto a Claude Code. Cada herramienta asigna a Claude un rol, un procedimiento y unos resultados esperados. En conjunto, estas herramientas plasman criterios sobre cómo debería pasar el software de una idea a producción. Un prompt genérico podría ser: ``` Review my implementation plan. ``` Un flujo de trabajo basado en roles plantea una pregunta más concreta: ``` /plan-eng-review ``` Esa habilidad puede indicar a Claude que examine la arquitectura, las dependencias, los modos de fallo, la facilidad de prueba, el riesgo del despliegue y la secuencia de implementación. Una habilidad de planificación orientada al producto puede examinar el mismo plan para evaluar el valor para el usuario y el alcance. Una habilidad orientada al diseño puede cuestionar los detalles de interacción en lugar de los límites del backend. La diferencia es la repetibilidad. No hace falta que cada miembro del equipo recuerde un prompt de revisión de 40 líneas o invente su propia lista de comprobación. La habilidad incorpora el procedimiento. La contrapartida es igual de importante: gstack introduce el procedimiento de otra persona en tu repositorio. Da por hecho que varias rondas de revisión, un control de calidad explícito y un trabajo de publicación estructurado justifican el contexto y el tiempo que consumen. Esto suele ser adecuado para cambios en producción, pero excesivo para una errata o un script interno de dos líneas. ## Qué abarcan realmente las 23 herramientas basadas en roles La lista exacta del repositorio puede evolucionar, así que considero los archivos SKILL.md de la copia local como la fuente de referencia, en lugar de basarme en capturas de pantalla o descripciones del lanzamiento. Lo importante de la arquitectura es la división de responsabilidades. | Fase de entrega | Herramientas representativas | Qué se le pide a Claude que haga | Limitación principal | Planificación del producto | /plan-ceo-review, /office-hours | Cuestionar el problema, el valor para el usuario, el alcance y los supuestos sobre el producto | El criterio sobre el producto sigue dependiendo del contexto de los clientes que se proporcione | Planificación de ingeniería | /plan-eng-review | Examinar la arquitectura, el flujo de datos, los casos límite, las pruebas y el despliegue | No puede validar restricciones de infraestructura sin documentar | Diseño | /plan-design-review, /design-consultation | Revisar la estructura de interacción, las decisiones visuales y la usabilidad | El texto y las capturas de pantalla aportan menos evidencia que la observación de usuarios reales | Control de la implementación | /careful, herramientas de protección o congelación | Limitar las ediciones arriesgadas y mantener el trabajo dentro de los límites declarados | Las restricciones pueden ralentizar cambios transversales legítimos | Revisión de código | /review | Examinar las diferencias de código en busca de defectos, regresiones, problemas de seguridad y pruebas faltantes | Los conjuntos grandes de cambios pueden seguir superando la capacidad práctica de atención durante la revisión | Control de calidad en ejecución | /qa, /browse | Probar la aplicación mediante un navegador e inspeccionar su comportamiento real | La configuración del entorno y los datos de prueba determinan la cobertura | Versión | /ship | Ejecutar las comprobaciones de publicación y coordinar los pasos de commit o entrega | Los permisos de Git y despliegue requieren un control deliberado | Documentación | /document-release, /retro | Registrar el comportamiento publicado, el contexto de la versión y las lecciones aprendidas | El texto generado debe contrastarse con el sistema final Por eso, llamar a gstack una «colección de prompts» se queda corto. Los resultados de la planificación alimentan la implementación; la implementación produce un conjunto de cambios; la revisión y el control de calidad examinan esos cambios; la publicación y la documentación preparan el resultado para su entrega. También por eso, «flujo de trabajo de 23 agentes» puede resultar engañoso. Lo que ocurre realmente al invocar una habilidad es que Claude Code carga instrucciones y ejecuta el flujo de trabajo asociado con las herramientas disponibles en la sesión actual. A menos que una habilidad delegue trabajo explícitamente, no hay 23 procesos persistentes que compartan un estado global. ### La planificación es redundante de forma intencionada Las revisiones de producto, ingeniería y diseño se solapan. Es deliberado. Considera una propuesta de función para «exportar toda la actividad de los clientes»: - La revisión de producto pregunta si los usuarios necesitan una exportación completa o un informe filtrado. - La revisión de ingeniería pregunta si la exportación cabe en memoria y cómo funcionan los reintentos. - La revisión de diseño pregunta dónde aparecen el estado de la exportación, los fallos y los controles de descarga. - El control de calidad pregunta qué ocurre cuando no hay registros, los enlaces han caducado o los trabajos se interrumpen. En la práctica, esta separación detecta supuestos que pasan desapercibidos dentro de un plan de implementación genérico. El coste es cargar el contexto repetidamente. Si el plan ya contiene 8,000 tokens, tres rondas de revisión pueden resultar caras y producir observaciones duplicadas. ### La revisión y el control de calidad son tareas distintas /review se basa principalmente en evidencia del código: diferencias, tipos, pruebas, puntos de llamada y convenciones del repositorio. /qa y /browse puede recopilar evidencia del comportamiento en ejecución de la propia aplicación. Esa separación es una de las mejores ideas de gstack. Un conjunto de cambios puede parecer correcto mientras que el resultado renderizado es inutilizable. A la inversa, una comprobación del caso ideal en el navegador puede pasar aunque la implementación introduzca una condición de carrera o una vía para eludir la autorización. Una secuencia práctica sería la siguiente: ``` /plan-eng-review /careful # Implement the approved plan in Claude Code /review /qa /document-release /ship ``` No lo trates como una secuencia obligatoria. Para una migración de base de datos, la revisión de ingeniería y la planificación de la reversión pueden importar mucho más que el diseño visual. Para una regresión de CSS, /browse, la revisión de diseño y el control de calidad pueden constituir el flujo de trabajo principal. ## Instalar gstack sin confiar ciegamente en él Una instalación típica a nivel de usuario coloca el repositorio en el directorio de habilidades de Claude Code y ejecuta su script de configuración: ``` git clone https://github.com/garrytan/gstack.git \ ~/.claude/skills/gstack cd ~/.claude/skills/gstack ./setup ``` Reinicia Claude Code después de la configuración si los nuevos comandos no se detectan de inmediato. A continuación, examina las habilidades instaladas en lugar de dar por hecho que la cantidad publicada sigue coincidiendo con tu copia local: ``` find ~/.claude/skills/gstack \ -name SKILL.md \ -print | sort find ~/.claude/skills/gstack \ -name SKILL.md | wc -l ``` Un error habitual es ejecutar scripts de instalación porque el repositorio es popular, sin leer qué modifican. gstack incluye mecanismos ejecutables para sus flujos de trabajo, no Markdown inerte. Antes de ejecutar la configuración, examínala: ``` cd ~/.claude/skills/gstack git status --short git log -1 --oneline sed -n '1,240p' setup ``` Para implantarlo en un equipo, fija un commit revisado en lugar de seguir silenciosamente el estado más reciente del repositorio: ``` git clone https://github.com/garrytan/gstack.git vendor/gstack cd vendor/gstack git checkout ./setup ``` El procedimiento exacto de instalación y las dependencias pueden cambiar a medida que se desarrolla el proyecto. Por tanto, el README actual del repositorio y el script de configuración deben prevalecer sobre los comandos copiados de un artículo antiguo, incluido este. ## Establece permisos de Claude Code para el flujo de trabajo Algunas herramientas de gstack necesitan un acceso amplio para examinar archivos, ejecutar pruebas, manejar un navegador o interactuar con Git. Eso no significa que todas las herramientas deban recibir permisos de shell y publicación sin restricciones. Un archivo de proyecto .claude/settings.json puede establecer una base conservadora: ``` { "permissions": { "allow": [ "Bash(git status:*)", "Bash(git diff:*)", "Bash(npm test:*)", "Bash(npm run lint:*)" ], "deny": [ "Read(./.env)", "Read(./.env.*)", "Bash(git push:*)", "Bash(git push --force:*)" ] } } ``` Trata esto como una política de ejemplo, no como un archivo universal listo para usar. Adapta los comandos a tu gestor de paquetes, tu ejecutor de pruebas y tu versión de Claude Code. La denegación deliberada de git push resulta especialmente útil durante la evaluación. /ship puede seguir comprobando si todo está listo para la publicación, pero la persona conserva el control sobre el efecto final en la red. Una vez que el equipo comprenda el flujo de trabajo, puedes decidir si está justificado conceder un permiso de push con un alcance muy limitado. Prueba también las habilidades orientadas al navegador en un entorno de preproducción o con datos locales precargados. La automatización del navegador con una sesión de producción puede modificar registros reales si el flujo de trabajo hace clic en un control destructivo. ## Adopta un subconjunto antes de adoptar el sistema Yo no introduciría las 23 herramientas en un equipo desde el primer día. Empieza por los puntos donde tu proceso actual pierde más información. Una matriz de evaluación razonable sería: | Problema del equipo | Empezar con | Posponer inicialmente | Los planes pasan por alto casos límite | /plan-eng-review | Secuencia completa de diseño y publicación | Los cambios en la interfaz introducen regresiones que pasan desapercibidas | /browse, /qa, /plan-design-review | Flujos de trabajo de estrategia de producto | Las revisiones son inconsistentes | /review | Publicación automatizada | Las versiones carecen de contexto | /document-release, /retro | Herramientas de navegador | Claude realiza ediciones demasiado amplias | /careful y controles de alcance | Adopción del flujo de trabajo de principio a fin Ejecuta el subconjunto en varios cambios reales y registra: - ¿Qué hallazgos provocaron cambios en el código o en el alcance? - ¿Qué hallazgos estaban duplicados? - ¿Cuánto contexto hubo que repetir? - ¿Se mantuvieron los artefactos generados sincronizados con la implementación? - ¿Qué comandos requirieron permisos que el equipo no concedería en CI? - ¿Comprendieron los desarrolladores cuándo invocar cada rol? La sobrecarga de contexto no es teórica. Cada rol necesita el estado del repositorio, los requisitos y las decisiones previas. Las sesiones separadas pueden perder la justificación de las decisiones; una sesión larga puede acumular supuestos obsoletos. Yo guardo el plan aprobado en un archivo del repositorio como docs/plans/export-jobs.md, y luego indico a cada flujo de trabajo que use ese artefacto. Los archivos persistentes son más fiables que esperar que el contexto de la conversación funcione como memoria del proyecto. ## Comportamiento documentado frente a afirmaciones promocionales La afirmación que se puede sostener es que gstack proporciona 23 herramientas de Claude Code orientadas a roles y un flujo de trabajo con criterios definidos que abarca el ciclo de vida del software. Puedes verificar ese comportamiento leyendo las habilidades instaladas y ejecutándolas en un repositorio de prueba. Las afirmaciones más amplias, como producir muchísimo más, sustituir a un equipo de ingeniería o reducir semanas a horas, son promocionales hasta que se demuestren en tu entorno. Los resultados dependen de la calidad del repositorio, la cobertura de pruebas, la ambigüedad de la tarea, la elección del modelo, los permisos y el desarrollador que supervisa el trabajo. La gama actual de modelos tampoco elimina estas restricciones. Sonnet 4.6 puede ser una opción predeterminada práctica para el trabajo de programación sostenido, mientras que Haiku 4.5 puede encajar en tareas más ligeras de clasificación o documentación. El contexto de 1M de Fable 5 puede ayudar con conjuntos de material muy grandes, y gpt-5.6-sol ofrece otra opción orientada a la ingeniería en los entornos compatibles. Ninguno convierte un prompt de rol en conocimiento verificado del producto ni en evidencia de producción. ## Conclusiones prácticas - Trata gstack como un proceso de desarrollo con criterios definidos, implementado mediante habilidades de Claude Code. - Entiende «23 agentes» como herramientas basadas en roles, no como trabajadores persistentes coordinados automáticamente. - Instala desde el repositorio, inspecciona setup y fija un commit revisado para que lo use el equipo. - Empieza con dos o tres flujos de trabajo que aborden fallos conocidos en la entrega. - Guarda los planes y las decisiones aprobados en archivos para que los roles compartan un contexto persistente. - Separa la revisión de código del control de calidad en tiempo de ejecución; detectan distintas clases de fallos. - Restringe los secretos, las sesiones de producción, los envíos a Git y los comandos de despliegue durante la evaluación. - Mide los hallazgos útiles y los defectos evitados, no la cantidad de comandos ejecutados. - Adopta el sistema operativo completo solo cuando el coste de su proceso sea menor que el de los fallos que evita. [Programación](/es/blog/tag/coding/)[Claude](/es/blog/tag/claude/)[Agentes](/es/blog/tag/agents/)[Modelos](/es/blog/tag/models/) A [AI Prime Tech](https://aiprimetech.io/es/) AI Prime Tech publica este blog. Los artículos se redactan con asistencia de IA; comprueba los detalles específicos de cada versión, como los identificadores de modelos, los precios y los límites, en la documentación oficial antes de basarte en ellos. Obtén acceso más económico a la API de Claude Una sola clave de API para Claude Opus 5.5, Sonnet 5, Haiku 4.5 y Fable 5.1, además de GPT-6 modelos. Pago por uso, sin suscripción. [Obtén tu clave de API →](/register) AI Prime Tech es una pasarela de API independiente de terceros. Claude™ y Anthropic® son marcas comerciales de Anthropic, PBC. No se implica ninguna afiliación ni respaldo.