Claude Code et GSD Skills : passer du prompt one-shot à l'agent qui livre vraiment

Quand on commence avec Claude Code, on découvre vite la limite naturelle d'un agent piloté au prompt. On lui demande "ajoute telle feature", il fonce, écrit du code, et on se retrouve à devoir relire, corriger, réorienter. Sur des tâches simples, ça marche. Sur des tâches sérieuses — celles qui touchent plusieurs fichiers, qui demandent de comprendre un domaine, qui ont des contraintes implicites — ça finit souvent en allers-retours.

Le problème n'est pas l'agent. C'est le format dans lequel on le fait travailler.

C'est précisément la lecture qui sous-tend GSD (pour Get Shit Done), un système de skills pour Claude Code qui propose une autre façon de structurer le travail : transformer une demande en phases explicites — comprendre, discuter, planifier, exécuter, vérifier — chacune outillée par un skill dédié.

Dans cet article, je veux poser ce que GSD apporte concrètement, pourquoi cette approche change le rapport au modèle, et où elle a (vraiment) du sens.

1. Ce que sont les skills dans Claude Code

Avant d'entrer dans GSD, un mot rapide sur le système de skills lui-même.

Un skill dans Claude Code, c'est un bout de logique invocable au sein d'une session — une instruction structurée que l'agent peut appeler comme un sous-programme. On le déclenche via /<nom-du-skill>, on lui passe éventuellement des arguments, et il s'exécute dans le même contexte. La différence avec un simple prompt textuel : un skill encapsule un workflow — étapes, agents auxiliaires, livrables attendus — au lieu de laisser le modèle improviser à chaque fois.

Concrètement, ça permet trois choses :

Standardiser une procédure (par exemple : la façon de planifier une feature, ou celle de vérifier un changement) sans la réécrire à chaque session.
Décomposer un travail complexe en étapes que l'agent peut traverser de façon traçable.
Capitaliser sur des patterns qui marchent — un skill bien conçu condense des heures d'apprentissage en une seule commande.

C'est sur cette mécanique-là que GSD se construit. Pas un seul skill, mais une famille de skills qui se coordonnent autour d'un même modèle mental.

2. L'idée centrale de GSD : penser en phases, pas en tâches

L'erreur classique avec un agent, c'est de le piloter comme un développeur senior — "fais ça, ajoute ceci" — alors qu'il a besoin d'une structure plus explicite pour livrer correctement sur des changements non triviaux.

GSD part d'une observation simple : le travail logiciel sérieux suit naturellement des phases. On ne plonge pas dans le code avant d'avoir compris le besoin. On ne planifie pas avant d'avoir cerné le contexte. On ne vérifie pas avant d'avoir exécuté. Ces étapes existent déjà dans la pratique des bons devs, mais elles sont implicites. GSD les rend explicites et outillées.

Concrètement, le cycle ressemble à :

Discuss — clarifier le besoin, lever les ambiguïtés, valider les hypothèses avant de planifier.
Plan — décomposer en tâches, identifier les dépendances, définir les critères de succès.
Execute — implémenter par vagues, avec commits atomiques et state tracking.
Verify — vérifier que le code livre réellement ce que la phase promettait.

Chaque étape a son skill correspondant : /gsd-discuss-phase, /gsd-plan-phase, /gsd-execute-phase, /gsd-verify-work. Et entre ces étapes, des skills auxiliaires : /gsd-map-codebase pour analyser un repo en parallèle avec plusieurs agents, /gsd-research-phase pour aller chercher de la doc externe avant de planifier, /gsd-add-tests pour combler les gaps de validation après coup.

L'effet pratique est intéressant. Quand on demande à l'agent "implémente telle feature", il ne saute plus directement au code. Il déroule la phase de discussion, valide ce qu'il a compris, propose un plan, attend validation, puis exécute. Sur une feature de taille moyenne, ça change radicalement la qualité du livrable — moins de retours, moins de "non c'est pas ça que je voulais".

3. Le piège que GSD adresse : la perte de contexte entre sessions

Un autre problème classique avec un agent piloté au prompt : le contexte ne survit pas à la session. Tu passes une heure à expliquer un domaine, à corriger une approche, à valider des choix — et la session suivante, tu repars de zéro.

GSD propose une réponse à ça via un répertoire .planning/ que les skills alimentent et consultent au fil du travail :

des plans versionnés (PLAN.md par phase) qui décrivent ce qu'on a décidé de faire,
des artefacts de recherche (RESEARCH.md) produits avant le plan,
des rapports de vérification (VERIFICATION.md) après exécution,
une roadmap projet (ROADMAP.md) qui décrit les phases et leur état.

Le résultat : un agent qui ouvre une nouvelle session peut lire ce répertoire et reprendre exactement là où le précédent s'était arrêté, avec le même modèle mental. Pas besoin de réexpliquer pourquoi on a choisi telle architecture ou pourquoi telle phase a été reportée.

C'est, à mon sens, le point le plus sous-estimé de GSD. Pas la décomposition en phases — d'autres systèmes le proposent. Mais l'ancrage de cette décomposition dans des fichiers persistants que l'agent peut consulter sans intervention humaine. Ça transforme une suite de sessions isolées en un flux de travail continu.

4. Les skills auxiliaires qui font vraiment la différence

