Guide pratique de GSD

Introduction

Dans l'article précédent, nous avons exploré en profondeur les principes fondamentaux de GSD — l'ingénierie de contexte, l'orchestration de sous-agents, la planification par objectifs inversés et les commits atomiques. Ces concepts semblent élégants, mais entre « comprendre la théorie » et « mener un projet à bien », il reste de nombreux détails opérationnels à maîtriser.

Dans cet article, nous passons à la pratique. Vous apprendrez le système complet de commandes de GSD, les options de configuration, la structure des fichiers produits, ainsi que la manière de l'utiliser pour livrer une fonctionnalité complète de A à Z.

Installation et configuration

Installation

npx get-shit-done-cc@latest

L'installateur vous demandera de choisir :

1. Environnement d'exécution — Claude Code, OpenCode, Gemini CLI ou tous
2. Portée — Globale (tous les projets) ou locale (projet actuel)

Après l'installation, saisissez /gsd:help dans votre environnement d'exécution pour vérifier que l'installation a réussi.

Recommandé : mode sans permissions

GSD est conçu pour une automatisation sans friction. Il est recommandé de lancer Claude Code de la manière suivante :

claude --dangerously-skip-permissions

Si vous préférez ne pas utiliser ce drapeau, vous pouvez configurer des permissions granulaires dans .claude/settings.json.

Mise à jour

/gsd:update

GSD est mis à jour très fréquemment (TÂCHES pousse environ 15 à 20 mises à jour par jour). Il est recommandé d'exécuter cette commande régulièrement pour rester à jour.

Référence complète des commandes

Toutes les interactions avec GSD se font via des commandes préfixées par /gsd:. Voici la liste complète, classée par fonctionnalité.

Commandes du flux de travail principal

Ces cinq commandes constituent la boucle principale de GSD. Elles s'utilisent dans l'ordre.

[N] indique un paramètre optionnel — en cas d'omission, le système détecte automatiquement la phase en cours. <N> indique un paramètre obligatoire.

Gestion des jalons

Gestion des phases

Quick Mode et outils

Gestion de session et configuration

Configuration détaillée

Profils de modèle

GSD propose trois profils de modèle, que vous pouvez changer via /gsd:set-profile :

Paramètres principaux

Affichez et modifiez les paramètres suivants via /gsd:settings :

Interrupteurs de flux de travail

Les agents suivants peuvent être activés ou désactivés individuellement, pour ajuster le compromis entre vitesse et qualité :

Désactiver research et plan_check peut accélérer considérablement le processus, mais risque de réduire la qualité de la planification. Il est recommandé de ne les désactiver qu'après avoir acquis une bonne connaissance du projet.

Structure des fichiers produits

Tous les états et fichiers produits par GSD sont enregistrés dans le répertoire .planning/. Comprendre cette structure vous aidera pour le débogage et les interventions manuelles.

Fichiers au niveau du projet

Fichiers au niveau de la phase

Chaque phase produit les fichiers suivants (exemple avec la phase 1) :

Exemple de structure de répertoire

.planning/
├── PROJECT.md
├── REQUIREMENTS.md
├── ROADMAP.md
├── STATE.md
├── research/
│   ├── tech-stack.md
│   ├── features.md
│   ├── architecture.md
│   └── pitfalls.md
├── 01-CONTEXT.md
├── 01-RESEARCH.md
├── 01-01-PLAN.md
├── 01-02-PLAN.md
├── 01-01-SUMMARY.md
├── 01-02-SUMMARY.md
├── 01-VERIFICATION.md
├── 01-UAT.md
├── 02-CONTEXT.md
├── 02-RESEARCH.md
├── 02-01-PLAN.md
│   ...
└── todos.md

Démonstration d'un flux de travail concret

L'exemple suivant illustre le processus complet, de l'initialisation à la livraison, en prenant comme cas « l'ajout d'une fonctionnalité de commentaires à un système de blog ».

Étape 1 : Initialiser le projet

