get-shit-done — Spec-driven dev, wave execution, context isolation par tâche¶
Resume¶
get-shit-done (42K stars, MIT, npm i get-shit-done-cc) est un système de développement spec-driven pour agents IA. Le problème central qu'il adresse : le "context rot" — dégradation de la qualité à mesure que la fenêtre de contexte se remplit. Solution : contexte de 200K tokens frais par tâche. Workflow : /gsd:new-project (questions → roadmap) → /gsd:discuss-phase (décisions d'implémentation) → /gsd:plan-phase (plan atomique) → /gsd:execute-phase (vagues parallèles, contexte isolé par tâche) → /gsd:verify-work (UAT manuel + debug auto). Compatible Claude Code, OpenCode, Gemini CLI, Codex, Cursor.
Analyse critique¶
La convergence avec le modèle ProbatioVault est frappante :
| get-shit-done | ProbatioVault Governance | Observation |
|---|---|---|
/gsd:discuss-phase (décisions avant plan) | Step 0 (besoin) + /coherence | Même principe : clarifier avant de planifier |
/gsd:plan-phase (plan atomique) | Step 4 + /gov-check-plan | Même granularité cible |
/gsd:execute-phase (vagues, 200K frais) | Step 6b (17 agents claude -p isolés) | Identique — isolation de contexte par agent |
/gsd:verify-work (UAT + debug) | Step 7 acceptabilité | Même intention, PV plus formalisé |
| Commits atomiques par tâche | Convention commits post-Gate 8 | Même principe git |
Le "context rot" est le même problème que ProbatioVault résout avec les subprocess claude -p isolés. GSD l'a nommé et en a fait le centre de sa proposition de valeur.
Ce que GSD fait mieux :
La gestion des dépendances entre vagues (wave-based execution) est plus explicite que le step 6b actuel. Dans GSD, les tâches avec dépendances sont regroupées en vagues ordonnées — les tâches d'une même vague s'exécutent en parallèle, les vagues suivantes attendent la précédente. Le step 6b actuel gère ça manuellement via WORKFLOW-STATE.md.
Ce que ProbatioVault fait mieux :
GSD n'a pas de gates PMO (validation croisée), pas d'invariants formels, pas de traçabilité YAML, pas de boucle de correction avec plafond d'itérations. C'est un outil de productivité, pas un système de gouvernance. Le /gsd:verify-work est un "manual user acceptance testing" — là où ProbatioVault a une phase automatisée (ObviousUI-QA, Sonar, tsc) ET une phase LLM formalisée.
42K stars en peu de temps : à vérifier l'ancienneté. La description "npm package" et multi-runtime suggest une approche marketing-first. Mais le contenu technique est cohérent.
Pertinence ProbatioVault¶
Impact faible — décision déjà prise en février 2026 (TODO.md §2, archivé).
Le problème que GSD résout (context rot) est déjà traité dans ProbatioVault par trois mécanismes combinés : subprocess delegation (claude -p isolés), prompt caching (contenu statique en premier), et compaction awareness. L'intégration GSD a été évaluée et écartée — détail dans docs/architecture/vision-n8n-gsd.md.
Valeur résiduelle : GSD confirme rétrospectivement que les choix architecturaux de ProbatioVault sont dans le bon sens — un outil externe de 42K stars a convergé vers les mêmes patterns de façon indépendante. Pas d'action à prendre.