Source: https://aiprimetech.io/fr/blog/gstack-claude-code-setup-guide/ Juil. 15, 2026 · 7 min · Outils # gstack pour Claude Code : ce que fait réellement son workflow à 23 agents A Par [AI Prime Tech](https://aiprimetech.io/fr/) · Avec l’aide de l’IA Une pull request portant sur 14 fichiers peut réussir les tests unitaires et pourtant échouer pour trois raisons entièrement différentes : le comportement du produit est insuffisamment spécifié, l’interface est peu pratique et les notes de version omettent une étape de migration. Exécuter Claude Code une seule fois avec « examine cette PR » condense ces préoccupations dans une seule conversation surchargée. gstack adopte une approche plus prescriptive. Ses 23 outils fondés sur des rôles répartissent la livraison logicielle entre la planification, la conception, l’implémentation, la revue, l’assurance qualité dans le navigateur, les travaux de mise en production et la documentation. Au lieu de demander à un assistant de développement généraliste d’improviser un processus, vous invoquez une succession de workflows Claude Code ciblés, tels que /plan-ceo-review, /plan-eng-review, /review, /qa, ainsi que /ship. Cette distinction est importante. gstack n’est pas simplement un répertoire de prompts utiles, et ses « 23 agents » ne sont pas 23 exécutants autonomes qui se coordonnent en permanence en arrière-plan. Ce sont des compétences Claude Code propres à des rôles, invoquées à des moments précis d’un workflow d’ingénierie. Leur valeur vient du mode de fonctionnement qu’elles imposent ; l’essentiel du surcroît de travail aussi. ## gstack pour Claude Code est un système d’exploitation, pas un pack de prompts Le modèle mental utile pour gstack pour Claude Code est celui d’un système d’exploitation pour l’ingénierie, superposé à Claude Code. Chaque outil donne à Claude un rôle, une procédure et des résultats attendus. Ensemble, ces outils codifient une vision de la manière dont un logiciel doit passer de l’idée à la production. Un prompt générique pourrait être : ``` Review my implementation plan. ``` Un workflow fondé sur des rôles pose une question plus ciblée : ``` /plan-eng-review ``` Cette compétence peut demander à Claude d’examiner l’architecture, les dépendances, les modes de défaillance, la testabilité, les risques de déploiement et l’ordre des étapes de mise en œuvre. Une compétence de planification orientée produit peut examiner le même plan sous l’angle de la valeur pour les utilisateurs et du périmètre. Une compétence orientée design peut remettre en question les détails des interactions plutôt que les frontières du backend. La différence tient à la répétabilité. Les membres de l’équipe n’ont pas chacun à mémoriser un prompt de revue de 40 lignes ni à inventer leur propre liste de contrôle. La compétence porte la procédure. La contrepartie est tout aussi importante : gstack introduit la procédure de quelqu’un d’autre dans votre dépôt. Il suppose que plusieurs passes de revue, une assurance qualité explicite et un travail de livraison structuré valent le contexte et le temps qu’ils consomment. C’est souvent pertinent pour des changements en production, mais excessif pour une faute de frappe ou un script interne de deux lignes. ## Ce que couvrent réellement les 23 outils fondés sur des rôles La liste exacte des outils du dépôt peut évoluer ; je considère donc les fichiers SKILL.md de la copie de travail comme la référence, plutôt que de me fier aux captures d’écran ou aux descriptions de lancement. L’essentiel de l’architecture réside dans la répartition des responsabilités. | Phase de livraison | Outils représentatifs | Ce qui est demandé à Claude | Limite principale | Planification produit | /plan-ceo-review, /office-hours | Remettre en question le problème, la valeur pour les utilisateurs, le périmètre et les hypothèses produit | Le jugement produit dépend toujours du contexte client fourni | Planification technique | /plan-eng-review | Examiner l’architecture, les flux de données, les cas limites, les tests et le déploiement | Impossible de valider les contraintes d’infrastructure non documentées | Design | /plan-design-review, /design-consultation | Examiner la structure des interactions, les choix visuels et l’utilisabilité | Le texte et les captures d’écran sont moins probants que l’observation de vrais utilisateurs | Encadrement de la mise en œuvre | /careful, outils de protection ou de gel | Limiter les modifications risquées et maintenir le travail dans les limites déclarées | Les contraintes peuvent ralentir des changements transversaux légitimes | Revue de code | /review | Examiner les diffs pour détecter les défauts, les régressions, les problèmes de sécurité et les tests manquants | Les diffs volumineux peuvent malgré tout dépasser la capacité d’attention disponible pour la revue | Assurance qualité à l’exécution | /qa, /browse | Tester l’application dans un navigateur et examiner son comportement réel | La configuration de l’environnement et les données de test déterminent la couverture | Version | /ship | Exécuter les vérifications de livraison et coordonner les étapes de commit ou de livraison | Les autorisations Git et de déploiement doivent être contrôlées de manière délibérée | Documentation | /document-release, /retro | Consigner le comportement livré, le contexte de la livraison et les enseignements tirés | Le texte généré doit être vérifié par rapport au système final C’est pourquoi qualifier gstack de « collection de prompts » minimise sa portée. Les résultats de la planification alimentent la mise en œuvre ; celle-ci produit un diff ; la revue et l’assurance qualité examinent ce diff ; la livraison et la documentation mettent en forme le résultat. C’est aussi pourquoi l’expression « workflow à 23 agents » peut être trompeuse. Lorsque vous invoquez une compétence, Claude Code charge en réalité des instructions et exécute le workflow associé à l’aide des outils disponibles dans la session en cours. Sauf si une compétence délègue explicitement du travail, il n’y a pas 23 processus persistants partageant un état global. ### La planification est volontairement redondante Les revues produit, technique et design se recoupent. C’est intentionnel. Prenons une proposition de fonctionnalité permettant d’« exporter toute l’activité des clients » : - La revue produit cherche à déterminer si les utilisateurs ont besoin d’un export complet ou d’un rapport filtré. - La revue technique cherche à déterminer si l’export peut tenir en mémoire et comment fonctionnent les nouvelles tentatives. - La revue design cherche à déterminer où apparaissent l’état de l’export, les échecs et les commandes de téléchargement. - L’assurance qualité examine ce qui se passe en l’absence d’enregistrements, avec des liens expirés et lors de traitements interrompus. En pratique, cette séparation permet de repérer des hypothèses qui passent inaperçues dans un plan de mise en œuvre générique. Son coût est le chargement répété du contexte. Si le plan compte déjà 8,000 tokens, trois passes de revue peuvent devenir coûteuses et produire des observations en double. ### La revue et l’assurance qualité sont deux tâches distinctes /review s’appuie principalement sur des éléments issus du code : diffs, types, tests, sites d’appel et conventions du dépôt. /qa et /browse peut recueillir des éléments observés à l’exécution dans l’application elle-même. Cette séparation est l’une des idées les plus solides de gstack. Un diff peut sembler correct alors que le résultat affiché est inutilisable. À l’inverse, une vérification du parcours nominal dans le navigateur peut réussir alors que la mise en œuvre introduit une condition de concurrence ou un contournement des autorisations. Une séquence pratique ressemble à ceci : ``` /plan-eng-review /careful # Implement the approved plan in Claude Code /review /qa /document-release /ship ``` Ne considérez pas cela comme un pipeline obligatoire. Pour une migration de base de données, la revue technique et la planification du retour arrière peuvent compter bien davantage que le design visuel. Pour une régression CSS, /browse, la revue design et l’assurance qualité peuvent constituer le cœur du workflow. ## Installer gstack sans lui faire aveuglément confiance Une installation classique au niveau utilisateur place le dépôt dans le répertoire des compétences de Claude Code et exécute son script de configuration : ``` git clone https://github.com/garrytan/gstack.git \ ~/.claude/skills/gstack cd ~/.claude/skills/gstack ./setup ``` Redémarrez Claude Code après la configuration si les nouvelles commandes ne sont pas détectées immédiatement. Examinez ensuite les compétences installées plutôt que de supposer que le nombre publié correspond toujours à votre copie de travail : ``` find ~/.claude/skills/gstack \ -name SKILL.md \ -print | sort find ~/.claude/skills/gstack \ -name SKILL.md | wc -l ``` Un piège courant consiste à exécuter des scripts d’installation parce que le dépôt est populaire, sans lire ce qu’ils modifient. gstack comprend des mécanismes de workflow exécutables, pas du Markdown inerte. Avant de lancer la configuration, examinez le script : ``` cd ~/.claude/skills/gstack git status --short git log -1 --oneline sed -n '1,240p' setup ``` Pour un déploiement au sein d’une équipe, fixez un commit ayant fait l’objet d’une revue au lieu de suivre silencieusement le dernier état du dépôt : ``` git clone https://github.com/garrytan/gstack.git vendor/gstack cd vendor/gstack git checkout ./setup ``` La procédure d’installation exacte et les dépendances peuvent changer à mesure que le projet évolue. Le README actuel du dépôt et son script de configuration doivent donc primer sur les commandes copiées d’un article plus ancien, y compris celui-ci. ## Encadrer le workflow avec les autorisations de Claude Code Certains outils de gstack ont besoin d’un accès étendu pour examiner les fichiers, exécuter les tests, piloter un navigateur ou interagir avec Git. Cela ne signifie pas que chaque outil doit recevoir des autorisations illimitées pour le shell et les livraisons. Un fichier au niveau du projet .claude/settings.json peut établir une base prudente : ``` { "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:*)" ] } } ``` Considérez cela comme un exemple de politique, et non comme un fichier universel prêt à l’emploi. Adaptez les commandes à votre gestionnaire de paquets, à votre outil d’exécution des tests et à votre version de Claude Code. Le refus explicite de git push est particulièrement utile pendant l’évaluation. /ship peut toujours vérifier si la livraison est prête, mais l’humain garde la maîtrise de l’action finale sur le réseau. Une fois que l’équipe comprend le workflow, vous pouvez décider si une autorisation de push strictement limitée se justifie. Testez également les compétences orientées navigateur dans un environnement de préproduction ou avec des données locales préchargées. L’automatisation du navigateur dans une session de production peut modifier de vrais enregistrements si le workflow clique sur une commande destructive. ## Adopter un sous-ensemble avant d’adopter le système Je ne présenterais pas les 23 outils à une équipe dès le premier jour. Commencez par les étapes où votre processus existant perd le plus d’informations. Voici une matrice d’évaluation raisonnable : | Problème de l’équipe | Commencer par | Reporter dans un premier temps | Les plans négligent les cas limites | /plan-eng-review | Séquence complète de design et de livraison | Les changements d’interface entraînent des régressions silencieuses | /browse, /qa, /plan-design-review | Workflows de stratégie produit | Les revues manquent de cohérence | /review | Livraison automatisée | Les livraisons manquent de contexte | /document-release, /retro | Outils de navigateur | Claude modifie trop largement le code | /careful et contrôles du périmètre | Adoption du workflow de bout en bout Utilisez ce sous-ensemble sur plusieurs changements réels et consignez les éléments suivants : - Quels constats ont entraîné des modifications du code ou du périmètre ? - Quels constats faisaient doublon ? - Quelle quantité de contexte a dû être répétée ? - Les artefacts générés sont-ils restés synchronisés avec la mise en œuvre ? - Quelles commandes ont nécessité des autorisations que l’équipe n’accorderait pas en CI ? - Les développeurs savaient-ils quand invoquer chaque rôle ? Le surcoût lié au contexte n’est pas théorique. Chaque rôle a besoin de l’état du dépôt, des exigences et des décisions précédentes. Des sessions séparées peuvent perdre les raisons des choix ; une longue session peut accumuler des hypothèses obsolètes. Je conserve le plan approuvé dans un fichier du dépôt tel que docs/plans/export-jobs.md, puis je demande à chaque workflow d’utiliser cet artefact. Les fichiers persistants sont plus fiables que l’espoir de voir le contexte conversationnel servir de mémoire au projet. ## Comportement documenté et affirmations promotionnelles L’affirmation défendable est que gstack fournit 23 outils Claude Code orientés rôles et un workflow prescriptif couvrant le cycle de vie du logiciel. Vous pouvez vérifier ce comportement en lisant les compétences installées et en les exécutant dans un dépôt de test. Des affirmations plus larges, comme produire considérablement plus, remplacer une équipe d’ingénierie ou ramener des semaines de travail à quelques heures, restent promotionnelles tant qu’elles n’ont pas été démontrées dans votre environnement. Les résultats dépendent de la qualité du dépôt, de la couverture des tests, de l’ambiguïté de la tâche, du choix du modèle, des autorisations et du développeur qui supervise le travail. La gamme actuelle de modèles ne supprime pas non plus ces contraintes. Sonnet 4.6 peut être un choix par défaut pratique pour un travail de développement soutenu, tandis que Haiku 4.5 peut convenir à des tâches plus légères de classification ou de documentation. Le contexte de 1M de Fable 5 peut être utile pour de très grands volumes de contenu, et gpt-5.6-sol offre une autre option orientée ingénierie dans les environnements pris en charge. Aucun de ces modèles ne transforme un prompt de rôle en connaissance produit vérifiée ou en éléments probants issus de la production. ## Conseils pratiques - Considérez gstack comme un processus de développement prescriptif mis en œuvre au moyen des compétences de Claude Code. - Comprenez « 23 agents » comme des outils fondés sur des rôles, et non comme des exécutants persistants automatiquement coordonnés. - Installez depuis le dépôt, inspectez setup, et épinglez un commit validé après revue pour une utilisation en équipe. - Commencez par deux ou trois workflows qui répondent à des problèmes de livraison connus. - Conservez les plans et les décisions approuvés dans des fichiers afin que les rôles partagent un contexte durable. - Séparez la revue de code de l’assurance qualité à l’exécution ; elles détectent des catégories de défaillances différentes. - Limitez l’accès aux secrets, aux sessions de production, aux envois Git et aux commandes de déploiement pendant l’évaluation. - Mesurez les constats utiles et les défauts évités, pas le nombre de commandes exécutées. - N’adoptez le système de fonctionnement complet que lorsque le coût de ses processus est inférieur à celui des défaillances qu’il évite. [Développement](/fr/blog/tag/coding/)[Claude](/fr/blog/tag/claude/)[Agents](/fr/blog/tag/agents/)[Modèles](/fr/blog/tag/models/) A [AI Prime Tech](https://aiprimetech.io/fr/) Ce blog est publié par AI Prime Tech. Les articles sont rédigés avec l’aide de l’IA ; vérifiez les détails propres à chaque version, tels que les identifiants de modèles, les prix et les limites, dans la documentation officielle avant de vous y fier. Accédez à l’API Claude à moindre coût Une seule clé API pour Claude Opus 5.5, Sonnet 5, Haiku 4.5 et Fable 5.1, ainsi que GPT-6 modèles. Paiement à l’usage, sans abonnement. [Obtenir votre clé API →](/register) AI Prime Tech est une passerelle API tierce indépendante. Claude™ et Anthropic® sont des marques d’Anthropic, PBC. Aucune affiliation ni approbation n’est sous-entendue.