/gsd:new-project

Le système commence à poser des questions successives :

> Que souhaitez-vous construire ?
"Je veux ajouter une fonctionnalité de commentaires à mon blog Next.js.
 Avec support des commentaires anonymes et authentifiés,
 rendu Markdown et panneau d'administration.
 Pile technique : Prisma + PostgreSQL."

Plus votre description est détaillée, moins le système aura besoin de poser de questions complémentaires. TÂCHES recommande de préparer un document de vision sommaire décrivant ce que vous voulez — pas besoin de connaître les détails techniques.

Une fois terminé, le système produit quatre fichiers et vous demande d'approuver la feuille de route. Après approbation, la phase de construction commence.

Vous avez déjà une base de code ? Exécutez d'abord /gsd:map-codebase : le système analysera votre architecture et vos conventions existantes, et new-project pourra ensuite planifier en s'appuyant sur le code déjà en place.

Étape 2 : Discuter de la phase

/gsd:discuss-phase 1

Le système identifie les zones grises et les aborde une par une :

> Imbrication des commentaires : supporter plusieurs niveaux ou seulement un niveau de réponse ?
> Commentaires anonymes : avec captcha ou soumission directe ?
> Panneau d'administration : opérations en lot ou modération individuelle ?

Chaque décision que vous prenez ici influence directement la qualité de la planification ultérieure. En cas de doute, vous pouvez laisser le système utiliser les valeurs par défaut — mais une discussion approfondie réduit considérablement les reprises lors de la phase d'exécution.

Étape 3 : Planifier la phase

/gsd:plan-phase 1

Le système va :

1. Rechercher comment implémenter un système de commentaires avec Prisma + PostgreSQL
2. Créer 2 à 3 plans de tâches atomiques (par exemple : modèle de données, routes API, composants front-end)
3. Vérifier automatiquement que le plan couvre toutes les exigences

Chaque plan est suffisamment petit pour être réalisé dans une fenêtre de contexte entièrement nouvelle.

Étape 4 : Exécuter la phase

/gsd:execute-phase 1

Le système lance l'exécution par vagues :

• Vague 1 (sans dépendances) : schéma de base de données, modèles Prisma — exécution en parallèle
• Vague 2 (dépend de la vague 1) : routes API, CRUD des commentaires — exécution en parallèle
• Vague 3 (dépend de la vague 2) : composant front-end de commentaires — exécution indépendante

Chaque tâche s'exécute dans un contexte neuf de 200k tokens et fait l'objet d'un commit Git indépendant à la fin.

Étape 5 : Vérifier les livrables

/gsd:verify-work 1

Le système vous guide pour confirmer chaque élément :

> ✅ Les tables de base de données ont été créées
> ✅ Les routes API retournent les codes de statut corrects
> ❓ Voyez-vous la zone de saisie de commentaire sous l'article de blog ? [oui/non/décrire le problème]
> ❓ La page se met-elle à jour en temps réel après la soumission d'un commentaire ? [oui/non/décrire le problème]

En cas d'échec, le système diagnostique automatiquement le problème et crée un plan de correction. Il vous suffit de relancer /gsd:execute-phase 1 pour appliquer les correctifs.

Scénarios courants

Insérer une phase urgente : un changement de besoin nécessite l'insertion d'un nouveau travail avant la phase actuelle.

/gsd:insert-phase 2

