gstack : Pile de stack d’ingénierie logicielle IA

Les agents de codage IA peuvent déjà écrire des fonctions, modifier des dépôts, exécuter des tests et ouvrir des demandes de fusion (pull requests). Le problème plus difficile est d’amener un agent à suivre un processus d’ingénierie réutilisable avant, pendant et après l’écriture du code.

gstack, un projet de Garry Tan initialement construit autour de Claude Code, emprunte une voie différente : au lieu de remplacer votre agent de codage par une autre plateforme, il enveloppe l’agent que vous utilisez déjà avec des compétences spécialisées, des outils de navigateur, des revues, des contrôles de sécurité et des processus de publication. Le projet décrit le résultat comme une équipe d’ingénierie virtuelle – vingt-trois spécialistes et huit outils puissants, tous sous forme de commandes en barre oblique (slash commands), tous en Markdown, sous licence MIT.

Les cibles de la comparaison dépendent de la partie de gstack dont vous avez besoin : des collections de compétences telles que Superpowers, des systèmes de spécification tels que OpenSpec et GitHub Spec Kit, des méthodologies telles que BMAD, des plateformes d’orchestration telles que Ruflo, ou votre propre ensemble de compétences d’agent entretenu. Plusieurs de ces éléments se combinent avec gstack plutôt que de le remplacer, et l’écosystème plus large auquel ils appartiennent tous est cartographié dans le centre des outils de développement IA de ce site.

Qu’est-ce que gstack ?

gstack est une collection open source de flux de travail d’ingénierie IA. Selon la vision de gstack, le développement logiciel consiste en plusieurs types de raisonnement différents, et demander à un prompt de codage générique unique de les exécuter tous est une mauvaise abstraction – le projet expose donc des compétences spécialisées à la place :

• exploration du produit
• revue du produit et du CEO
• revue d’architecture
• revue de l’expérience développeur
• revue de conception
• revue d’implémentation
• QA basée sur le navigateur
• investigation et débogage
• analyse de sécurité
• documentation
• benchmarking
• préparation à la publication
• déploiement
• rétrospectives

Le projet présente ces rôles comme une équipe d’ingénierie virtuelle : un CEO qui repense le produit, un manager technique qui verrouille l’architecture, un designer qui détecte la « saleté IA » (AI slop), un revueur qui trouve les bugs de production, un responsable QA qui ouvre un vrai navigateur, un agent de sécurité qui exécute des audits OWASP et STRIDE, et un ingénieur de publication qui livre la demande de fusion. La chaîne d’outils autour des définitions de compétences est TypeScript et Bun : un script de configuration, une documentation des compétences générée, des hooks de session, un état sous ~/.gstack/, un navigateur intégré et un ensemble de CLIs autonomes.

gstack n’est ni un modèle de fondation ni un remplaçant pour Claude Code ; c’est une couche de processus exécutée au-dessus d’un harnais d’agent :

Deux propriétés structurelles déterminent où gstack s’inscrit. D’abord, le projet le décrit comme un processus plutôt que comme une collection d’outils : les compétences s’exécutent dans l’ordre d’un sprint – réfléchir, planifier, construire, réviser, tester, livrer, réfléchir en arrière – et chaque compétence transmet ses artefacts à la suivante, de sorte que /office-hours écrit une note de conception que /plan-ceo-review lit, et /plan-eng-review écrit un plan de test que /qa prend en charge. Deuxièmement, gstack n’est pas exclusif à Claude Code : ./setup détecte automatiquement les agents installés sur la machine, et ./setup --host <name> cible Codex CLI, OpenCode, Cursor, Factory Droid, Kiro, Slate, OpenClaw et Hermes, tandis qu’un résumé de 2 Ko contenant uniquement des instructions dans le dépôt couvre les agents qui lisent des règles et n’ont besoin d’aucune installation.

Pourquoi gstack existe

Une session Claude Code vierge est extrêmement flexible, et cette flexibilité est aussi l’une de ses faiblesses. Prenons une demande de fonctionnalité telle que :

Ajouter des jetons d'API au niveau de l'organisation à l'application.

