GSD (Get Shit Done) - Analyse approfondie

Introduction

Dans l'analyse approfondie de Ralph Wiggum, nous avons decouvert un probleme fondamental : le Context Rot — a mesure que la conversation s'allonge, la fenetre de contexte de Claude se remplit de code echoue, de discussions obsoletes et d'informations non pertinentes, ce qui degrade continuellement la qualite des resultats.

La solution de Ralph est de "tout redemarrer" : une boucle infinie en bash lance a chaque fois une nouvelle instance de Claude, en transmettant l'etat via le systeme de fichiers. Simple, efficace, mais avec des limites evidentes — ce n'est qu'une methodologie, sans comprehension du projet, sans planification par phases, sans verification de la qualite. Vous devez rediger les specs vous-meme, orchestrer les taches vous-meme, et juger vous-meme si "c'est termine ou non".

Comme Chase AI l'a resume avec precision dans sa video : Ralph Loop est une arme extremement puissante, mais la plupart des gens n'ont pas besoin d'une arme — ils ont besoin d'un arsenal complet. La boucle Ralph depend entierement de la preparation en amont : votre PRD est-il suffisamment bon ? Les definitions fonctionnelles sont-elles assez precises ? Savez-vous a quoi ressemble "termine" ? Si les reponses a ces questions ne sont pas precises, peu importe le nombre d'iterations de la boucle, ce sera du garbage in, garbage out.

Et si vous vouliez un systeme qui ne se contente pas de faire tourner Claude en boucle, mais qui comprend reellement votre projet et livre du code de maniere fiable ?

C'est exactement ce que GSD (Get Shit Done) se propose de faire.

Qu'est-ce que GSD

Le createur de GSD est TÂCHES (GitHub : glittercowboy), un developpeur independant. Sa motivation est directe :

"Je ne suis pas une entreprise de 50 personnes. Je ne veux pas jouer au theatre d'entreprise. Je suis juste un creatif qui veut faire de bonnes choses."

Lors de son stream en direct, TÂCHES a demontre un fait saisissant : il n'ecrit jamais de code a la main. Il a utilise GSD pour construire en 4 heures, a partir de zero, une application native macOS complete de generation musicale (Sample Digger), entierement sans code ecrit manuellement. Il ne se definit pas comme un programmeur, mais comme un "chef de projet de haut niveau" — decrire la vision, prendre les decisions cles, valider les resultats. GSD rend ce mode de travail possible.

"This has like 100x'd my ability to make cool shit with Claude Code because it's just created this systematization."

— TÂCHES

D'autres outils de developpement pilote par les specifications — BMAD, SpecKit — ont chacun leur valeur, mais ils tendent a introduire des workflows d'entreprise complexes : ceremonies de sprint, story points, synchronisations avec les parties prenantes. Pour les developpeurs independants ou les petites equipes, ces processus sont eux-memes un fardeau. Comme Chase AI l'a souligne : "It's not enterprise theater. We understand that you're just one person, you just want some sort of scaffolding around Claude Code to make sure it executes the tasks it says it's going to execute in an effective way."

La philosophie de conception de GSD est de cacher la complexite dans le systeme. L'utilisateur n'a besoin que de quelques commandes simples, tandis que le systeme gere en arriere-plan toute la gestion du contexte, l'orchestration des taches et la verification de la qualite. En un mois apres sa publication, le projet a obtenu pres de 3 000 stars sur GitHub et 14 000 installations npm, TÂCHES le mettant a jour presque 15 a 20 fois par jour.

La place de GSD dans l'ecosysteme des outils

Ce tableau revele un compromis cle : Ralph obtient l'autonomie d'execution la plus elevee avec la complexite systeme la plus basse — une fois lance, vous pouvez aller dormir ; tandis que GSD echange une complexite systeme elevee contre la qualite de planification et la validation humaine — vous avez l'opportunite d'intervenir a chaque phase. SpecKit et BMAD se situent entre les deux, offrant des capacites de planification mais sans l'ingenierie de contexte de GSD ni l'execution autonome de Ralph.

