Get Shit Done - système de méta-prompts et de développement piloté par les spécifications

 (github.com/gsd-build)
12 points par GN⁺ 2026-03-19 | 1 commentaires | Partager sur WhatsApp
  • Système léger qui automatise le développement piloté par les spécifications (SDD) dans Claude Code et autres, afin d’aider à mener un projet à bien sans workflows complexes
  • Empêche la dégradation de la qualité du code IA (context rot) grâce à l’ingénierie de contexte, à la structuration des prompts basée sur XML et à l’orchestration multi-agents
  • Automatise tout le cycle de développement, de la définition de l’idée → planification → exécution → validation, avec des commandes comme /gsd:new-project, /gsd:plan-phase, /gsd:execute-phase
  • Garantit traçabilité et efficacité grâce à des commits Git atomiques pour chaque unité de travail et à l’exécution parallèle (wave execution)
  • Outil utilisé par des ingénieurs de Amazon, Google, Shopify, Webflow, qui améliore la fiabilité et la productivité du développement assisté par l’IA

Aperçu

  • Get Shit Done (GSD) est un système léger de méta-prompts et de gestion du contexte qui fonctionne dans divers environnements de développement IA comme Claude Code, OpenCode, Gemini CLI, Codex, Copilot, Antigravity
  • Il résout le problème de context rot, où la qualité du contexte se dégrade pendant que l’IA écrit du code, et produit des résultats cohérents sur la base des spécifications
  • Fonctionne sur Mac, Windows et Linux, et peut être installé avec la commande npx get-shit-done-cc@latest

Contexte de création (Why I Built This)

  • Créé pour résoudre le problème des outils destinés aux grandes organisations qui imposent des procédures inutilement complexes
  • GSD est conçu selon le principe suivant : la complexité à l’intérieur du système, un workflow simple pour l’utilisateur
  • En interne, il gère l’ingénierie de contexte, le formatage XML des prompts, l’orchestration de sous-agents et la gestion d’état
  • L’utilisateur peut mener un projet à terme avec de simples commandes

Fonctions clés et workflow (How It Works)

  • L’ensemble du processus de développement se compose de 6 étapes

    1. Initialisation du projet : interroge sur l’idée, les contraintes, la stack technique, puis génère PROJECT.md, ROADMAP.md, etc.
    2. Phase de discussion : définit les détails d’implémentation et crée CONTEXT.md
    3. Phase de planification : recherche en parallèle et élaboration du plan, avec création d’unités de travail structurées en XML
    4. Phase d’exécution : exécution parallèle par vagues (wave) selon les dépendances, avec commit et validation pour chaque tâche
    5. Phase de validation : tests automatiques et confirmation utilisateur, avec génération automatique d’un plan de correction en cas d’échec
    6. Itération et achèvement des jalons : répétition des étapes puis marquage de release

  • Le Quick Mode traite rapidement une tâche unique, avec un contrôle fin via les flags --discuss, --research, --full

Technologies clés (Why It Works)

  • Ingénierie de contexte : gestion du contexte global du projet au niveau des fichiers (PROJECT.md, REQUIREMENTS.md, STATE.md, etc.)
  • Formatage XML des prompts : définit clairement chaque tâche et inclut les procédures de validation
  • Orchestration multi-agents : exploitation parallèle d’agents spécialisés pour la recherche, la planification, l’exécution et la validation
  • Commits Git atomiques : un commit par unité de travail pour garantir la traçabilité et faciliter la restauration
  • Conception modulaire : ajout, insertion et modification d’étapes libres pour une gestion de projet flexible

Système de commandes (Commands)

  • Workflow principal : /gsd:new-project, /gsd:plan-phase, /gsd:execute-phase, /gsd:verify-work
  • Aide à la conception UI : /gsd:ui-phase, /gsd:ui-review
  • Analyse de la base de code : /gsd:map-codebase
  • Gestion de projet : /gsd:add-phase, /gsd:insert-phase, /gsd:complete-milestone
  • Utilitaires : /gsd:quick, /gsd:health, /gsd:stats, /gsd:debug, /gsd:note, etc.

Paramétrage et configuration (Configuration)

  • Le fichier de configuration .planning/config.json permet de contrôler le mode, le niveau de découpage des phases, les profils de modèle, les agents de workflow, la parallélisation et la stratégie de branching Git
  • Les profils de modèle disponibles sont quality, balanced, budget, inherit
  • Des bascules comme workflow.research, workflow.plan_check, workflow.verifier permettent d’ajuster qualité et vitesse

Sécurité et résolution des problèmes (Security & Troubleshooting)

  • Les fichiers sensibles comme .env, secrets/, *.pem, *.key doivent être ajoutés à la deny list de Claude Code afin d’en bloquer l’accès
  • En cas d’erreur de reconnaissance des commandes après installation, il est recommandé de redémarrer le runtime ou de réinstaller
  • Dans un environnement Docker, les problèmes de chemin peuvent être résolus avec le paramètre CLAUDE_CONFIG_DIR
  • L’option --uninstall permet de supprimer tous les composants