Un agent capable pourrait immédiatement inspecter le dépôt et commencer à modifier le code d’authentification, tandis qu’un ingénieur senior demanderait d’abord qui possède les jetons, si les utilisateurs peuvent appartenir à plusieurs organisations, comment les jetons sont révoqués, si les permissions sont héritées, ce qui arrive à l’authentification existante, si les jetons doivent expirer, comment les secrets sont affichés, et quels événements d’audit sont requis. L’agent peut éventuellement découvrir certaines de ces questions, mais il n’y a aucune garantie qu’il les découvrira avant l’implémentation. gstack déplace cette discipline dans des flux de travail réutilisables : au lieu de idée -> agent de codage -> code, le changement passe par la revue de produit, la planification technique, la revue d’architecture, l’implémentation, la revue de code, la QA navigateur et la publication comme des étapes nommées, chacune avec sa propre commande (la séquence complète est dans Un flux de travail gstack pratique ci-dessous).

Cela ne rend pas l’IA correcte ; cela change la distribution de probabilité de ses erreurs. L’agent est poussé à remettre en question les hypothèses plus tôt, à inspecter les preuves, à réviser son propre travail sous plusieurs perspectives et à vérifier l’application au lieu de s’arrêter lorsque le code compile.

Comment gstack transforme les compétences Markdown en processus

La plupart des capacités de gstack proviennent de définitions de compétences Markdown. Une compétence d’agent peut décrire :

• quand elle doit s’exécuter
• quel contexte elle doit inspecter
• quelles questions elle doit poser
• quels outils elle peut utiliser
• quelles commandes elle doit exécuter
• quelles preuves elle doit collecter
• quels contrôles doivent passer
• comment le résultat doit être structuré

Une telle compétence agit quelque part entre la documentation, un prompt réutilisable, une procédure opérationnelle standard et une configuration de flux de travail exécutable. Les mécanismes sous-jacents sont couverts dans Claude Skills et SKILL.md pour les développeurs ; gstack ajoute une infrastructure au-dessus de ce primitif : définitions de compétences générées, hooks de démarrage et de complétion, gestion d’état sous ~/.gstack/, automatisation du navigateur, mécanismes de sécurité, inspection du dépôt, télémétrie sur option, mémoire inter-sessions gérée par /learn, et une connaissance persistante optionnelle via le projet séparé GBrain, que /setup-gbrain peut mettre en place comme une base de données PGLite locale, un projet Supabase, ou un point de terminaison MCP distant.

Les compétences gstack les plus importantes

La collection exacte change rapidement, mais plusieurs flux de travail illustrent comment le système est censé être utilisé.

office-hours

/office-hours se situe près du début d’un projet ou d’une fonctionnalité. Il exécute six questions contraignantes sur le problème avant l’écriture de tout code, et dans l’exemple travaillé du README, il reframe une demande d’application de « briefing quotidien » en un chef de cabinet personnel IA, puis écrit la note de conception que chaque compétence en aval lit. Pour une entrée vague comme « nous avons besoin d’une meilleure recherche de projet », la sortie est un besoin, pas du code.

plan-ceo-review

/plan-ceo-review examine les hypothèses au niveau du produit derrière un plan. Il fonctionne dans quatre modes de périmètre – Expansion, Expansion Sélective, Maintien du Périmètre, Réduction – et peut remettre en question le périmètre, identifier des opportunités manquantes, réduire le travail inutile, ou suggérer de formuler le problème différemment. Il s’exécute avant que les besoins ne soient fixés, une étape que la plupart des outils d’agents de codage n’ont pas.

plan-eng-review

/plan-eng-review déplace la perspective vers l’ingénierie : architecture, flux de données, diagrammes, cas limites, matrice de tests, modes de défaillance et préoccupations de sécurité. Il reste séparé de la revue de produit parce que fusionner les deux dans un seul grand prompt amène le modèle à mélanger les décisions produit et les décisions d’implémentation.

plan-design-review et design-review