Les phases suivantes sont automatiquement renumérotées (l'ancienne phase 2 devient la phase 3, et ainsi de suite).

Mettre en pause et reprendre : vous devez interrompre le travail pour traiter autre chose.

/gsd:pause-work    # Sauvegarde l'état actuel
# ... traiter autre chose ...
/gsd:resume-work   # Reprendre là où vous vous étiez arrêté

Annuler un résultat insatisfaisant :

git reset --hard HEAD~3    # Revenir à l'état précédant l'exécution

/gsd:remove-phase 2        # Supprimer en cascade tous les fichiers produits de cette phase

TÂCHES a démontré cette opération plusieurs fois en direct — quand le résultat ne lui convient pas, il annule. Net et sans bavure.

Flux de travail de débogage

Lorsque la vérification révèle un problème, ou que vous rencontrez un bug en cours de développement, GSD fournit un processus de débogage dédié.

/gsd:debug La page ne se met pas à jour en temps réel après la soumission d'un commentaire

Le système lance un sous-agent de débogage isolé dont le processus est le suivant :

1. Hypothèses — Génère plusieurs hypothèses de causes racines à partir de la description du problème
2. Collecte de preuves — Vérifie chaque hypothèse en examinant le code, les journaux et les requêtes réseau
3. Résolution — Une fois la cause racine identifiée, crée un plan de correction

Caractéristiques clés :

• Isolation du contexte : l'agent de débogage dispose de sa propre fenêtre de contexte et ne pollue pas le contexte de développement principal
• Traçabilité documentée : crée un document de débogage indépendant retraçant l'ensemble de l'investigation
• Plan de correction : une fois le diagnostic terminé, produit un plan de correction prêt à être exécuté

Cette approche est bien plus efficace que de déboguer directement dans le contexte principal — les informations de débogage ne s'accumulent pas dans votre fenêtre principale.

Retours d'expérience

En combinant les démonstrations en direct de TÂCHES et l'expérience d'utilisation de Chase AI, voici quelques recommandations pratiques.

Ralentir pour aller plus vite

TÂCHES admet que lorsqu'il a commencé à utiliser GSD, il avait un état d'esprit « vite, vite, vite ». Mais il a découvert que passer plus de temps en phase de recherche et de discussion réduit les reprises en phase d'exécution. La nouvelle version de GSD a ajouté les étapes research-project et define-requirements précisément pour s'assurer de bien cadrer la direction avant de passer à l'action.

"I was definitely when I first started doing things with GSD, I was very much like move fast, move fast, move fast. But I'm just finding that taking these extra steps... I think you're going to really really love to see the results."

—— TÂCHES

Purger le contexte entre les phases

L'habitude de TÂCHES est d'exécuter clear entre chaque phase, pour garder le contexte principal épuré. Il utilise le terminal Warp, chaque fenêtre en plein écran (Command+Shift+Enter), exécutant la phase en cours dans une fenêtre tout en préparant la phase suivante dans une autre.

Le compromis du coût en tokens

L'approche par sous-agents de GSD consomme effectivement plus de tokens qu'une utilisation directe de Claude Code. Mais Chase AI avance un argument convaincant : « plan twice, prompt once » (planifier deux fois, prompter une fois) est plus économique à long terme que « prompter une fois, puis corriger encore et encore ». Car réussir du premier coup dans un contexte neuf est bien plus efficace que de corriger indéfiniment dans un contexte dégradé.

Gérer les résultats insatisfaisants

Si vous n'êtes pas satisfait du résultat d'une phase, vous pouvez exécuter git reset --hard puis utiliser /gsd:remove-phase pour supprimer en cascade tous les fichiers produits de cette phase. TÂCHES a démontré cette opération en direct — un rendu visuel ne lui convenait pas, il est simplement revenu à l'état précédent satisfaisant. Net et sans bavure.

Le système de tâches

/gsd:add-todo vous permet d'enregistrer des idées dans une liste de tâches à tout moment, sans modifier la feuille de route. Ces idées peuvent être reprises lors de /gsd:discuss-milestone comme données d'entrée pour le prochain jalon. La stratégie de TÂCHES est « d'abord les fonctionnalités, le peaufinage de l'interface au milestone 2 ».

Questions fréquentes et bonnes pratiques

Bonnes pratiques

Fournissez une description initiale détaillée. La qualité de /gsd:new-project dépend de la qualité de vos données d'entrée. Préparez un document de vision sommaire — décrivez les objectifs, les utilisateurs, les fonctionnalités clés et les contraintes connues. Plus la description est précise, moins le système posera de questions et plus la planification sera pertinente.

Nettoyez le contexte entre les phases. Après chaque phase, exécutez clear ou /compact pour garder la fenêtre de contexte principale épurée. L'habitude de TÂCHES est de maintenir le contexte principal à 30-40 %.

Testez d'abord avec le Quick Mode. Pour les petites fonctionnalités dont vous n'êtes pas certain, testez d'abord avec /gsd:quick. Si le résultat est concluant, intégrez-le dans la feuille de route officielle.

Exécutez map-codebase sur un projet existant. Avant d'utiliser GSD sur une base de code existante, exécutez /gsd:map-codebase. Le système analysera la pile technique, l'architecture et les conventions, et la planification ultérieure sera mieux adaptée au code existant.

FAQ

Q : Quels environnements d'exécution GSD prend-il en charge ?

R : Claude Code, OpenCode et Gemini CLI. Vous pouvez en choisir un ou tous lors de l'installation.

Q : Quelle est la différence entre le Quick Mode et le mode complet ?

R : Le Quick Mode fournit les garanties de base de GSD (commits atomiques, suivi d'état), mais ignore les étapes de recherche, de vérification du plan et de validation. Il est adapté aux corrections de bugs, aux petites fonctionnalités et aux modifications de configuration qui ne nécessitent pas une planification complète.

Q : Peut-on mettre en pause pendant l'exécution ?

R : Oui. /gsd:pause-work sauvegarde l'état actuel dans STATE.md. Lors du prochain /gsd:resume-work, le système reprendra là où vous vous étiez arrêté.

Q : Comment contrôler le coût en tokens ?

R : Trois approches — (1) Passer au profil budget : /gsd:set-profile budget ; (2) Désactiver les agents research ou plan_check ; (3) Utiliser /gsd:quick pour les tâches simples.

Q : Peut-on utiliser GSD avec Ralph ?

R : Oui. GSD et Ralph répondent à des problématiques différentes — GSD gère la planification et l'exécution structurée, Ralph gère les boucles d'exécution autonomes. Vous pouvez utiliser new-project et plan-phase de GSD pour générer un plan complet, puis utiliser les boucles Ralph pour exécuter les phases qui ne nécessitent pas d'intervention humaine.

Q : Comment gérer la collaboration en équipe ?

R : Le répertoire .planning/ peut être versionné dans Git. Plusieurs personnes peuvent exécuter différentes phases et fusionner les résultats via Git. Toutefois, il est recommandé d'éviter d'exécuter la même phase simultanément.

Conclusion

La valeur fondamentale de GSD réside dans le fait de cacher la complexité dans le système et de laisser la simplicité à l'utilisateur. Vous n'avez besoin que de quelques commandes — new-project, discuss-phase, plan-phase, execute-phase, verify-work — et le système gère en coulisses toute la gestion de contexte, l'orchestration des sous-agents et la vérification de la qualité.

De l'installation à la livraison, GSD offre un chemin clair : décrire ce que vous voulez → discuter des détails d'implémentation → générer des plans atomiques → exécuter en parallèle → vérifier les livrables. À chaque étape, vous avez la possibilité d'intervenir, et chaque étape est documentée.

Ce n'est pas de la magie « un bouton et c'est fait ». C'est un système qui requiert votre participation tout en prenant en charge la majeure partie de la charge cognitive. Comme le dit TÂCHES : vous êtes le chef de projet, GSD est votre équipe d'exécution.

Pour aller plus loin :

• Analyse approfondie de GSD — Principes fondamentaux, flux de travail et architecture technique
• Analyse approfondie de Ralph Wiggum — Context Rot et la méthodologie Ralph
• Guide pratique de snarktank/ralph — Installation de Ralph, rédaction de PRD et mise en pratique
• Qu'est-ce que le développement piloté par les spécifications — Du Vibe Coding au développement piloté par les spécifications
• Guide pratique de Speckit — Détail des commandes Speckit et cas d'usage complet