GSD et Ralph ne sont pas contradictoires. GSD herite des principes fondamentaux de Ralph — contexte frais, fichiers comme source de verite — mais construit dessus un systeme complet de comprehension et d'execution de projet. Si Ralph c'est "donner une tache a l'IA et la laisser reessayer en boucle", GSD c'est "comprendre ce que vous voulez, rechercher comment le faire, planifier les etapes, executer et verifier".

Le resume de Chase AI est tres juste : La boucle Ralph suppose que vous arrivez avec un plan complet — GSD vous aide a construire ce plan. GSD prend votre idee a moitie formee, pose des questions approfondies, effectue des recherches pour vous, genere un PRD complet, le decompose en taches atomiques, puis livre le projet de bout en bout. Et lors de l'execution du code, il utilise precisement les principes fondamentaux qui rendent la boucle Ralph puissante : le contexte frais des sous-agents, et des taches aussi petites et precises que possible.

Workflow principal

Le workflow de GSD est un cycle discussion → planification → execution → verification, avec des entrees et sorties clairement definies a chaque phase.

1. Initialisation du projet

/gsd:new-project

Une seule commande lance l'ensemble du processus. Le systeme va :

1. Questionner — Poser des questions de maniere continue jusqu'a comprendre pleinement votre idee (objectifs, contraintes, preferences techniques, cas limites)
2. Rechercher — Envoyer des agents paralleles pour etudier les domaines pertinents (optionnel mais recommande)
3. Extraire les exigences — Distinguer le contenu v1, v2 et hors perimetre
4. Feuille de route — Creer une planification par phases correspondant aux exigences

Vous approuvez la feuille de route, puis la construction commence. L'experience de TÂCHES montre que : plus la description initiale est detaillee, moins le systeme pose de questions ; plus elle est vague, plus il en pose. Il recommande de preparer un document de vision sommaire avant de demarrer — pas besoin de connaitre la stack technique ou les details d'implementation, il suffit de decrire ce que vous voulez.

Fichiers produits : PROJECT.md, REQUIREMENTS.md, ROADMAP.md, STATE.md

Vous avez deja une base de code ? Executez d'abord /gsd:map-codebase, le systeme enverra des agents paralleles pour analyser votre stack technique, architecture, conventions et problemes potentiels. Ensuite, /gsd:new-project pourra planifier en se basant sur la base de code existante.

2. Phase de discussion

/gsd:discuss-phase 1

Chaque phase de la feuille de route n'a qu'une ou deux phrases de description, ce qui est insuffisant pour construire ce que vous voulez. La phase de discussion sert a capturer vos preferences d'implementation avant la recherche et la planification.

Le systeme analyse la phase courante et identifie les "zones grises" — ces points de decision ou plusieurs implementations sont raisonnables :

• Fonctionnalites visuelles → mise en page, interactions, gestion des etats vides
• API/CLI → format de reponse, gestion des erreurs, niveau de detail
• Systeme de contenu → structure, ton, profondeur, flux

Chaque decision que vous prenez ici affecte directement la qualite de la recherche et de la planification ulterieures. Vous pouvez sauter cette etape (le systeme utilisera des valeurs par defaut raisonnables), mais une discussion approfondie permet au systeme de construire quelque chose de plus conforme a vos attentes.

Fichier produit : {phase}-CONTEXT.md

3. Phase de planification

/gsd:plan-phase 1

Le systeme va :

1. Rechercher — Etudier comment implementer la phase courante, guide par les decisions de la phase de discussion
2. Planifier — Creer 2 a 3 plans de taches atomiques, en utilisant un format structure XML
3. Verifier — Controler que le plan satisfait les exigences, iterer et corriger jusqu'a validation

Un principe de conception important est le Goal-Backward Planning (planification par retro-objectif). Au lieu de partir de "que devrions-nous construire", on demande "pour atteindre l'objectif, quelles conditions doivent etre remplies ?" — puis on deduit le plan et les taches en sens inverse. TÂCHES affirme que cette approche "a considerablement ameliore la qualite des resultats", car chaque tache comprend sa relation avec les autres, au lieu d'etre simplement un element d'une liste a faire.

Chaque plan est suffisamment petit pour etre execute dans une fenetre de contexte entierement nouvelle. C'est la cle — il n'y aura pas de degradation de la qualite.