gstack traite la conception visuelle et d’interaction comme une discipline separate. /plan-design-review note chaque dimension de conception de 0 à 10, décrit à quoi ressemble un 10, et modifie le plan pour combler l’écart, avec la détection de la « saleté IA » comme contrôle nommé. Le /design-review ultérieur exécute la même audit contre l’implémentation réelle et corrige ce qu’il trouve avec des commits atomiques et des captures d’écran avant/après. Pour les applications web, les deux s’accompagnent de l’automatisation du navigateur de gstack.

review

/review effectue une revue d’ingénierie des changements du dépôt sous la perspective d’un ingénieur de niveau staff : il corrige automatiquement les observations évidentes, signale le reste pour approbation, et maintient une lentille de simplification consultative pour le code sur-construit. Le code écrit avec succès n’est pas nécessairement le code qui doit être fusionné.

investigate

/investigate impose une règle systématique de débogage que le projet appelle la Loi de Fer : pas de correctifs sans investigation. Il trace le flux de données, teste les hypothèses, et s’arrête après trois tentatives de correction échouées au lieu de continuer à errer. Il active aussi automatiquement /freeze, qui verrouille les modifications au module en cours d’investigation.

qa et qa-only

/qa a l’agent opérer un navigateur, interagir avec l’application, trouver des bugs, les corriger avec des commits atomiques, re-vérifier, et générer un test de régression pour chaque correction. /qa-only exécute la même méthodologie en mode rapport uniquement. Beaucoup d’agents de codage arrêtent la vérification à « tests passés » ; pour une application web, le navigateur est là que les erreurs d’intégration, les problèmes de mise en page, les flux incorrects, les échecs d’authentification et les exceptions JavaScript deviennent généralement visibles.

ship, land-and-deploy, et canary

La chaîne de publication est constituée de trois compétences plutôt que d’une seule. /ship synchronise main, exécute les tests, audite la couverture, pousse, et ouvre la demande de fusion, instaurant un framework de test si le projet n’en a pas. /land-and-deploy fusionne, attend la CI et le déploiement, et vérifie la santé de la production. /canary exécute ensuite une boucle de surveillance post-déploiement qui surveille les erreurs de console, les régressions de performance et les échecs de page.

autoplan, spec, learn, et retro

/autoplan exécute automatiquement le pipeline de revue CEO, design, DX et ingénierie – l’ingénierie toujours en dernier, de sorte que la porte de livraison révisé le plan final amendé – et ne surface que les décisions de goût pour approbation. /spec transforme une intention vague en une spécification précise et exécutable en cinq phases (pourquoi, périmètre, technique avec lecture de code obligatoire, brouillon, fichier) avec une porte de qualité de revue externe avant l’enregistrement. /learn gère ce que gstack a appris à travers les sessions – modèles, pièges et préférences – avec revue, recherche, élagage et export. /retro produit une rétro hebdomadaire consciente de l’équipe ; /retro global l’exécute à travers tous vos projets et outils IA.

Automatisation du navigateur dans gstack

Sur les systèmes macOS pris en charge (macOS 15+), gstack pilote d’abord le navigateur Aside – votre vrai navigateur, avec vos vraies sessions connectées, dans des onglets que l’agent ouvre pour lui-même et ferme une fois terminé. Lorsque Aside n’est pas disponible, gstack revient à son propre moteur basé sur Chromium, que ./setup construit et qui exécute un démon persistant plutôt que de lancer un nouveau navigateur pour chaque commande :

L’état persistant du navigateur permet aux cookies, aux sessions d’authentification et aux onglets de survivre entre les opérations, ce qui rend la QA basée sur le navigateur pratique. /open-gstack-browser expose le moteur de secours en mode visible, avec un agent de barre latérale qui route les actions rapides (clic, navigation, capture d’écran) vers Sonnet et la lecture ou l’analyse vers Opus. Lorsque l’agent rencontre un CAPTCHA, un mur d’authentification ou une invite MFA, $B handoff ouvre un navigateur visible à la même page avec les cookies et les onglets intacts ; vous le résolvez, et $B resume reprend là où l’agent s’était arrêté. L’agent suggère automatiquement un handoff après trois échecs consécutifs. /pair-agent partage le navigateur avec d’autres agents – OpenClaw, Hermes, Codex, Cursor, ou tout ce qui peut faire un curl – avec des jetons limités, une isolation des onglets, une limitation de débit et une attribution d’activité par onglet.

