Garry Tan publie gstack, un système de workflow pour Claude Code avec QA, revue et release

Garry Tan a publié en open source gstack, un ensemble de skills pour Claude Code qui transforme le travail avec un agent IA de programmation en un processus plus strict et plus prévisible. L'idée est simple : ne pas mélanger planification, revue d'ingénierie, QA et release dans un prompt interminable, mais les répartir en modes distincts aux rôles clairs.

Ce qu'est gstack

Gstack n'est ni un nouveau modèle ni un énième framework d'agents, mais une couche de workflow au-dessus de Claude Code. Le projet regroupe les étapes typiques de la livraison de logiciels en commandes séparées et fixe pour chacune un état d'esprit propre. Au lieu d'improviser sur le mode « fais la fonctionnalité et vérifie-toi toi-même », le développeur obtient une suite d'étapes : d'abord la formulation produit, puis le plan d'ingénierie, ensuite la revue, la vérification dans le navigateur et, seulement après, la préparation de la release. Autrement dit, gstack cherche à apporter au développement assisté par IA de la discipline de processus, pas de la magie.

«

Eight opinionated workflow skills for Claude Code » : c'est ainsi que le projet se décrit lui-même.

L'idée clé n'est pas de donner plus de liberté à l'agent, mais l'inverse : réduire le contexte de chaque tâche. D'après la description du projet, cela doit diminuer les décisions médiocres qui surgissent quand la même IA imagine la fonctionnalité, écrit le code, teste l'interface et décide si l'on peut déployer en production. Gstack sépare ces rôles et oblige à les enchaîner dans l'ordre, comme si des personnes différentes, avec des responsabilités différentes, travaillaient sur la tâche.

Huit modes de travail

Au moment de la sortie, le dépôt comptait huit commandes principales, chacune couvrant une partie du processus et non « tout à la fois ». C'est le principal pari de gstack : la qualité progresse non grâce à une intelligence nouvelle, mais grâce à la discipline autour d'un agent de programmation existant. Une commande examine l'idée produit, une autre l'architecture et les tests, une autre les risques dans le code, et une dernière gère l'étape finale avant le merge et la release.

• `/plan-ceo-review` — revue produit de l'idée et des priorités
• `/plan-eng-review` — architecture, data flow, edge cases et tests
• `/review` — recherche de risques en production et de problèmes dans le code
• `/ship` — synchronisation de la branche, exécution des tests et préparation de la PR
• `/browse`, `/qa`, `/setup-browser-cookies`, `/retro` — navigateur, QA, import de cookies et rétrospective

Cette répartition des rôles paraît particulièrement logique face à un problème classique du code assisté par IA : l'agent écrit vite le happy path, mais saute souvent les cas limites, les régressions et les défauts d'UX. Dans gstack, ces vérifications sont isolées dans des modes distincts afin qu'elles ne concurrencent pas la tâche « écrire le code le plus vite possible ». Cela ne garantit pas l'absence d'erreurs, mais rapproche le processus de la pratique d'ingénierie habituelle, où conception, implémentation, vérification et livraison ne sont pas entassées en une seule étape.

Navigateur, QA et stack

La partie la plus intéressante de gstack n'est pas constituée des skills en markdown, mais du runtime de navigateur persistant. Plutôt que de lancer un nouveau navigateur à chaque action, le système démarre un daemon Chromium headless de longue durée et dialogue avec lui en HTTP sur localhost. C'est utile à la fois pour la vitesse et pour conserver l'état entre les étapes. D'après la description du projet, le démarrage à froid de l'outil de navigation prend environ 3–5 secondes, et les appels suivants s'exécutent en 100–200 millisecondes environ. Ainsi, cookies, onglets, localStorage et état de connexion persistent entre les commandes.

La façon dont ce navigateur s'intègre au flux de QA compte aussi. La commande `/browse` permet à l'agent d'ouvrir l'application, de cliquer dans l'interface, de faire des captures d'écran et de voir où ça casse. `/qa` va plus loin : il analyse le diff de la branche, détermine les routes touchées et vérifie précisément les pages et scénarios que les changements ont pu affecter. Dans l'exemple du dépôt, ce mode a analysé huit fichiers modifiés, trouvé trois routes touchées et les a exécutées sur une instance locale de l'application, reliant ainsi les changements de code au comportement réel de l'interface.

Sur le plan technique, gstack reste pragmatique. Il requiert Claude Code, Git et Bun 1.0+, et, au moment de la publication, le dépôt utilisait Playwright et le paquet `diff`, la commande `/browse` étant compilée en un binaire exécutable à part. L'ensemble peut s'installer dans `~/.claude/skills/gstack` ou se placer dans un `.claude/skills/gstack` local au sein du projet, afin que toute l'équipe suive le même processus. Les auteurs justifient le choix de Bun par des raisons simples : binaires compilés, accès natif à SQLite, exécution de TypeScript sans surcouche et serveur HTTP intégré via `Bun.serve()`.

Ce que cela signifie

Gstack est intéressant non comme « un énième jeu de prompts », mais comme une tentative de transformer le code assisté par IA en chaîne reproductible, avec des contrôles à chaque étape. Si cette approche s'impose, le marché ira non seulement vers des modèles plus puissants, mais aussi vers des couches opérationnelles plus strictes par-dessus, avec des modes distincts pour la planification, la revue, le QA et la release. Le principal changement est que l'on tente de bâtir la confiance envers l'IA non sur les promesses du modèle, mais sur des étapes de vérification.