Specs Driven Vibe Coding : 2/3 : Matt Pocock Skills

Cette série en trois articles raconte mes expériences sur le développement assisté par. Les bons côtés, les frictions, les impasses, les surprises. L'évolution aussi, on le verra.

1. Le premier article parlait de BMAD, une méthode qui met en scène une équipe d'agents IA jouant chacun leur rôle de collègues virtuels
2. Le second article traitera des skills de Matt Pocock, qui sont une version un peu moins dense et plus orientée dev que BMAD
3. Dans le troisième, on essayera de créer notre propre workflow et on essayera Hermes et ses bots pour cela.

Contexte

Cette fois-ci, c'est une demo d'un futur produit SaaS qui a été conçu et développée, pour le compte d'une startup. Les contraintes étaient à la fois de pouvoir développer assez rapidement une demo montrable en avant-vente, avec un front et des features relativement limitées mais une archi backend la plus proche possible de la cible, afin de pouvoir scaler sans trop de pb, et surtout de poser les bases techniques et le socle permettant de gérer d'ores et déjà un peu de volume. Il fallait par exemple gérer les events SSE pour le temps réel, faire du multi-tenant, etc...

Stack utilisée

La nouveauté par rapport à l'essai BMAD, c'est l'abandon de Claude Code. Pour des raisons diverses et variées, d'ailleurs (coûts, dramas constants avec Fable, notamment, changements soudains dans la tarification, limite des 5 heures, volonté de ne pas être trop lié à un provider...).

On passa donc chez OpenCode, et leur abonnement Go qui donne accès à un large choix de modèles chinois. Notamment GLM 5.2 qui s'annonçait très performant pour des coûts bien en dessous de ceux pratiqués par Anthropic. L'envie était aussi de pouvoir tester différents modèles, passer sur des modèles gratuits pour certaines tâches, utiliser Mistral également pour d'autres, tout en partageant les configs autour du AGENTS.md.

Intro

Après BMAD et son équipe d'agents virtuels, je voulais quelque chose de plus léger, surtout pour la partie. Matt Pocock, connu pour ses cours TypeScript et son travail sur l'agentic coding, a publié sur GitHub un repo de skills qui a bcp fait parlé de lui. Chaque skill décrit un processus répétable : quand l'invoquer, les étapes à suivre, les pièges à éviter. Et comme c'est du markdown standard, ça marche avec OpenCode, Claude Code, Cursor ou Codex, sans être marié à un provider, ce qui tombait bien avec notre stack.

Pour ce projet, 4 skills ont structuré l'essentiel du travail :

