GSD (Get Shit Done) : structurer Claude Code comme un vrai projet

Quand on laisse Claude Code coder seul pendant une heure, les 20 premières minutes sont brillantes. Puis la qualité se dégrade. Le modèle oublie les exigences initiales, prend des raccourcis, commence à halluciner sur l’architecture. C’est le context rot : au-delà de 50% de la fenêtre de contexte remplie, le modèle perd le fil.

GSD (Get Shit Done) résout ce problème avec une idée simple : chaque tâche est exécutée par un agent frais qui dispose de 200k tokens de contexte propre. La tâche numéro 50 a la même qualité que la tâche numéro 1.

22k+ stars sur GitHub, adopté par des ingénieurs chez Amazon, Google, Shopify. Ce n’est pas un wrapper cosmétique autour de Claude : c’est une vraie chaîne de production logicielle.

1 Le problème que GSD résout

Par défaut, Claude Code travaille dans une seule session. Plus on avance, plus le contexte se remplit de code, de résultats de recherche, de décisions prises. Résultat :

0-30% du contexte : qualité optimale, le modèle est précis
50%+ : il commence à bâcler, saute des étapes
70%+ : hallucinations, exigences oubliées, stubs au lieu de vraie implémentation

La solution classique : faire /clear et relancer. Mais on perd tout le contexte, et il faut ré-expliquer le projet. GSD automatise cette rotation de contexte en découpant le travail en phases, plans et tâches, chacun exécuté par un agent spécialisé avec un contexte neuf.

2 Le cycle de vie complet

flowchart TB
    NEW["/gsd:new-project<br/>Questions, recherche, roadmap"] --> PHASE

    subgraph PHASE["Pour chaque phase"]
        direction TB
        DISC["/gsd:discuss-phase<br/>Verrouiller les préférences"] --> PLAN
        PLAN["/gsd:plan-phase<br/>Recherche + Plan + Vérification"] --> EXEC
        EXEC["/gsd:execute-phase<br/>Exécution parallèle par vagues"] --> VERIFY
        VERIFY["/gsd:verify-work<br/>UAT manuelle"]
    end

    PHASE --> AUDIT["/gsd:audit-milestone"]
    AUDIT --> COMPLETE["/gsd:complete-milestone"]
    COMPLETE --> NEXT{Autre milestone ?}
    NEXT -->|Oui| MILE["/gsd:new-milestone"]
    MILE --> PHASE
    NEXT -->|Non| DONE["Terminé"]

Figure 1: Cycle de vie d’un projet GSD

Le modèle est linéaire par design. On ne saute pas d’étape, on ne mélange pas planification et exécution. Chaque commande lit les fichiers d’état du projet (.planning/) et sait exactement où on en est.

3 L’architecture des agents

C’est là que GSD se distingue des autres frameworks. Le travail est distribué entre des agents spécialisés, chacun avec un rôle précis et un contexte frais.

3.1 La phase de planification

flowchart TB
    CMD["/gsd:plan-phase N"] --> RES

    subgraph RES["4 chercheurs en parallèle"]
        R1["Stack"] & R2["Features"] & R3["Architecture"] & R4["Pièges"]
    end

    RES --> RESEARCH["RESEARCH.md"]
    RESEARCH --> PLANNER["Planner<br/>Lit PROJECT.md, REQUIREMENTS.md,<br/>CONTEXT.md, RESEARCH.md"]
    PLANNER --> PLAN["Plans de tâches"]
    PLAN --> CHECKER["Plan Checker"]
    CHECKER -->|Rejeté| PLANNER
    CHECKER -->|Approuvé| FILES["Fichiers PLAN finaux"]

Figure 2: Coordination des agents pendant plan-phase

Quatre chercheurs indépendants investiguent en parallèle : le stack technique, les features à implémenter, l’architecture cible, et les pièges connus. Leurs résultats convergent dans un RESEARCH.md que le planner utilise pour produire des plans atomiques.

Le plan checker est le garde-fou. Il vérifie 8 dimensions (dont la couverture de tests automatisés via le “Nyquist layer”) et peut rejeter un plan jusqu’à 3 fois avant approbation.

3.2 L’exécution par vagues

flowchart TB
    CMD2["/gsd:execute-phase N"] --> DEPS["Analyse des dépendances"]
    DEPS --> W1

    subgraph W1["Vague 1 : tâches indépendantes"]
        E1["Executor A<br/>200k contexte frais"] --> C1["commit"]
        E2["Executor B<br/>200k contexte frais"] --> C2["commit"]
    end

    W1 --> W2

    subgraph W2["Vague 2 : dépend de Vague 1"]
        E3["Executor C<br/>200k contexte frais"] --> C3["commit"]
    end

    W2 --> VERIF["Verifier<br/>Check codebase vs objectifs"]
    VERIF -->|PASS| OK["VERIFICATION.md"]
    VERIF -->|FAIL| ISSUES["Issues pour /gsd:verify-work"]

Figure 3: Exécution par vagues avec contexte frais

Chaque executor reçoit un contexte neuf de 200k tokens avec uniquement les fichiers pertinents à sa tâche. Pas de pollution croisée entre les exécuteurs. Un commit atomique par tâche terminée.