Fichiers produits : {phase}-RESEARCH.md, {phase}-{N}-PLAN.md

4. Phase d'execution

/gsd:execute-phase 1

Le systeme va :

1. Execution par vagues — Les taches independantes sont executees en parallele, celles avec des dependances en sequence
2. Contexte frais — Chaque plan est execute dans un nouveau contexte de 200k tokens, zero accumulation de dechets
3. Commits atomiques — Chaque tache fait l'objet d'un git commit independant
4. Verification des objectifs — Verifier que la base de code implemente bien les fonctionnalites promises par la phase

Lors du stream en direct de TÂCHES, il a complete le developpement de 3 phases entieres, la fenetre de contexte principale restant constamment a 24%. Le sous-agent GSD Executor n'a besoin de charger que moins de 1 000 lignes de contexte pour achever une phase complete — vous pouvez executer 10 plans consecutifs, le contexte restant en dessous de 50%. C'est une experience completement differente du travail direct dans Claude Code : vous ne "jouez plus a la roulette russe en pariant sur le moment ou vous allez heurter le mur de la fenetre de contexte".

Fichiers produits : {phase}-{N}-SUMMARY.md, {phase}-VERIFICATION.md

5. Phase de verification

/gsd:verify-work 1

La verification automatisee peut controler si le code existe et si les tests passent. Mais la fonctionnalite fonctionne-t-elle comme vous l'attendez ? Cela necessite votre confirmation.

Le systeme va :

1. Extraire les livrables testables — Lister les choses que vous devriez pouvoir faire maintenant
2. Guider la verification une par une — "Pouvez-vous vous connecter par email ?" Oui/Non, ou decrire le probleme
3. Diagnostiquer automatiquement les echecs — Envoyer un agent de debogage pour trouver la cause racine
4. Creer un plan de correction — Un plan de correction directement executable

Si tout passe, on continue a la phase suivante. S'il y a des problemes, executez a nouveau /gsd:execute-phase pour lancer le plan de correction.

C'est la plus grande difference ideologique entre GSD et la boucle Ralph : Ralph est hands-off — vous lancez et vous le laissez tourner ; GSD a une etape de validation humaine a la fin de chaque phase. Chase AI souligne que la boucle Ralph est du type "partez a la conquete" — elle tourne toute seule sans se retourner ; GSD s'assure que vous pouvez intervenir et corriger le cap a chaque point critique, evitant que les erreurs s'accumulent couche apres couche sans supervision.

De plus, GSD fournit un processus de debogage dedie. Lorsque la verification trouve un probleme, /gsd:debug lance un sous-agent de debogage isole, avec son propre workflow hypothese-preuves-solution, creant une documentation de debogage independante qui trace l'ensemble du processus d'investigation, sans polluer le contexte principal.

Fichier produit : {phase}-UAT.md

Repeter le cycle

/gsd:discuss-phase 2 → /gsd:plan-phase 2 → /gsd:execute-phase 2 → /gsd:verify-work 2
...
/gsd:complete-milestone → /gsd:new-milestone

Chaque phase passe par le cycle complet discussion → planification → execution → verification. Le contexte reste frais, la qualite reste constante.

Une fois toutes les phases terminees, /gsd:complete-milestone archive le jalon et marque la version. Puis /gsd:new-milestone demarre la construction de la version suivante.

Pourquoi cela fonctionne : principes techniques

La fiabilite de GSD n'est pas le fruit du hasard, elle repose sur quatre piliers techniques cles.

Context Engineering

Claude Code est extremement puissant lorsqu'il recoit le bon contexte. La plupart des gens ne savent pas comment lui fournir le bon contexte. GSD gere cela pour vous.

Chaque fichier a une limite de taille basee sur le seuil de degradation de qualite de Claude. Rester sous ces limites garantit une qualite de sortie elevee et constante. La fenetre de contexte principale reste a 30-40%, le travail reel etant effectue dans le contexte frais de 200k des sous-agents.