• /grill-me : avant d'écrire la moindre ligne de code, l'agent m'interviewe sur le plan ou la décision en cours, et ne s'arrête que quand chaque branche de l'arbre de décision est résolue. C'est frustrant parfois (on a juste envie qu'il code, ce fichu agent), mais c'est redoutablement efficace pour éviter le retravail. Multi-tenant ? Il a fallu clarifier le modèle d'isolation des données, la stratégie de routing, ce qui arrive quand un utilisateur appartient à deux tenants... Autant de questions auxquelles j'aurais autrement répondu en API par défaut, à moitié, et payées plus tard.
• /to-spec : une fois l'alignement obtenu, l'agent synthétise la conversation en une spec (sans nouvelle interview, il formalise juste ce qu'on vient de discuter) et la publie dans le tracker. C'est la phase "spec" proprement dite : ce qui a remplacé la longue phase de planification de BMAD, mais en plus court et plus ancré dans le code réel. Dans la foulée, to-tickets découpe la spec en tickets, des tickets qui traversent toute la stack verticalement plutôt que couche par couche, avec leurs dépendances de blocage, poussés nativement dans Linear.
• /implement, pour lancer le travail sur les tickets. A vrai dire, avec un worflow de tickets et la connexion par mcp avec Linear, celui ci n'a pas servi longtemps. Par la suite, à chaque session, on parcourait le backlog, choisissait le ticket, sans forcément invouqer /implement
• /handoff, enfin, et c'est peut-être le plus précieux pour moi : il compresse la session en cours dans un document de passation, pensé pour qu'un autre agent, ou le même dans une session fraîche, puisse reprendre le travail sans rien perdre. La fenêtre de contexte se vidant à chaque session, ce document fait office de mémoire externe. Le soir, je ferme l'ordi, et plus tard dans la semaine on pouvait tout reprendre. Pocock appelle ça du "memento-driven development" : optimiser le codebase pour quelqu'un qui le redécouvre chaque matin, ce qui est exactement la condition de vie d'un agent.

Ressenti

• La grande avancée pour moi a été de pouvoir créer les tickets Linear, connecter ce dernier à Gitlab, et automatiser presque entièrement la chaine. J'ai ajouté aux worflow la demande de code-review par un autre modele et agent, et surtout un skill pour ajouter une demo.
• Dès lors, je pouvait choisir le ticket à implementer, donner juste à l'agent le numero de celui-ci, puis revenir quelques temps après pour voir la démo et pouvopir testé ce qui avait été developpé. Quelques retours mineurs plus tard, on pouvait relire le code, puis merger et la CI deployait l'app.
• L'autre bonne idée c'est /hand-off qui m'a permis de pouvoir abandonner un travail à 18h15 et de courir aller chercher les enfants sans cette injonction qu'on se crée souvent de devoir finir un travail, le fameux 'un dernier detail et j'y vais'. Ici c'est plutot le contraire, on reprend quelques jours après le handoff, et on a un petit résumé "Dans les épisodes précedents" qui n'aide pas que l'agent pour être honnête.
• Le /grill-me était moins profond mais plus technique que celui de BMAD. Un peu long encore, peut-être serait-il interessant aussi de pouvoir découper en sessions thématiques plus courtes, comme des réunions de travail, des ateliers. On tombe aussi parfois dans le meme travers de l'interview, on nous bombarde de questions et certaines sont parfois hardues, ou arrivent trop tôt dans la reflexion. Mais globalement l'experience a engrangé un rendu de qualité.
• La qualité des specs qui en sont sortis est assez bluffante. Et celle-ci a facilité l'implementation qui a coulé par la suite sans trop d'accrocs.
• Clairement l'UI, l'UX, le design ne sont pas trop le domaine de ces skills. Mais ce n'est pas très grave, on peut completer par des étapes intermédiaire et à l'inverse de BMAD on a l'espace pour que ca n'interfère pas ou ne bloque l'essentiel des specs plutot très techniques.
• Au final, le worflow était tellement bien rôdé que l'intervention humaine est à questionner. Si on a besoin de tickets JIRA pour pouvoir lancer ou reprendre une session de developpement, et globalement suivre le déroulé, on sent que les agents pas forcément. Ca peut les aider à structurer, mais on sent qu'au fond, ils pourraient s'en passer. Les notions de sprint, d'US, de tickets, d'agilité sont surtout et encore importantes pour nous, mais si on nous enleve l'execution et meme l'ecriture des tickets, on se retrouve assez vite assez secs.
• On voit que notre plus-value va se concentrer sur la conception d'une part, le test et la validation d'autre part, et je dirais quand meme l'UX, l'UI, le design qui sont encore des domaines où les specs ont un peu de mal à être générées par l'AI.

La suite

Les skills de Matt Pocock ont l'avantage de pouvoir être invoqués à tous niveau (ou presque) d'un developpement : bug, mini amélioration, grosse feature, gros projet, je les ai trouvé plus versatiles que BMAD, et donc avec des possibilités de customisation plus fortes pour s'adapter à votre worflow.

Celui-ci evolue de toute façon énormément à l'air l'agentique, et ces skills sont peut être autant destinées aux agents eux-memes que surtout à nous, pour garder un contrôle et nous rapprocher de ce qu'on connait, notamment en entreprise.

Reste encore quelques frictions (mêmes les frictions restent utiles pour garder la connection et l'interêt de ce que l'on fait), et des interrogations sur le sens de nos worflows et outils "classiques" de developpement, lorsque nous perdons la plupart de l'execution.

Et vient l'envie de customiser et experimenter encore un peu plus tout en exercant plus de contrôle. On verra cela dans le prochain article où on va tenter de se passer de "frameworks" existants, en écrivant nos propres skills , notre propres méthodes avec Hermes, sa mémoire et ses capacités d'auto-amélioration.

Pour aller plus loin

• Documentation Pocock : Skills sur AI Hero
• Le repo GitHub : mattpocock/skills