4 Le Nyquist Layer : la validation intégrée

Avant même d’écrire une ligne de code, GSD mappe la couverture de tests automatisés pour chaque exigence de la phase. Le chercheur détecte l’infrastructure de tests existante, associe chaque requirement à une commande de test spécifique, et identifie les scaffoldings à créer avant l’implémentation (tâches “Wave 0”).

Le plan checker l’impose comme 8ème dimension de vérification : un plan dont les tâches n’ont pas de commande verify automatisée ne sera pas approuvé.

Prototypage rapide

Pour les phases exploratoires où l’infrastructure de tests n’est pas la priorité, désactiver avec workflow.nyquist_validation: false dans /gsd:settings.

5 Référence des commandes

5.1 Workflow principal

Commande	Rôle
`/gsd:new-project`	Init complète : questions, recherche, requirements, roadmap
`/gsd:new-project --auto @idea.md`	Init automatique à partir d’un document
`/gsd:discuss-phase [N]`	Capturer les décisions d’implémentation
`/gsd:plan-phase [N]`	Recherche + plan + vérification
`/gsd:execute-phase <N>`	Exécuter tous les plans en vagues parallèles
`/gsd:verify-work [N]`	UAT manuelle avec diagnostic auto
`/gsd:audit-milestone`	Vérifier la definition of done du milestone
`/gsd:complete-milestone`	Archiver le milestone, taguer la release
`/gsd:new-milestone [name]`	Démarrer le cycle suivant

5.2 Navigation et reprise

Commande	Rôle
`/gsd:progress`	Statut et prochaines étapes
`/gsd:resume-work`	Restaurer le contexte de la dernière session
`/gsd:pause-work`	Sauvegarder le contexte pour plus tard
`/gsd:quick`	Tâche ad-hoc avec les garanties GSD
`/gsd:debug [desc]`	Debugging systématique avec état persistant

5.3 Gestion de scope

Commande	Rôle
`/gsd:add-phase`	Ajouter une phase à la roadmap
`/gsd:insert-phase [N]`	Insérer du travail urgent (numérotation décimale)
`/gsd:remove-phase [N]`	Supprimer une phase future et renuméroter
`/gsd:list-phase-assumptions [N]`	Voir les intentions de Claude avant planification
`/gsd:plan-milestone-gaps`	Créer des phases pour les lacunes d’audit

5.4 Brownfield (codebase existante)

Commande	Rôle
`/gsd:map-codebase`	Analyser le code existant en parallèle

Produit 4 fichiers dans .planning/codebase/ : STACK.md, ARCHITECTURE.md, CONVENTIONS.md, CONCERNS.md. Ensuite /gsd:new-project se concentre sur ce qu’on ajoute, pas sur ce qui existe.

6 Configuration

GSD stocke tout dans .planning/config.json. Les réglages clés :

6.1 Profils de modèles

Agent	`quality`	`balanced`	`budget`
Planner	Opus	Opus	Sonnet
Roadmapper	Opus	Sonnet	Sonnet
Executor	Opus	Sonnet	Sonnet
Phase Researcher	Opus	Sonnet	Haiku
Verifier	Sonnet	Sonnet	Haiku
Plan Checker	Sonnet	Sonnet	Haiku

Le profil balanced (par défaut) met Opus uniquement sur le planner, là où les décisions d’architecture comptent. Tout le reste tourne sur Sonnet. Le profil budget passe les chercheurs et vérificateurs sur Haiku pour réduire les coûts.

/gsd:set-profile budget    # Switch rapide
/gsd:settings              # Configuration détaillée

6.2 Toggles de workflow

Réglage	Par défaut	Effet
`workflow.research`	`true`	Investigation avant planification
`workflow.plan_check`	`true`	Boucle de vérification des plans (jusqu’à 3 itérations)
`workflow.verifier`	`true`	Vérification post-exécution
`workflow.nyquist_validation`	`true`	Mapping de tests automatisés pendant la planification

Désactiver ces agents pour les domaines familiers ou quand le budget tokens est limité.

6.3 Stratégies Git

Stratégie	Crée une branche	Quand l’utiliser
`none`	Jamais	Dev solo, projets simples
`phase`	À chaque `execute-phase`	Review de code par phase, rollback granulaire
`milestone`	Au premier `execute-phase`	Branches de release, une PR par version

7 Presets selon le contexte

Scénario	Mode	Profondeur	Profil	Research	Plan Check	Verifier
Prototypage	`yolo`	`quick`	`budget`	off	off	off
Dev normal	`interactive`	`standard`	`balanced`	on	on	on
Production	`interactive`	`comprehensive`	`quality`	on	on	on

Le mode yolo auto-approve toutes les décisions. Utile pour avancer vite sur un prototype, mais ne pas l’utiliser sur du code destiné à la production.

8 Structure des fichiers