Le moteur persistant augmente également la surface de sécurité, car un agent avec accès aux sessions authentifiées détient un privilège significatif. gstack fournit une défense en couches contre l’injection de prompt pour cela : des filtres de contenu (datamarking, suppression des éléments cachés, nettoyage ARIA, liste de blocage d’URL) à chaque lecture de page, plus un classifieur ML local dans un sous-processus latéral qui scanne le contenu dérivé de la page avant que l’agent ne le voie, avec un combinateur de verdict qui exige l’accord du classifieur avant de bloquer. Le contenu de la page est traité comme une entrée non fiable – l’agent prend la syntaxe d’une page, jamais des instructions. Vérifications avant et pendant l’utilisation de la QA pilotée par navigateur :

• Déterminez à l’avance quels environnements authentifiés l’agent peut opérer, et préférez un profil isolé pour les travaux de QA lorsque le moteur de secours est utilisé.
• Connaissant l’interrupteur d’urgence : GSTACK_SECURITY_OFF=1 désactive la couche de sécurité – ne le laissez pas activé.
• Le démon persistant conserve les cookies et les sessions entre les exécutions, donc arrêtez-le une fois terminé et confirmez que rien n’est laissé en cours d’exécution, par exemple ps aux | grep -i chrom.
• Lisez les hooks et les mécanismes de sécurité dans le dépôt cloné avant de les activer – ce sont des fichiers simples, donc examinez-les comme vous examineriez une configuration CI.
• Après avoir mis à jour le clone, relancez ./setup afin que les composants générés restent synchronisés avec les définitions de compétences.

Garde-fous de sécurité et seconds avis

Trois outils puissants agissent comme des interrupteurs de sécurité au niveau de la session. /careful avertit avant les commandes destructives – rm -rf, DROP TABLE, force-push, git reset --hard – et s’active en disant « faites attention » ; les suppressions récursives du dossier racine ou home et les force-pushes vers la branche par défaut sont refusés de force. /freeze restreint les modifications de fichiers à un seul répertoire pour que l’agent ne puisse pas « corriger » un code non lié pendant le débogage, et /guard active les deux à la fois.

Les revues de second avis croisent les harnais : sur Claude Code, /codex envoie le travail à OpenAI Codex CLI pour une revue indépendante, un défi ou une consultation ; sur les autres harnais, /claude-code fait l’inverse. Chaque rapport identifie le fournisseur qui a effectivement terminé la revue.

Un flux de travail gstack pratique

Vous n’avez pas besoin de chaque compétence gstack pour chaque changement. Un flux de travail de fonctionnalité raisonnable :

1. /office-hours
2. /plan-ceo-review
3. Créer le plan d’implémentation
4. /plan-eng-review
5. Implémenter
6. /review
7. /qa
8. /ship

Lesquelles compétences de revue ajouter dépend de pour qui le logiciel est construit :

Pour une correction de bug triviale, aller directement à l’investigation, l’implémentation, la revue et les tests est souvent suffisant. Une version neutre en termes d’outils de la même forme – spécification, conception, tâches, implémentation, validation – est dans Flux de travail de développement par spécification Des exigences au code. Le README du projet décrit l’exécution de dix à quinze de ces sprints en parallèle, chacun dans son propre espace de travail isolé ; la structure de sprint est ce que le projet dit maintient les agents parallèles loin de devenir des sources de chaos.

Installer gstack

L’installation actuelle attend une configuration Claude Code fonctionnelle, Git, Bun v1.0+, et, sur Windows, Node.js – Bun a un bug connu avec le transport de tuyau de Playwright sur Windows, donc le serveur de navigateur revient à Node.js là-bas. Si vous n’avez pas encore configuré Claude Code, commencez par l’aperçu de Claude Code d’abord. Sur macOS, le navigateur Aside (macOS 15+) est recommandé pour les compétences de navigateur ; sans lui, le démon Chromium intégré est utilisé.

1. Vérifiez vos prérequis : git --version et bun --version (la chaîne d’outils est basée sur Bun).

2. Clonez gstack dans le répertoire des compétences Claude :

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