Communauté et licence

  • Prise en charge de ports communautaires pour OpenCode, Gemini CLI et Codex
  • Publié sous licence MIT
  • « Claude Code is powerful. GSD makes it reliable. » — un outil qui renforce la fiabilité de Claude Code

À lire aussi

1 commentaires

 
GN⁺ 2026-03-19
Avis sur Hacker News

  • J’utilisais auparavant Plan mode avec Superpowers, mais j’ai fini par trouver que Plan mode seul suffisait
    Ce type de framework est utile pour les tâches fire-and-forget qui demandent de la recherche, mais j’avais l’impression que ça consommait plus de 10 fois plus de tokens
    La différence de qualité du résultat n’était pas énorme non plus, et j’atteignais souvent la limite du Max plan

    • J’ai repris les fonctions brainstorm·design·implementation planning de Superpowers pour les greffer sur une couche d’implémentation basée sur Ralph
      Une fois le plan d’implémentation terminé, ça enchaîne automatiquement sans me demander mon avis, mais il faut l’exécuter dans un sandbox Docker
      C’est à cause de réglages de permissions risqués, mais de toute façon je trouve ça plus sûr ainsi
      Pour l’instant ça marche bien et c’est productif, mais j’ai l’impression que ce n’est qu’une étape intermédiaire du parcours
    • Moi, j’ai fait l’inverse et je suis passé de Plan mode à Superpowers
      Je l’ai réessayé après l’annonce de la dernière version, et comme il y a plusieurs couches de cross-check et self-review, les résultats étaient plus stables
      On peut le faire à la main, mais Superpowers automatise le processus, donc c’était bien plus pratique
    • J’ai testé la même tâche avec GSD et Plan Mode : Plan Mode a terminé une implémentation de base en 20 minutes, alors que GSD a pris plusieurs heures
      GSD produisait un code tenant compte du contexte global du projet, tandis que Plan Mode implémentait juste le strict nécessaire, au niveau d’un MVP
      Les avantages et inconvénients sont très marqués selon le workflow et la taille du travail
    • Le Plan mode de GitHub Copilot a changé bizarrement récemment depuis l’ajout de la plan memory
      Les sorties sont devenues plus verbeuses, alors que les détails sont au contraire plus flous
      Il y a plus d’étapes du type “design” ou “figure out”, puis ça passe directement à l’implémentation sans question de suivi
    • J’ai eu une expérience similaire. J’ai brûlé une semaine de frais d’abonnement Claude et de crédits API pour obtenir à peine 500 lignes de code
      Il manipulait parfois les tests ou produisait des résultats à côté de la plaque
      Au final, j’ai terminé le MVP en le guidant manuellement, et c’était bien plus efficace

  • Il y a trop de méta-frameworks de ce genre en ce moment, mais j’en ai rarement vu prouver une réelle productivité
    La plupart ne font que gaspiller des tokens et polluer la context window
    Au final, le mieux restait de faire simple : fournir uniquement les infos nécessaires et boucler sur Plan → Code → Verify

    • Dans l’article d’Apenwarr “The AI Developer’s Descent Into Madness”, il tourne en dérision la situation où « l’agent construit son propre framework »
    • J’ai moi-même créé un mini-framework combinant Claude et Codex
      Quand je vois Codex rattraper les erreurs produites par Claude seul, je me dis qu’on ne peut pas tout confier à un agent unique
    • J’utilise une approche de conception de spécifications visuelles
      Je conçois le flux des écrans de l’application sous forme d’images, puis je l’exporte en markdown structuré, ce qui permet au LLM de comprendre le contexte écran par écran
      Par rapport à une spécification textuelle, ça permet de détecter plus tôt les états manquants ou les flux d’erreur
    • Ces méta-frameworks ne sont au fond rien de plus que des outils personnalisés comme .vimrc ou .emacs.d
      Ils sont utiles pour leur auteur, mais donnent souvent l’impression d’être inutiles aux autres

  • À mon avis, les systèmes Spec-Driven sont voués à l’échec
    Des spécifications écrites en anglais ne parviennent pas à relier le code réel à son comportement
    Ce problème est déjà résolu par les tests automatisés
    Il faut encoder le comportement du système sous forme de tests exécutables
    Même quand un LLM génère l’implémentation, il faut d’abord écrire les tests et vérifier la cohérence via le mutation testing
    J’ai résumé ça dans cet article et cet exemple GitHub

    • Les spécifications en langage naturel ne passent pas à l’échelle, mais il y a peut-être une piste si on s’en sert pour produire une spécification formelle (formal spec)
      Au final, cela doit être exprimé sous forme de code
    • Il y avait aussi cet article disant “A sufficiently detailed spec is code”, mais je n’ai pas réussi à reproduire les résultats d’OpenAI
      Voir le lien
    • Le Spec Driven Development porte un nom proche du TDD, mais la logique est exactement inverse
    • Considérer les tests uniquement comme le produit dérivé des spécifications est un raisonnement erroné
      Les spécifications couvrent un champ bien plus large que les tests
      Il arrive aussi souvent que les LLM ignorent les tests ou les modifient arbitrairement

  • J’utilise un système d’IA personnel et j’hésite à le rendre public
    Il est tellement personnalisé pour ma façon de travailler que maintenir une version publique séparée me semble lourd
    Plutôt que de laisser d’autres personnes l’utiliser directement, j’aimerais qu’elles s’en inspirent pour partager seulement les patterns

    • Il n’est pas nécessaire d’assurer la maintenance à tout prix
      À l’ère de l’IA, le simple fait de partager de l’inspiration et des idées a déjà beaucoup de valeur

  • J’ai essayé GSD lors d’un hackathon en équipe, mais il mettait beaucoup trop de temps à comprendre la codebase et la consommation de tokens était énorme
    Il y avait aussi beaucoup d’erreurs lors de la génération des transcriptions d’agents
    C’était un outil excessif pour développer quelques petites fonctionnalités
    La leçon à retenir était simple : rédiger de bonnes specs + itérer avec Plan mode était bien plus efficace

  • Les contraintes de design de Beads me frustraient, donc j’ai créé moi-même un outil similaire
    Ma version est basée sur SQLite et j’y ai ajouté une synchronisation bidirectionnelle avec GitHub
    L’idée centrale est de discuter d’abord avec le modèle pour produire un fichier de spécifications clair
    Une fois ce fichier en place, le modèle n’oublie pas, et plus il y a de détails, meilleure est la qualité de sortie
    J’ai utilisé Claude pour prototyper une idée que je mûrissais depuis longtemps, et le résultat a été meilleur que prévu

    • Difficile de parler de “sauce secrète” alors que RPI (research-plan-implement) est déjà un concept présent dans la documentation officielle
      Les modèles restent des systèmes probabilistes, donc une mémoire parfaite est impossible
      Présenter ça comme si on avait découvert une nouvelle recette miracle, c’est exagéré

  • J’ai essayé Superpowers, et comme ce GSD semble similaire, j’étais curieux de la comparaison

    • J’ai utilisé les deux, et GSD est excessivement complexe et lent
      Le Quick mode lui fait perdre son objectif initial, et Superpowers me semblait un bon compromis
    • Les prompts structurés aident clairement
      Mettre ce genre de framework dans le dépôt, puis demander à l’IA d’améliorer le framework lui-même, peut aussi être utile pour des tâches créatives
      Mais ce type de structure ne me semble être qu’un hack temporaire, qui disparaîtra naturellement quand les modèles seront suffisamment entraînés
    • Superpowers écrivait tout le code dès l’étape de planification, puis les sous-agents le recopiaient tel quel, ce qui était inefficace
      GSD a résolu ce problème, mais comme il y a trop d’étapes, c’est lent
    • J’ai testé Superpowers en migrant mon blog de Hugo vers Astro
      Les spécifications produites par Superpowers étaient détaillées, mais il manquait certaines fonctions (par ex. RSS, analytics), et une spécification collaborative proposant une migration en parallèle était plus flexible
      Au final, j’ai demandé à Claude de comparer et fusionner les deux specs pour produire une version finale
      Voir la comparaison détaillée
    • Je ne suis pas sûr qu’un wrapper CLI soit vraiment nécessaire
      On peut très bien obtenir la même chose avec les skills de Claude

  • J’ai utilisé GSD intensivement pendant 3 mois, et c’est beaucoup plus abouti que speckit, que j’utilisais auparavant
    Même des tâches complexes sont automatisées à 95 %
    Les 5 % restants sont finalisés avec des tests manuels
    J’ai même lancé un produit SaaS (whiteboar.it) avec ça
    Le modèle lui-même a progressé entre-temps, mais le gain de productivité était bien réel

    • J’ai eu une expérience similaire
      Comme je trouvais l’abonnement FreshBooks trop cher, j’ai développé moi-même une application macOS en Swift avec GSD
      L’extraction automatique des reçus et leur catégorisation ont été implémentées via l’API Anthropic
      J’étais parti d’une web app, mais en ajoutant des fonctions comme l’intégration de l’appareil photo, c’est devenu une vraie application desktop
      Grâce à GSD, j’ai pu terminer mon application de comptabilité personnelle

  • Au final, le véritable outil qu’il nous faut, c’est un outil qui économise les tokens
    Mais ça n’existe pas encore
    Même Claude Code consomme trop de tokens sur les gros projets

  • Le nom de « cet ensemble de fichiers Markdown » est vraiment trop gênant

    • Ce serait sans doute mieux sous un dossier “Languages”
    • Cela dit, c’est toujours mieux que “gstack”, non ?