.planning/
  PROJECT.md              # Vision et contexte (toujours chargé)
  REQUIREMENTS.md         # Exigences scopées v1/v2 avec IDs
  ROADMAP.md              # Phases avec suivi de statut
  STATE.md                # Décisions, bloqueurs, mémoire de session
  config.json             # Configuration workflow
  research/               # Recherche domaine
  codebase/               # Mapping brownfield
    STACK.md
    ARCHITECTURE.md
    CONVENTIONS.md
    CONCERNS.md
  phases/
    XX-phase-name/
      XX-YY-PLAN.md       # Plans d'exécution atomiques
      XX-YY-SUMMARY.md    # Résultats et décisions
      CONTEXT.md           # Préférences d'implémentation
      RESEARCH.md          # Recherche écosystème
      VERIFICATION.md      # Résultats de vérification

PROJECT.md est le fichier le plus important. Il est chargé dans le contexte de chaque agent. C’est la source de vérité sur le “quoi” et le “pourquoi” du projet.

9 En pratique : un cycle complet

# 1. Initialiser
/gsd:new-project
# Répondre aux questions, configurer, approuver la roadmap

/clear

# 2. Phase par phase
/gsd:discuss-phase 1        # Verrouiller les choix
/gsd:plan-phase 1           # Les agents recherchent et planifient
/gsd:execute-phase 1        # Exécution parallèle
/gsd:verify-work 1          # Vérifier le résultat

/clear

# Répéter pour chaque phase...

# 3. Clôture
/gsd:audit-milestone        # Vérifier que tout est livré
/gsd:complete-milestone     # Archiver, taguer, terminé

Le /clear entre les phases est important. Il libère le contexte de la session principale. Chaque sous-agent a déjà son propre contexte frais ; le /clear garantit que l’orchestrateur aussi repartit propre.

Plans trop ambitieux

Si l’exécution produit des stubs ou du code incomplet, le plan était probablement trop gros. GSD recommande 2-3 tâches par plan maximum. Au-delà, un seul contexte ne suffit pas pour produire du code fiable.

10 Brownfield : intégrer un projet existant

/gsd:map-codebase           # 4 agents analysent en parallèle
/gsd:new-project            # Les questions ciblent ce qu'on ajoute

Le mapping produit une radiographie du code existant. Quand on lance ensuite /gsd:new-project, les questions portent sur les nouvelles features, pas sur la compréhension du stack. Les agents de planification et d’exécution ont accès aux fichiers de mapping pour respecter les conventions en place.

11 Troubleshooting

“Project already initialized” : .planning/PROJECT.md existe déjà. Supprimer le répertoire .planning/ pour recommencer.

La qualité se dégrade en cours de session : faire /clear puis /gsd:resume-work ou /gsd:progress. GSD est conçu autour de contextes frais ; la session principale est juste l’orchestrateur.

Les plans semblent mal alignés : utiliser /gsd:discuss-phase avant de planifier. La majorité des problèmes de qualité viennent de Claude qui fait des hypothèses que CONTEXT.md aurait corrigées. /gsd:list-phase-assumptions permet de vérifier ses intentions avant de s’engager.

L’exécution produit des stubs : le plan était trop ambitieux. 2-3 tâches max par plan. Re-planifier avec un scope plus petit.

Coûts trop élevés : /gsd:set-profile budget et désactiver les agents de recherche/vérification via /gsd:settings pour les domaines familiers.

Un subagent semble échouer mais le travail est fait : bug connu de classification dans Claude Code. GSD vérifie la sortie réelle avant de reporter un échec. Checker git log pour confirmer.

12 Ce qui le distingue des autres frameworks

J’ai couvert Spec-Kitty et Superpowers dans un article précédent. GSD se positionne différemment :

Contre Spec-Kitty : GSD n’a pas de dashboard kanban ni de multi-agent cross-tool (Claude + Cursor + Gemini dans le même projet). En revanche, l’orchestration par vagues avec contexte frais par executor est plus sophistiquée. Spec-Kitty donne un worktree par agent mais le même contexte continue ; GSD garantit 200k tokens propres par tâche.

Contre Superpowers : Superpowers enseigne des compétences (TDD, debugging, code review) mais ne gère pas le cycle de vie projet. GSD couvre tout de l’initialisation à la release. Les deux pourraient se compléter : Superpowers pour la discipline méthodologique à l’intérieur de chaque session, GSD pour l’orchestration globale.

L’argument principal de GSD : le context engineering. Pas juste “structurer le travail”, mais garantir que chaque agent travaille avec un contexte optimisé pour sa tâche spécifique. C’est ce qui permet de maintenir la qualité sur des projets de 50+ tâches.

13 Installation

npx get-shit-done-cc@latest

Compatible avec Claude Code, OpenCode et Gemini CLI. L’installation crée les slash commands dans .claude/commands/ et la structure .planning/ au premier /gsd:new-project.

Permissions

GSD fonctionne mieux avec claude --dangerously-skip-permissions pour que les subagents puissent écrire et committer sans confirmation manuelle à chaque étape. À évaluer selon votre contexte de sécurité.

14 Liens

GitHub : gsd-build/get-shit-done
Discord : discord.gg/gsd

Testé en février 2026. GSD évolue vite (v1.17+ au moment de l’écriture) ; vérifier les versions actuelles avant installation.