vibe-coding-prompt-template : un enchaînement de prompts pour cadrer un MVP avant d'écrire du code

Ce que la séquence remplace vraiment

Le problème visé n'est pas l'écriture du code. Le README le formule ainsi : l'IA sait écrire du code, la difficulté est de décider quoi construire, de vérifier ce qui fonctionne et de se remettre d'une casse. Le dépôt s'adresse donc à des personnes qui ont une idée d'application et un agent conversationnel sous la main, mais pas de méthode pour transformer l'idée en périmètre tenable. La cible annoncée inclut les débutants, via le topic beginner-friendly, et les développeurs qui utilisent Cursor, Claude Code, Codex ou Gemini CLI. La séquence compte cinq étapes réparties en deux phases : recherche, PRD et tech design se font dans un outil de chat, sans dépôt ; la génération des fichiers d'agent et la construction se font dans l'IDE. Le README mentionne des projets construits avec ce flux, dont vibeworkflow.app, moneyvisualiser.com, caglacabaoglu.com et RealDex App. Ce sont des exemples cités par l'auteur, pas une mesure d'adoption.

Le mécanisme : des fichiers de prompt, pas un moteur

Il n'y a pas de moteur d'orchestration derrière. Le dépôt contient des fichiers markdown à copier-coller : part1-deepresearch.md, part2-prd-mvp.md, et selon le même schéma les étapes suivantes. Vous copiez le contenu d'un fichier, vous le collez dans ChatGPT, Claude.ai ou Gemini, l'IA pose des questions de clarification, vous répondez, elle produit un document, vous le sauvegardez sous un nom du type research-[YourAppName].md. L'étape suivante consomme ce document, soit dans le même fil de discussion, soit dans un nouveau fil où vous collez d'abord la recherche puis le prompt du PRD. Le README insiste sur ce point : si votre outil de chat gère la recherche web, il faut l'activer et exiger des affirmations sourcées avec date d'accès. La traçabilité des sources dépend donc entièrement de l'outil choisi, pas du dépôt. C'est une chaîne de fichiers texte dont la cohérence repose sur la discipline de l'utilisateur.

La CLI vibeworkflow et les commandes d'agent

La partie exécutable arrive à l'étape 4. Le README donne l'instruction à transmettre à l'agent : Run npx vibeworkflow and follow its instructions. Le paquet npm s'appelle vibeworkflow. Selon la description du dépôt, la CLI inspecte ce qui existe déjà dans le dossier, puis propose trois routes : démarrer quelque chose de nouveau, continuer un projet existant, ou intervenir sur une panne. Trois niveaux de planification sont annoncés, Quick, Guided et Deep, avec des questions proportionnées à la taille du projet. Le README précise aussi que les commandes /vibe-change, /vibe-debug et /vibe-verify sont disponibles dans un projet existant, à partir de vibeworkflow 0.3.0. Le fichier AGENTS.md et le dossier agent_docs/ sont générés à cette étape. Un exemple exécutable est fourni sous examples/reading-list/README.md. Je n'ai pas exécuté cette CLI : ce qui précède vient de la documentation du dépôt et des notes de version, et le détail de ce que la CLI écrit réellement dans agent_docs/ n'est pas décrit dans le matériel fourni.

Ce que les notes de version indiquent sur la trajectoire

Trois versions récentes sont listées : v3.1.0 intitulée The Agent-First Release en août 2026, v3.0.0 intitulée The Contracts Release en juillet 2026, et v2.4.0 intitulée Audit & Hardening en avril 2026. Les intitulés seuls ne disent pas ce qui a changé, et le contenu des notes de version n'est pas fourni ici. On peut seulement constater que le projet bouge vite : trois versions majeures ou mineures en cinq mois, avec un déplacement apparent vers les agents. Pour un utilisateur, cela signifie que les fichiers de prompt et les commandes peuvent changer entre deux lectures du README. Si vous épinglez une version du paquet npm pour votre équipe, vérifiez la correspondance entre cette version et les fichiers markdown du dépôt au moment où vous les copiez, car rien dans le matériel fourni ne garantit que les deux évoluent ensemble.

La limite : le dépôt ne valide rien

Le point faible est structurel. Toute la phase 1 produit des documents en langage naturel, et rien dans le dépôt ne vérifie que le PRD correspond à ce qui sera construit, ni que le tech design tient debout. Le README parle lui-même de vérification et de récupération après casse, ce qui suppose que la casse arrive. Un utilisateur qui saute l'étape de recherche parce que son outil de chat n'a pas accès au web obtient, d'après le README, un prompt de recherche à exécuter ailleurs : la qualité de l'étape 1 dépend alors d'un outil tiers. Autre cas où l'outil est mal adapté : si votre spécification est déjà écrite et validée en interne, la séquence complète vous fait refaire un travail de cadrage déjà fait, et les questions de clarification deviennent du bruit. Le dépôt est aussi explicitement orienté vers les agents conversationnels ; une équipe qui n'en utilise pas n'a accès qu'à la moitié copier-coller du flux, sans la CLI ni les commandes /vibe-*.

Face à une spécification écrite à la main

L'alternative la plus directe n'est pas un autre outil de prompt, c'est un document de spécification rédigé sans LLM, du type PRD interne ou RFC, avec une relecture humaine avant tout code. La différence d'approche est nette. Ici, le contenu du PRD et du tech design est généré par le modèle à partir de vos réponses à ses questions, et la valeur vient de la structure imposée par les fichiers de prompt : recherche d'abord, périmètre ensuite, choix techniques après. Dans un RFC écrit à la main, c'est l'auteur qui décide de l'ordre et de ce qui mérite d'être tranché, ce qui coûte plus de temps mais laisse une trace de raisonnement que le modèle ne produira pas à votre place. Le compromis est donc entre vitesse de cadrage et profondeur d'arbitrage. Le dépôt ne prétend pas remplacer un comité de conception, et le README ne présente à aucun moment les documents générés comme validés.

Licence, maintenance et coût de mise à jour

Le dépôt est sous licence MIT, ce qui autorise la réutilisation, la modification et la redistribution, y compris dans un contexte commercial, à condition de conserver la notice de licence. Ce n'est pas un avis juridique : si vous intégrez les fichiers de prompt dans un produit distribué, faites vérifier la notice par qui de droit. Le coût de maintenance tient surtout à la nature du contenu. Les fichiers de prompt sont du texte que vous copiez dans votre propre dépôt ; une fois copiés, ils ne se mettent plus à jour tout seuls. La CLI, elle, s'installe via npx et suit donc la version publiée sur npm. Vous pouvez avoir des prompts figés à une ancienne étape et une CLI récente, sans avertissement. Le rythme de publication observé sur les trois dernières versions suggère de prévoir une relecture des fichiers après chaque montée de version majeure, en particulier autour de v3.x où le vocabulaire des agents semble avoir changé.

Conclusion éditoriale

À adopter si vous démarrez d'une idée encore floue et voulez un ordre de passage imposé avant de laisser un agent écrire du code : la séquence recherche, PRD, tech design, AGENTS.md est explicite et la licence MIT lève la plupart des questions d'intégration. À éviter si votre spécification est déjà écrite et validée, ou si votre équipe travaille sans agent conversationnel, car le dépôt est bâti autour de ce mode d'usage. Avant de vous engager, ouvrez part1-deepresearch.md et part2-prd-mvp.md et lisez-les en entier, puis lancez npx vibeworkflow dans un dossier de test pour voir comment il route un projet vide plutôt que de le supposer.

Sources officielles

1. KhazP/vibe-coding-prompt-template on GitHub
2. License: MIT
3. Project website
4. README
5. Releases