Au-delà du quartet discuss / plan / execute / verify, GSD propose une bibliothèque de skills plus spécialisés. Quelques-uns valent la peine d'être cités, parce qu'ils résolvent des problèmes concrets :

/gsd-map-codebase : lance plusieurs agents en parallèle pour cartographier un repo (tech, architecture, qualité, risques) et produit une série de documents que les phases suivantes peuvent consulter. Sur un onboarding dans une grosse codebase, ça évite à l'agent de partir explorer aveuglément à chaque session.
/gsd-debug : un workflow de debug "scientifique" — hypothèses, expériences, checkpoints. Au lieu de laisser l'agent itérer à l'aveugle sur un bug, il est forcé de poser des hypothèses explicites et de les valider une à une.
/gsd-secure-phase : revue rétroactive de sécurité sur une phase déjà livrée, avec génération d'un SECURITY.md qui trace les menaces identifiées et leurs mitigations.
/gsd-ui-phase et /gsd-ui-review : design contracts pour le frontend, avec audit visuel à 6 dimensions. Pour des projets où le design compte, c'est un gain de cohérence.
/gsd-ship : créer la PR, lancer la review, préparer le merge — l'avant-dernière étape avant que ton code parte.
/gsd-pr-branch : produire une branche PR "propre" en filtrant les commits .planning/, pour que la review ne soit pas polluée par les artefacts internes.

Tous ces skills ont une caractéristique en commun : ils codent une bonne pratique que les bons devs appliquent déjà à la main. La valeur n'est pas la technique en soi, c'est qu'elle devient systématique et automatique, sans demander à l'humain de s'en souvenir à chaque feature.

5. Quand GSD a du sens — et quand il n'en a pas

Soyons honnêtes : GSD ajoute de l'overhead. Pour des tâches triviales, c'est trop lourd. Si tu veux juste corriger un typo ou modifier une string, tu n'as pas besoin de planifier en phases. C'est d'ailleurs pourquoi GSD propose des skills "rapides" comme /gsd-fast ou /gsd-quick, qui court-circuitent le workflow lourd pour les tâches simples.

GSD prend tout son sens quand :

la tâche est sérieuse — multi-fichiers, cross-cutting, avec des dépendances entre composants,
le domaine demande de la rigueur — un changement risqué dans une codebase mature, une feature avec des contraintes de sécurité ou de compliance, une migration,
l'humain n'est pas disponible en continu pour réorienter l'agent au fil de l'eau,
on travaille sur un projet qui va durer, où le contexte accumulé entre sessions a une vraie valeur.

À l'inverse, GSD est probablement trop pour :

un script jetable,
un prototype exploratoire qu'on va jeter,
une simple correction de bug évidente,
un projet où on est constamment dans la session de l'agent et où on préfère piloter au feeling.

Il y a un autre coût qu'il faut accepter : GSD vit dans le repo. Le répertoire .planning/ est versionné, parfois lourd, et reflète l'état du projet à un instant T. C'est un investissement dans la traçabilité, qui se paye en lignes de Markdown supplémentaires dans le repo.

À chacun de juger si ça vaut le coup. Mon expérience : sur des projets sérieux, oui, largement.

6. Pourquoi c'est plus large qu'une simple méthodo

Au fond, GSD n'est pas seulement un ensemble de skills. C'est une prise de position sur ce que devient un agent quand on lui donne les bons outils.

L'idée implicite, c'est que la qualité d'un agent ne dépend pas seulement du modèle qui le motorise. Elle dépend du harness — la couche qui structure son travail, persiste son contexte, vérifie son output. Un excellent modèle dans un harness médiocre livrera moins bien qu'un modèle correct dans un harness excellent.

Et c'est une bonne nouvelle. Parce que ça veut dire qu'on peut, dès aujourd'hui, améliorer la qualité de nos agents sans attendre la prochaine génération de modèles. Il suffit de structurer mieux.

GSD est une instance particulière de cette idée. Il y en aura d'autres, avec d'autres conventions, d'autres formats, d'autres trade-offs. Mais le pattern central est, je pense, durable : la productivité agent vient de la combinaison modèle × harness × workflow, et le harness est le levier le plus accessible aux développeurs.

7. Conclusion : passer de "chat avec un agent" à "produire avec un système"

Si tu utilises Claude Code au quotidien et que tu te retrouves à réexpliquer le même contexte de session en session, à passer plus de temps à corriger qu'à valider, à hésiter avant de lancer une feature parce que tu sais qu'il va falloir la reprendre — GSD vaut le coup d'être essayé.

Pas comme une recette magique. Comme un changement de format de travail : on arrête de demander à l'agent de "faire", on lui demande de traverser des phases, en laissant des traces que la prochaine session pourra reprendre.

Le bénéfice se sent rapidement. Moins d'allers-retours, plus de continuité, des features qui partent en PR avec une trace claire de ce qui a été fait, pourquoi, et ce qu'il reste. Et surtout : un agent qui se comporte de plus en plus comme un collaborateur qui comprend où il en est, plutôt que comme un exécutant qui repart à zéro à chaque tour.

C'est, à mon avis, dans cette direction que va le travail avec les agents en 2026. Pas plus de magie côté modèle, mais plus de discipline côté pipeline. Et GSD est un bon point d'entrée pour s'y mettre.