La qualité du code que je produis et la vitesse à laquelle je le produis sont littéralement dix fois supérieures à ce qu’elles étaient il y a un mois. Et ce changement tient simplement à une poignée de compétences que j’utilise dans le processus, dans l’ordre où je les passe en revue à chaque fois que je souhaite créer un logiciel, que ce soit en interne pour gérer mon entreprise ou en externe pour apporter de la valeur à mes clients.
- Dans cet article, je vais vous présenter en détail les compétences (skills) que j’utilise,
- comment vous pouvez les obtenir et les installer,
- ainsi qu’un nouveau mode « autopilote » et une sorte de version « yolo » de toutes ces compétences réunies.
Je les utilise avec Opencode, mon agent ia préféré, mais vous pouvez les utiliser avec Claude Code si vous tenez absolument à payer plus cher.
Au cœur de tout cela se trouve un concept appelé Ralph.
Si vous êtes développeur, vous en avez probablement déjà entendu parler. Il date de quelques mois et Ralph signifie « boucle autonome répétitive pour la gestion des PRD ».
Donc, « répétitive » signifie que les actions sont effectuées encore et encore, dans une boucle pour la gestion des PRD. Et PRD signifie « document d’exigences produit », c’est-à-dire un plan très précis sur la manière dont vous souhaitez générer du code.
Tout d’abord, un grand merci à Matt Pocock pour avoir créé les trois compétences originales présentées ici, ainsi que le concept de boucle Ralph et sa mise en œuvre. C’est lui qui m’a transmis tout cela. Donc, si vous ne suivez pas Matt sur GitHub, vous devriez vraiment le faire, car son travail est incroyable.
Mais en réalité, tout commence par une compétence appelée « grill me ». Si vous consultez le dépôt de Matt, vous pouvez voir la compétence « grill me ». Elle est d’une simplicité enfantine : elle tient en trois lignes. « Interrogez-moi sans relâche sur chaque aspect de ce plan jusqu’à ce que nous parvenions à une compréhension commune. Parcourez chaque branche de l’arborescence de conception en résolvant une à une les divergences entre les décisions. Pour chaque question, fournissez votre réponse recommandée. Posez les questions une par une. Si une question peut trouver sa réponse en explorant la base de code, explorez plutôt la base de code. » Il s’agit donc d’un remplacement du mode « plan » dans le code Claude.
Ainsi, vous exécuterez /grill me au lieu d’entrer en mode « plan » lorsque vous voudrez faire quelque chose. Nous allons parcourir tout ce processus dans un instant avec une fonctionnalité réelle que je vais développer pour l’un de mes produits. Mais je veux d’abord poser les bases de tout ce que nous allons faire ici.
Nous allons utiliser « grill me » pour mener des entretiens. Il vous posera des questions techniques, des questions de type « user story », des questions sur les modèles, les coûts, la tarification et toutes sortes de choses de ce genre. En général, Grill Me me pose entre 20 et 35 ou 40 questions. Et cela peut prendre une heure. Nous n’allons donc pas tout passer en revue aujourd’hui, mais nous allons lancer une session Grill Me pour que vous puissiez vous faire une idée de ce à quoi cela ressemble.
Une fois la session « Grill Me » terminée, place au document d’exigences
Nous disposons de tout le contexte dans un chat pour créer un document de spécifications produit, un PRD. Et la deuxième compétence ici est d’exécuter le PRD.
Pour le PRD, si nous allons sur le dépôt de Matt (et encore une fois, Matt a créé tout cela), je veux juste les partager avec vous, puis je vais vous montrer la version « autopilote » de tout ça.
- Donc, rédigez un PRD.
- Rédigez un document de spécifications produit qui résume tout le contexte que nous venons d’obtenir et le présente dans un format bien organisé pour que vous puissiez vous y référer, puis poussez-le sur GitHub.
- C’est comme un document de planification que vous auriez pu avoir localement, par exemple dans un dossier de planification sur votre ordinateur auparavant, mais il est créé sous forme de GitHub issue, ce qui est vraiment important car l’étape suivante consiste à transformer le PRD en issues.
Nous prenons ce plan gigantesque (imaginez un Google Doc d’environ cinq pages, très précis, très détaillé) et nous allons le décomposer en petits morceaux. Chacun de ces morceaux deviendra un ticket individuel sur GitHub. Nous aurons donc un PRD et peut-être des dizaines de tickets, selon l’ampleur de la fonctionnalité que nous développons. Cool.
Ensuite, c’est là que ça devient intéressant : nous allons lancer Ralph. Ralph signifie « boucle autonome répétitive pour la gestion des PRD ». Il va simplement sélectionner chaque ticket, effectuer le travail, le valider, le tester, puis passer au ticket suivant et répéter le processus : écrire le code, le tester, le valider. Il va continuer ainsi sans arrêt. Vous pouvez imaginer ce que nous allons faire ici : nous allons passer une heure à créer exactement ce que nous voulons construire.
- Il va documenter cela sous forme de PRD,
- le décomposer en tout petits morceaux,
- puis les traiter un par un, écrire le code et le valider.
Je vais créer un PRD, le décomposer en tickets. Puis, à 17 heures (comme c’est le cas en ce moment), je vais simplement lancer une boucle Ralph et elle va faire tout le travail. Ensuite, elle va intégrer le résultat dans Docker sur votre ordinateur.
Docker est en quelque sorte un bac à sable sécurisé où nous allons pouvoir nous permettre de prendre des risques dans le code Claude, par exemple en acceptant des autorisations dangereuses. Cela ne peut pas vraiment endommager tout votre ordinateur, car c’est dans un bac à sable dans le code Claude. Dans Docker, pardon.
Les quatre étapes et ma touche personnelle : Shape
Ensuite, là où j’ai ajouté ma petite touche personnelle, c’est une nouvelle compétence appelée « shape ».
« Shape », c’est en gros « grill me » en mode automatique. Ça va passer en revue toutes les questions, y répondre tout seul, puis créer le PRD pour vous automatiquement. D’accord ? Donc, à la première étape ici, vous pouvez faire « grill me » puis rédiger un PRD, ou vous pouvez simplement faire « shape », qui exécute « grill me » automatiquement et rédige le PRD. Cool.
Passons au terminal
J’ai déjà installé Shape. Je vais donc simplement taper /shape. Je vais parler dans le micro et utiliser Turbo Whisper pour dicter le type de fonctionnalité que je souhaite développer.
Je souhaite créer un résumé hebdomadaire envoyé par e-mail aux utilisateurs, présentant les performances de leur chaîne YouTube au cours de la semaine précédente. Cela permettra d’extraire les données analytiques de leur chaîne et de fournir les performances des vidéos ainsi que les valeurs aberrantes, en particulier des éléments tels que le taux de rétention et le taux de clics, ainsi que toutes les métriques importantes auxquelles les créateurs de contenu YouTube doivent prêter attention.
Il contiendra les données de leur chaîne et des vidéos qu’ils ont publiées la semaine précédente. De plus, il sélectionnera les vidéos les plus performantes de leur niche et nous devrions examiner la section « concurrents » de leur chaîne pour identifier des vidéos performantes de leur niche dont ils n’auraient peut-être pas eu connaissance.
Je mets à jour ou crée vos articles personnellement, assisté par l'IA, avec optimisation SEO incluse.
| 📝 Mise à jour | 14 € |
| ✨ Création | 49 € |
L’e-mail devrait être configurable pour être envoyé le jour et à l’heure de leur choix, mais nous pouvons le régler par défaut sur le lundi matin à 7 h, heure locale. Cet e-mail sera envoyé via notre plateforme d’envoi d’e-mails habituelle, qui est Bento, et sera en texte brut avec un peu de mise en forme.
Nous avons donc exécuté la commande shape et nous venons de définir tout un tas de paramètres ici, puis nous allons appuyer sur Entrée. Et il contient tout ce que je viens de dire. Maintenant, ce qu’il va faire, c’est explorer la base de code, car c’est ce que dit la compétence : si vous pouvez répondre à la question, regardez d’abord dans la base de code. Il va donc analyser l’intégralité de la base de code et trouver tout ce qui pourrait avoir un rapport avec les e-mails, l’API YouTube, la planification, le suivi de la concurrence, etc. Donc, tous les éléments contextuels qu’il estime devoir connaître d’après ce que je viens de dire.
Une fois cela fait, il va commencer à se poser ces questions. Par exemple :
« Et le modèle de données ? Dois-je inclure d’autres API ou services externes ? Dois-je ajouter une table de base de données ici ? Dois-je ajouter un élément d’interface utilisateur ? Dois-je demander l’autorisation des utilisateurs pour quoi que ce soit ? »
Vous verrez qu’il va commencer à se poser ces questions, puis y répondre automatiquement.
Et c’est là la véritable différence entre Shape et Grill Me
Si vous utilisez Grill Me, il vous posera ces questions une par une. Et souvent, je me contente de suivre ses recommandations. C’est pourquoi j’apprécie Shape : dans 90 % des cas, je me contente de suivre ce que le code Claude juge être le mieux. Je pense que c’est une meilleure façon de générer du code, car il passe par un processus consistant à lire l’intégralité de la base de code, à comprendre ce qui se passe d’un point de vue contextuel par rapport à ce que nous essayons de construire, puis à réfléchir à tous ces cas limites et scénarios, et à proposer des bonnes pratiques basées sur tout ce qu’il sait de l’écriture de logiciels.
Une fois qu’il aura terminé, il va commencer à se poser des questions, puis y répondre en s’appuyant sur les meilleures pratiques des développeurs logiciels très expérimentés. À la fin, nous aurons un document complet sur les exigences du produit que nous pourrons simplement consulter et, si nous voulons le modifier, nous pourrons le faire. Sinon, nous pouvons passer aux étapes suivantes, qui consistent à transformer le cahier des charges en tickets, c’est-à-dire à créer des tickets individuels à partir de ce document. Ensuite, nous pourrons lancer la boucle Ralph. Super.
Exploration terminée, l’IA se pose les bonnes questions
Maintenant, il va commencer à se poser des questions. Du genre : « Hé, que dois-je faire quand telle chose se produit ? » ou « Et dans ce scénario ? » et « Et dans ce cas limite ? ». Il va simplement y répondre et rassembler tout cela dans un document une fois qu’il aura terminé.
- Qui sont les acteurs concernés par cette fonctionnalité ? Tous les clients.
- Cela devrait-il étendre la tâche existante d’envoi de résumé par l’agent ?
- Quelle infrastructure de planification est déjà en place ? Bon, on a déjà tout ça en place. Donc, au lieu de me poser ces questions et que je lui donne une réponse, il se pose en quelque sorte les questions lui-même et les documente au fur et à mesure.
Je lui demande de faire en sorte que le skill affiche intentionnellement toutes les questions et les réponses. Pendant qu’il réfléchit, je peux parcourir tout ça et me dire : « Hmm, je ne pense pas que celle-ci soit tout à fait correcte. » Je peux donc me dire : « Hé, ta réponse à cette question n’est pas correcte. Je veux que tu la modifies. » Au lieu de passer en revue chaque question une par une pour y répondre manuellement ou simplement accepter ce qu’il dit la plupart du temps, j’accepte simplement ce qu’il propose par défaut, et s’il y a une exception où je dois le corriger, je peux le faire.
Installer et utiliser la compétence PRD to issues
Je n’avais jamais utilisé la compétence « PRD to issues » auparavant. Je l’ai donc chargée dans la fenêtre de terminal standard.
Il suffit d’exécuter cette commande : NPX skills latest Matt Pocock (c’est de là qu’elle vient) pour passer du PRD aux issues. Un générateur interactif s’affiche alors. Je dis que je veux charger cette compétence, uniquement dans ce projet, et je vais créer un lien symbolique pour que si Matt modifie la compétence, elle se mette automatiquement à jour. Et ça a fonctionné, c’était génial.
Ensuite, si vous êtes dans un projet Claude Code actif, vous devez redémarrer, quitter puis relancer Claude Code pour charger une nouvelle compétence. J’ai dû faire ça, puis j’ai utilisé cloud-c depuis le terminal pour redémarrer la session précédente afin de conserver tout le contexte.
Si votre ordinateur redémarre ou quelque chose comme ça, dans le terminal normal (pas dans Claude Code), tapez simplement cloud-c pour le redémarrer. Une fois cela fait, je peux lancer la transformation du PRD en tickets. Cela va créer des tickets pour chacune des petites tâches que nous voulons accomplir à partir du PRD.
Une petite fenêtre de confirmation s’affiche alors : « Voulez-vous pousser cela vers GitHub issue ? » Répondez oui, tout simplement. Ensuite, lancez « PRD to issues ». L’outil sait que nous parlons de ce PRD.
Ce qu’il va faire, c’est parcourir tout le document et se demander :
« Comment découper ce gros travail en petits morceaux individuels concis pour pouvoir lancer la boucle Ralph dessus ? »
Rappelez-vous : la boucle Ralph est entièrement autonome. Elle fonctionne en mode AFK (loin du clavier). Vous allez lancer ça et revenir quelques heures plus tard, et tout sera terminé. Il est donc crucial que la documentation et la portée de chaque ticket soient vraiment précises.
La boucle Ralph, telle que je l’implémente dans cet ensemble de compétences, intègre du développement piloté par les tests et révise son propre code. Vous n’avez pas besoin de savoir tout ça : il suffit de laisser faire et tout s’installe tout seul. Et si vous êtes perdu, pointez simplement Claude Code vers ça (c’est open source) et dites : « Fais tout ça. Je veux que ça marche. » Vous aurez besoin de Docker sur votre ordinateur, c’est entièrement gratuit.
Une fois le découpage terminé, PRD to issues annonce : « Super. Je vais diviser ça en quatre parties. Ça te va ? » Je réponds « Oui, tout ça me va très bien. » Il va alors créer tout un tas de tickets sur GitHub, en les classant par ordre de dépendance : d’abord un et deux en parallèle, puis trois et quatre. C’est pratique, car lorsque vous utiliserez votre boucle Ralph plus tard, elle saura si un ticket est bloqué ou dépend d’un autre, et elle choisira le bon en conséquence. Et c’est tout.
- A lire sur notre blog ⇒ OpenCode, agent IA open source pour terminal mieux que Claude Code
- ⇒ OpenClaw : l’urgence d’adopter l’IA avant d’être dépassé
Nous sommes passés d’une simple idée à un plan très détaillé, puis à de petites tâches individuelles faciles à gérer
Une fois cela fait, il faudra probablement environ 10 ou 15 minutes pour créer tous ces tickets. Puis, nous n’aurons plus qu’à lancer Ralph. Et si vous voulez lancer Ralph en mode AFK en indiquant simplement le numéro de ticket de votre PRD, il le récupérera avec tous les tickets individuels liés, et il s’occupera de tout. Vous reviendrez quelques heures plus tard, et toute la fonctionnalité sera terminée. C’est plutôt fiable, car il vérifie son code au fur et à mesure.
J’espère que vous l’essaierez et que ça vous plaira. Que ce soit le cas ou non, n’hésitez pas à laisser un commentaire pour me dire ce que vous en pensez. C’est open source, vous pouvez donc créer une pull request et y contribuer.
Je tenais à partager ça avec vous, car je trouve que Grill Me, le PRD, les tickets et la boucle Ralph sont vraiment intéressants.