Chase AI a une explication intuitive du context rot : quelle que soit la taille de la fenetre de contexte — Sonnet, Opus, meme une fenetre d'un million de tokens — les tokens de la premiere moitie sont plus efficaces que ceux de la seconde moitie. Ce n'est pas un bug, c'est une propriete inherente des LLM. Le mecanisme autocompact integre de Claude Code ne peut que partiellement attenuer le probleme. La solution de GSD est plus radicale : chaque tache atomique est executee dans un nouveau sous-agent, garantissant que chaque tache obtient le meilleur de Claude.

Les propres donnees de TÂCHES le confirment : sur le plan Max a $200/mois, il consomme environ $30 000 de tokens Opus par mois. Cela semble beaucoup, mais comme chaque tache est executee dans un contexte frais, les reprises sont rares, et l'efficacite reelle est bien superieure a celle d'un travail de rafistolage repete dans un contexte degrade.

XML Prompt Formatting

Chaque plan est un XML structure optimise pour Claude :

<task type="auto">
  <name>Create login endpoint</name>
  <files>src/app/api/auth/login/route.ts</files>
  <action>
    Use jose for JWT (not jsonwebtoken - CommonJS issues).
    Validate credentials against users table.
    Return httpOnly cookie on success.
  </action>
  <verify>curl -X POST localhost:3000/api/auth/login returns 200 + Set-Cookie</verify>
  <done>Valid credentials return cookie, invalid return 401</done>
</task>

Des instructions precises, aucune devinette necessaire, la verification est integree dans chaque tache.

Multi-Agent Orchestration

Chaque phase utilise le meme schema : un orchestrateur leger envoie des agents specialises, collecte les resultats et les achemine vers l'etape suivante.

L'orchestrateur ne fait jamais le gros du travail. Il envoie des agents, attend, integre les resultats. Le resultat : vous pouvez executer une phase entiere — recherche approfondie, creation et validation de multiples plans, des milliers de lignes de code ecrites en parallele, verification automatique — tandis que votre fenetre de contexte principale reste a 30-40%.

Atomic Git Commits

Chaque tache est commitee independamment des qu'elle est terminee :

abc123f docs(08-02): complete user registration plan
def456g feat(08-02): add email confirmation flow
hij789k feat(08-02): implement password hashing
lmn012o feat(08-02): create registration endpoint

Avantages : git bisect peut localiser la tache exacte qui a echoue, chaque tache peut etre annulee independamment, l'historique clair aide Claude a comprendre l'evolution du code dans les sessions futures.

Les limites de GSD

GSD est puissant, mais comprendre ce qu'il ne peut pas faire est tout aussi important.

GSD est un workflow guide par l'humain, pas un agent autonome

GSD ne peut pas tourner de maniere persistante. Chaque frontiere de phase — de discuss a plan a execute a verify — necessite que vous saisissiez manuellement une commande. Vous ne pouvez pas dire "fais-moi une app" et aller dormir.

Cela contraste fortement avec le mode AFK de Ralph. Ralph est concu pour "lancer et aller dormir" — la boucle infinie en bash continue de tourner jusqu'a ce que la tache soit terminee ou echoue. GSD exige que vous soyez present a chaque point critique : approuver la feuille de route, repondre aux questions de discussion, declencher la planification, lancer l'execution, confirmer les resultats de verification.

Lors de son stream en direct de 4 heures, TÂCHES a saisi des commandes en continu : new-project, discuss-phase 1, plan-phase 1, execute-phase 1, verify-work 1, discuss-phase 2... Chaque transition necessite qu'il appuie sur Entree. Ce n'est pas accidentel — c'est un choix de conception delibere.

Un compromis de conception delibere

Ralph sacrifie la capacite de planification au profit de l'autonomie d'execution ; GSD sacrifie l'autonomie d'execution au profit de la qualite de planification et de la validation humaine. C'est un compromis de conception, pas un defaut.

• Avantage de Ralph : Vous pouvez le laisser tourner pendant que vous dormez et il completera une fonctionnalite entiere. Mais si les specs ne sont pas assez bonnes, il foncera a toute allure dans la mauvaise direction.
• Avantage de GSD : Vous pouvez corriger le cap a la fin de chaque phase. Mais vous devez etre present tout au long du processus, sans pouvoir vous absenter.