3. Exécutez le script de configuration depuis le répertoire cloné :

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

   La configuration installe et génère les composants requis par les compétences prises en charge et construit le navigateur intégré ; une échec d’installation de Chromium est de meilleure foi, la configuration enregistre la raison, termine l’enregistrement de chaque compétence, et imprime quelles compétences sont affectées.

4. Ajoutez une section ## gstack au CLAUDE.md du projet. Les instructions d’installation du projet incluent cette étape, et c’est ce qui permet à Claude Code de router les compétences : utilisez /browse de gstack pour toute navigation web, n’utilisez jamais les outils mcp__claude-in-chrome__*, et listez les compétences disponibles.

5. Vérifiez l’installation : vérifiez que les fichiers générés sont présents dans le répertoire cloné, démarrez une session Claude Code, et exécutez /office-hours sur un projet de brouillon pour confirmer que la compétence est reconnue.

Mode équipe

Pour les dépôts, gstack offre une configuration orientée équipe où les développeurs partagent un seul flux de travail au lieu d’environnements configurés individuellement :

(cd ~/.claude/skills/gstack && ./setup --team) && \
  ~/.claude/skills/gstack/bin/gstack-team-init required && \
  git add .claude/ CLAUDE.md && \
  git commit -m "exiger gstack pour le travail assisté par IA"

required bloque le travail assisté par IA dans le dépôt sans gstack ; remplacez-le par optional pour inciter les coéquipiers au lieu de les bloquer. Aucun fichier n’est intégré dans le dépôt : chaque session Claude Code commence avec une vérification de mise à jour automatique rapide (limitée à une fois par heure, sûre en cas d’échec réseau, silencieuse), qui élimine la dérive de version au sein de l’équipe. La configuration personnelle améliore un développeur ; la configuration au niveau du dépôt crée une convention d’ingénierie partagée.

Autres harnais, mises à niveau et désinstallation

• Autres agents : ./setup --host codex, --host opencode, --host cursor, --host factory, --host kiro, --host slate, --host openclaw et --host hermes installent les compétences dans le répertoire de compétences propre à chaque agent. Le résumé de 2 Ko contenant uniquement des instructions dans agents-digest/gstack-AGENTS.md couvre les agents qui ne lisent que les fichiers de règles.
• Nommage des commandes : les compétences s’enregistrent avec des noms courts par défaut (/qa, /review) ; ./setup --prefix passe à des noms éponymiques (/gstack-qa), ce qui est important lorsque vous exécutez d’autres packs de compétences aux côtés de gstack.
• Mises à niveau : relancez ./setup après un git pull (requis sur Windows, où les installations sont des copies de fichiers), ou utilisez la compétence /gstack-upgrade ; définir auto_upgrade: true dans ~/.gstack/config.yaml maintient l’installation à jour automatiquement.
• La télémétrie est désactivée par défaut et demande l’opt-in à la première exécution. Si vous optez pour, elle envoie le nom de la compétence, la durée, le succès/échec, la version de gstack et le SO – jamais le code, les chemins de fichiers, les noms de dépôt ou les prompts. gstack-config set telemetry off la désactive à tout moment.
• Désinstallation : ~/.claude/skills/gstack/bin/gstack-uninstall supprime les compétences, les liens symboliques, l’état ~/.gstack/, l’état local du projet, les démons de navigateur et les enregistrements de hooks.

Vérifier l’installation et corriger les échecs courants

• ./setup échoue – confirmez que Bun est dans votre PATH avec bun --version ; les composants générés sont construits par la chaîne d’outils Bun.
• Compétences non reconnues par Claude Code – confirmez que le clone réside vraiment dans ~/.claude/skills/gstack, que le CLAUDE.md du projet a une section gstack, et relancez ./setup.
• /browse signale NEED_ASIDE ou ASIDE_NOT_RUNNING – le probe vous dit qu’il utilisera le navigateur de secours. C’est normal sur Linux et Windows ; sur macOS, cela signifie qu’Aside n’est pas ouvert ou connecté.
• Le navigateur de secours échoue – cd ~/.claude/skills/gstack && bun install && bun run build.
• Installation obsolète après une mise à jour – exécutez /gstack-upgrade, ou définissez auto_upgrade: true dans ~/.gstack/config.yaml.