Quel serait l'etat ideal ? Si la discussion, la planification, l'execution et la verification de GSD pouvaient etre enchaines en un cycle automatique — similaire a la boucle bash de Ralph, mais avec la planification structuree et la verification qualite de GSD — ce serait le meilleur des deux mondes. Mais un tel outil n'existe pas encore. C'est peut-etre la prochaine direction a explorer.

Ressources video

Les videos suivantes peuvent vous aider a mieux comprendre de maniere visuelle l'utilisation et l'efficacite de GSD.

I Created GSD For Claude Code. This Is How I Use It.

Stream en direct de 4 heures de TÂCHES, le createur de GSD. Construction a partir de zero d'une application native macOS complete de generation musicale IA (Sample Digger), entierement sans code ecrit manuellement. Demonstration du sous-agent GSD Executor, de la planification par retro-objectif, du workflow de debogage, du changement multi-modeles, et de la maniere dont le contexte principal reste a 24% apres 10 phases.YouTube

The New Claude Code Meta

Chase AI explique pourquoi GSD est le nouveau meta pour les developpeurs solo. Analyse approfondie du principe du context rot, de la maniere dont l'execution par sous-agents garantit la qualite des resultats, des trois documents fondamentaux de GSD (Project/Roadmap/State), ainsi que son experience reelle de construction d'un clone de My Fitness Pal avec GSD.YouTube

Stop Using Ralph Loops (Use This Instead)

Chase AI evalue GSD du point de vue d'un utilisateur de la boucle Ralph. Argument central : la boucle Ralph est une arme puissante, mais GSD est l'arsenal complet. Comparaison du mode hands-off de Ralph vs la verification human-in-the-loop de GSD, demonstration du processus complet d'installation et d'execution, discussion sur le compromis cout en tokens.YouTube

Conclusion

GSD represente une direction dans l'evolution des outils de programmation IA : passer de "faire ecrire du code par l'IA" a "faire livrer des projets de maniere fiable par l'IA".

Ralph Wiggum a prouve une intuition cle — un contexte frais est plus precieux qu'un contexte accumule. GSD s'appuie sur cette base en ajoutant la comprehension du projet (new-project), la capture des decisions (discuss), la planification structuree (plan), l'execution parallele (execute) et la verification qualite (verify), formant ainsi un cycle complet en boucle fermee.

Pour les developpeurs independants et les petites equipes, la valeur de GSD reside dans le fait qu'il encapsule des pratiques d'ingenierie complexes en quelques commandes simples. Vous n'avez pas besoin de comprendre l'orchestration de sous-agents ou l'ingenierie de prompts XML — il vous suffit de decrire ce que vous voulez, puis de laisser le systeme s'en occuper.

Chase AI le dit bien : GSD est fait pour ceux qui "ne viennent pas d'un background technique, mais qui veulent tout de meme construire des projets de bout en bout dans Claude Code de maniere durable et reproductible". Et le stream en direct de TÂCHES le prouve — quelqu'un qui se decrit comme "capable tout au plus d'ecrire une page HTML Hello World tout seul" a construit une application de bureau native complete avec GSD.

Ce n'est pas de la magie. C'est mettre la bonne complexite au bon endroit — le systeme assume la complexite d'orchestration, l'humain se concentre sur la creativite et les decisions. Et ses limites meritent egalement d'etre respectees : GSD a choisi de garder l'humain toujours present, ce qui est a la fois sa limitation et la source de sa fiabilite.

Vous voulez passer a la pratique ? Poursuivez avec le guide pratique GSD — couvrant la reference complete des commandes, les details de configuration, les demonstrations de workflows reels et les questions frequentes.

Lectures connexes :

• Analyse approfondie de Ralph Wiggum — Analyse complete du probleme du Context Rot et de la methodologie Ralph
• Qu'est-ce que le developpement pilote par les specifications — De la programmation intuitive au developpement pilote par les specifications
• Guide complet des sous-agents Claude — Une autre maniere de maintenir un contexte propre
• Architecture complete du systeme Claude — Architecture globale des composants Hooks, Subagent, etc.
• Mes meilleures pratiques Claude Code — Conseils d'utilisation quotidienne de Claude Code