Essayer gstack sans tout adopter

Utilisez gstack sur une fonctionnalité réelle mais non critique plutôt que de migrer votre processus de développement. Le démarrage rapide du projet est le même essai, et il se termine par « arrêtez-vous là » :

1. /office-hours – définition du problème
2. /plan-ceo-review – raisonnement produit
3. /review – vérification d’ingénierie, après implémentation
4. /qa – vérification d’exécution, pour les projets web

Si ces étapes font surface des observations que votre flux de travail Claude Code normal manque, le reste du système vaut la peine d’être exploré ; si elles produisent principalement du texte supplémentaire sans changer les décisions d’ingénierie, l’adoption de tout le stack ne sera probablement pas utile.

Ce que gstack fait bien

Rôles d’ingénierie séparés. Au lieu d’une instruction gigantesque « sois un ingénieur senior », la stratégie produit, l’architecture, l’UX, la QA, la sécurité et l’ingénierie de publication ont chacune leur propre mode de raisonnement.

Vérification, pas seulement génération. La revue, la QA navigateur avec génération de tests de régression, les audits de sécurité, le benchmarking et la chaîne ship-deploy-canary sont des flux de travail de premier ordre dans gstack plutôt que des après-pensées optionnels.

Inspectable. Une grande partie de la couche comportementale est constituée de fichiers Markdown simples que les développeurs peuvent lire et modifier, contrairement aux flux de travail internes d’un agent autonome propriétaire. Le dépôt fournit également des outils d’audit pour le stack lui-même : gstack-context-bill rapporte ce que coûte en jetons un arbre de compétences installé, et gstack-egress écrit un reçu chaîné par hachage pour chaque envoi hors machine, télémétrie incluse.

Infrastructure d’équipe. Les compétences peuvent coder des conventions d’ingénierie – au lieu de taper

N'oubliez pas de vérifier la compatibilité de l'API, d'exécuter les tests d'intégration,
d'inspecter la console du navigateur et de mettre à jour le journal des modifications.

dans chaque session, les exigences résident dans un flux de travail réutilisable, et le mode équipe fait de ce flux de travail une exigence du dépôt.

Où gstack peut être trop

gstack est intentionnellement d’opinion, et cela limite son ajustement : une organisation mature peut déjà avoir des procédures de revue d’architecture, des outils de publication, des portes CI, une automatisation de QA, un balayage de sécurité, des conventions ADR, des modèles de spécification et des politiques de revue de code, et l’ajout d’une autre méthodologie complète au-dessus crée une superposition au lieu de la clarté.

Il y a aussi un coût de contexte et de jetons : chaque étape de revue supplémentaire ajoute une inspection du dépôt, un raisonnement du modèle et potentiellement plus d’appels de modèles externes. L’objectif est le processus minimal fiable nécessaire pour livrer un logiciel correct, pas un nombre maximal de revues IA ; gstack-context-bill peut quantifier ce que coûte réellement votre ensemble de compétences installé par session avant de décider combien en conserver.

gstack fonctionne mieux comme une boîte à outils dont vous sélectionnez et adaptez les flux de travail, pas comme une cérémonie pour chaque commit.

Alternatives et combinaisons de gstack

Les alternatives les plus proches, et la couche que chacune occupe :

gstack + Superpowers : la discipline d’implémentation à l’intérieur des rôles

Les deux sont des frameworks de compétences, ils se chevauchent donc le plus. La division du travail lors de leur combinaison : gstack fournit les rôles environnants – produit, design, QA, publication – tandis que Superpowers fournit la discipline à l’intérieur de la phase d’implémentation (TDD, planification avant implémentation, débogage systématique, revue par sous-agent). Installez les deux ensembles de compétences, puis éliminez les compétences superposées pour que l’agent ne voie jamais deux instructions contradictoires pour la même phase ; si les noms de commandes entrent en conflit, installez gstack avec ./setup --prefix pour que ses compétences s’enregistrent sous /gstack-* et coexistent avec l’autre pack. Les détails d’installation et de flux de travail sont dans Le démarrage rapide de Superpowers.

gstack + OpenSpec : spécifications durables, revues en direct

OpenSpec maintient l’alignement entre l’humain et l’agent autour de spécifications de changement explicites – artefacts pour le changement proposé, spécifications, décisions de conception et tâches d’implémentation. La propriété clé est la persistance : une conversation de chat disparaît dans l’historique du contexte, mais une spécification reste dans le dépôt où les humains et les futures sessions d’agent peuvent la réviser. gstack ajoute la revue produit avant que la spécification n’existe et la revue et la QA après qu’elle est implémentée :

Une séquence concrète : exécutez /office-hours et /plan-ceo-review, capturez le résultat comme un changement OpenSpec, implémentez à son égard, puis exécutez /review et /qa. Notez que gstack fournit également sa propre compétence /spec, qui archive les spécifications sous ~/.gstack ; si OpenSpec possède la spécification, gardez la /spec de gstack en dehors de la boucle pour que les deux ne divergent pas. Le [démarrage rapide d’OpenSpec](https://www.glukhov.org/fr/ai-devtools/openspec/ “Démarrage rapide d’OpenSpec : Installation, Flux de travail et Pièges courants”}) couvre en détail la boucle explorer-poser-appliquer-archiver.

gstack + GitHub Spec Kit : choisissez un seul squelette de planification

Le flux de travail central de Spec Kit est une séquence d’étapes explicites – constitution, spécifier, planifier, tâches, implémenter, converger – et il s’est étendu vers la correction de bugs, l’évaluation d’idées, les extensions, les préréglages et les intégrations. Comme Spec Kit et gstack centrent tous deux l’étape de planification, l’exécution des deux flux complets duplique le travail. Si la traçabilité des exigences et les étapes formelles comptent, laissez Spec Kit posséder le squelette de spécification et utilisez gstack pour les couches que Spec Kit n’impose pas – revue produit, revue de design, QA navigateur et livraison. Une comparaison plus large des configurations par spécification, incluant Kiro et Claude Code, est dans GitHub Spec Kit vs Kiro vs Claude Code SDD Workflows.

BMAD et Ruflo : des axes différents

BMAD est une méthodologie de développement piloté par l’IA plus large dont les flux de travail adaptatifs couvrent la réflexion produit, les spécifications, l’architecture et l’implémentation, en ajustant la cérémonie à la taille du travail. Il et gstack jouent tous deux le rôle de colonne vertébrale du processus, donc choisissez-en un comme colonne vertébrale plutôt que d’exécuter les deux en complet ; les compétences individuelles de gstack peuvent toujours être sélectionnées aux côtés d’une méthodologie.

Ruflo cible l’orchestration multi-agents : travailleurs coordonnés, mémoire partagée, essaims. gstack applique plusieurs perspectives spécialisées à un flux de travail d’ingénierie ; une plateforme d’orchestration applique plusieurs agents exécutants à un objectif d’ingénierie. La limite est floue – gstack peut appeler des outils externes et des modèles supplémentaires, et les orchestrateurs peuvent implémenter des rôles d’ingénierie structurés – mais la décision est indépendante : si le problème est que l’agent saute la discipline d’ingénierie, un framework de compétences est la correction directe ; si c’est d’exécuter dix agents simultanément à travers de nombreuses tâches et dépôts, un orchestrateur est au-dessus d’un flux de travail comme gstack plutôt que de le remplacer.

Compétences personnalisées : la couche la plus personnalisable

Vous pouvez aussi sauter le framework entièrement et créer une petite collection de compétences pour les procédures que votre équipe suit déjà :

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

Chaque compétence code des connaissances spécifiques à l’organisation qu’un framework générique ne peut pas connaître. Une compétence de migration de base de données peut exiger une analyse de rollback, une analyse de verrouillage de table, une revue de l’impact des index, une estimation de la durée de migration, un ordonnancement de déploiement et une compatibilité avec la version précédente de l’application ; une compétence de revue d’API peut exiger la compatibilité arrière, des vérifications d’authentification, la cohérence de la pagination, l’analyse d’idempotence, le comportement de limitation de débit et les changements OpenAPI. Une voie pratique : partez des compétences gstack que vous utilisez réellement, copiez leur structure dans votre propre répertoire skills/, et réécrivez les contrôles autour de vos conventions.

Quatre couches : Compétences, Spécifications, Méthodologies, Orchestrateurs

Quatre couches couvrent la plupart de ces outils, et elles montrent comment les combinaisons ci-dessus s’assemblent :

Les compétences répondent à « comment l’agent doit-il se comporter ? »

gstack, Superpowers, et les compétences d’agent personnalisées.

Les systèmes de spécification répondent à « qu’est-ce que nous construisons exactement ? »

OpenSpec et GitHub Spec Kit ; les concepts et la terminologie de base du développement par spécification sont définis dans Qu’est-ce que le développement par spécification ?.

Les méthodologies répondent à « comment le projet doit-il passer de l’idée au logiciel ? »

BMAD, Superpowers, et certaines parties de gstack.

Les orchestrateurs répondent à « comment plusieurs agents doivent-ils exécuter le travail ? »

Ruflo et d’autres runtimes multi-agents.

Les couches se composent ; un environnement de développement peut contenir les quatre :

gstack couvre déjà plusieurs de ces limites.

Devriez-vous utiliser gstack ?

Le README du projet décrit le public cible comme des fondateurs techniques et des CEO qui veulent toujours livrer, des utilisateurs de Claude Code pour la première fois qui veulent des rôles structurés au lieu d’un prompt vierge, et des responsables techniques et des ingénieurs staff qui veulent une revue rigoureuse, une QA et une automatisation de publication sur chaque PR. gstack vaut la peine d’être essayé si vous utilisez des agents de codage intensivement et que le facteur limitant n’est plus la génération de code elle-même. Symptômes typiques :

• l’agent commence à implémenter avant de comprendre le problème
• les plans d’implémentation manquent les implications d’architecture
• le code généré passe les tests mais échoue dans le navigateur
• les revues sont incohérentes entre les sessions
• les étapes de publication sont constamment oubliées
• différents développeurs promptent l’agent de manières complètement différentes
• des instructions d’ingénierie utiles restent enfouies dans les fichiers CLAUDE.md
• vous tapez manuellement les mêmes prompts de revue en répétition

Si votre automatisation fournit déjà des portes déterministes fortes et que l’agent ne gère que de petites tâches bien spécifiées, gstack n’ajoute presque rien.

gstack et la direction du développement logiciel IA

Le changement dans lequel gstack s’inscrit suit des générations : complétion de code (2022-2023), agents de codage (2024-2025), spécifications et flux de travail d’agent (2025-2026), et organisations d’ingénierie IA programmables. Les produits changeront, mais le modèle reste un composant ; la qualité d’ingénierie dépend de plus en plus du système environnant :

• spécifications persistantes
• compétences réutilisables
• connaissance du dépôt
• accès au navigateur
• tests
• outils déterministes
• boucles de revue
• contrôles de sécurité
• mémoire
• limites d’approbation humaine
• orchestration

Conclusion

gstack est le processus d’ingénierie autour d’un agent de codage, emballé en compétences inspectables et sous contrôle de version, et sa valeur réside dans le fait d’imposer ce processus à l’agent plutôt que dans n’importe quelle compétence individuelle.

Commencez par la séquence d’essai et ne gardez que les compétences qui méritent leur place. Au-delà, la direction est des couches composables – spécification, compétences, vérification déterministe, orchestration – chacune faisant ce que les autres ne peuvent pas.

Références

• Dépôt gstack – source, définitions de compétences et configuration
• Analyses approfondies des compétences gstack – philosophie, exemples et flux de travail pour chaque compétence
• Navigateur Aside – le navigateur que gstack pilote d’abord sur macOS
• Dépôt Superpowers – source, compétences et manifests de plugins
• Dépôt OpenSpec – source, docs et le package CLI
• Documentation GitHub Spec Kit – référence officielle du flux de travail Spec Kit
• Dépôt BMAD-METHOD – la méthodologie agile adaptative pilotée par l’IA
• Dépôt Ruflo – la plateforme d’orchestration multi-agents