Votre application en Vibe Coding

La règle du jeu

Avant de commencer

• Le dépôt créé à l'atelier 1, avec AGENTS.md et PLAN.md (ou un dossier vide, initialisé avec git init).
• Votre agent ouvert dans ce dossier, en mode Agent.
• Ménagez votre quota gratuit : une nouvelle session par tâche, le modèle sur Auto. S'il s'épuise, passez sur le modèle local de l'atelier 1.
• Un fichier PROMPTS.md vide : vous y notez vos prompts au fil de l'atelier, ceux qui ont marché et ceux qui n'ont pas marché.

Étape 0 (facultative) · Un wireframe de votre écran principal

Si votre application a une interface, prenez 10 minutes pour en dessiner l'écran principal dans UX Pilot (offre gratuite) ou une alternative, puis faites une capture. Vous la joindrez au premier prompt de l'étape 1. Pour un outil en ligne de commande, écrivez plutôt un exemple de la sortie attendue.

Pas d'idée ? Un jeu façon Undercover

Étape 1 · Spec, plan, checklist

Le principe : ne jamais demander « code-moi l'application ». On passe d'abord par trois documents écrits, puis on code par petites étapes.

1. Affiner l'idée

Remplacez la dernière ligne par votre idée, en une ou deux phrases. Si vous avez fait l'étape 0, joignez la capture du wireframe au prompt : l'agent s'en servira pour la spécification. Répondez aux questions jusqu'à ce que l'agent n'en ait plus, ou jusqu'à ce que vous estimiez en avoir assez dit.

Pose-moi une seule question à la fois pour que nous construisions ensemble une spécification complète et détaillée de cette idée. Chaque question doit s'appuyer sur mes réponses précédentes. L'objectif final est une spécification assez précise pour être confiée à un développeur. Avançons pas à pas et creusons chaque point important. Ne code rien pour l'instant.
Rappel : une seule question à la fois.

Voici l'idée : [VOTRE IDÉE]

2. La spécification

Nous avons fini le brainstorming. Compile tout ce que nous avons décidé en une spécification complète, prête pour un développeur : besoins fonctionnels, choix d'architecture et de stack, données manipulées, gestion des erreurs, et plan de tests. Un développeur doit pouvoir commencer à coder immédiatement à partir de ce document.
Écris-la dans spec.md.

Relisez spec.md. Corrigez ce qui ne vous convient pas, à la main ou en le demandant. C'est le dernier moment où changer d'avis ne coûte rien.

3. Le plan

Deux variantes. Choisissez la variante TDD si vous voulez des tests dès la première étape (recommandé), la variante sans TDD pour un prototype rapide.

À partir de spec.md, rédige un plan de construction détaillé, étape par étape.
Découpe ensuite ce plan en petits morceaux qui s'appuient les uns sur les autres. Repasse sur ces morceaux pour les découper encore. Vérifie que chaque étape est assez petite pour être implémentée sans risque, avec de vrais tests, mais assez grande pour faire avancer le projet. Recommence jusqu'à ce que la taille des étapes soit juste.
Transforme enfin chaque étape en un prompt destiné à un agent de code, qui implémente l'étape en TDD : test d'abord, puis le code.
Contraintes : bonnes pratiques, progression incrémentale, tests le plus tôt possible, aucun saut de complexité. Chaque prompt s'appuie sur les précédents et se termine en branchant le nouveau code sur l'existant : pas de code orphelin.
Sépare chaque prompt dans sa propre section, en Markdown, et place le texte de chaque prompt dans un bloc de code.
Écris le résultat dans prompt_plan.md.

À partir de spec.md, rédige un plan de construction détaillé, étape par étape.
Découpe ensuite ce plan en petits morceaux qui s'appuient les uns sur les autres. Repasse sur ces morceaux pour les découper encore, jusqu'à ce que chaque étape soit assez petite pour être faite sans risque, mais assez grande pour faire avancer le projet.
Transforme enfin chaque étape en un prompt destiné à un agent de code.
Contraintes : bonnes pratiques, progression incrémentale, aucun saut de complexité. Chaque prompt s'appuie sur les précédents et se termine en branchant le nouveau code sur l'existant : pas de code orphelin.
Sépare chaque prompt dans sa propre section, en Markdown, et place le texte de chaque prompt dans un bloc de code.
Écris le résultat dans prompt_plan.md.

4. La checklist

À partir de prompt_plan.md, crée un todo.md que je peux utiliser comme checklist, avec une case à cocher par tâche. Sois exhaustif.

Commitez les trois fichiers : spec.md, prompt_plan.md, todo.md. Ils sont la mémoire du projet : si vous fermez la session, l'agent repart d'eux.

5. L'exécution

Ouvrez une nouvelle session (bouton + du chat ; dans Claude Code, /clear). Le brainstorming n'a plus besoin d'être dans le contexte, tout est dans les fichiers. Puis bouclez :

1. Envoyez le prompt de l'étape suivante.
2. Laissez l'agent coder et lancer les tests.
3. Lancez l'application vous-même et regardez ce qui a changé.
4. Si ça marche : cochez la case dans todo.md et commitez. Sinon : corrigez avant de passer à la suite.

Lis spec.md, prompt_plan.md et todo.md. Implémente la prochaine étape non cochée de todo.md, en suivant son prompt dans prompt_plan.md. Lance les tests et montre-moi leur résultat. Quand ils passent, coche la case dans todo.md et propose un message de commit. Arrête-toi après cette étape.

Quand ça bloque

Avec un chat en ligne, qui ne voit pas votre projet, il faudrait regrouper tout le code dans un seul fichier (avec repomix, par exemple) et le lui renvoyer. Un agent de code lit déjà le dépôt : donnez-lui plutôt le message d'erreur exact et ce que vous attendiez. Si l'agent tourne en rond, revenez au dernier commit qui marchait et reformulez l'étape plus petite.

Une fois l'application commencée : les prompts « code existant »

Trois autres prompts, pour un projet qui existe déjà. Ils vous serviront en fin d'étape 1, sur votre propre code.

Tu es un développeur senior. Fais une revue complète de ce projet, comme si tu la préparais pour un collègue. Pour chaque remarque, indique le fichier, les numéros de ligne et le contexte. N'invente rien : ne signale que ce que tu vois réellement dans le code. Écris la revue en Markdown dans code-review.md.

Tu es un développeur senior. Liste les principaux problèmes de ce projet : bugs, défauts de conception, code peu lisible. Rédige chacun comme un ticket GitHub : titre, description, fichier concerné, correction proposée. N'invente rien. Écris le résultat dans issues.md.

Tu es un développeur senior. Liste les cas de test qui manquent dans ce projet, en commençant par les plus risqués. Rédige chacun comme un ticket GitHub : ce qu'il faut tester, pourquoi, et le fichier concerné. Écris le résultat dans missing-tests.md.

Conseils

• Ne pas aller trop vite. Avec un LLM, on avance si vite qu'on finit par ne plus comprendre son propre projet. Les fichiers de plan, les tests et des pauses régulières vous ramènent au contrôle.
• Petites étapes et tests. Planifier, avancer par petits pas et tester gardent le développement assisté sous contrôle.
• Occuper l'attente. Pendant que l'agent travaille, préparez l'étape suivante.
• Une méthode solo. Elle est pensée pour un seul développeur : à plusieurs, les fusions et le contexte deviennent compliqués.
• Un point de départ. Ces prompts ne sont pas une recette figée : adaptez-les, et notez vos versions dans PROMPTS.md.

Étape 2 · Les bonnes pratiques de l'agent

Source principale : la page Best practices for Claude Code d'Anthropic. Ses principes valent pour tout agent de code. Cette fiche les applique à Copilot en mode agent dans VS Code, l'outil gratuit de la journée ; les équivalents pour Claude Code et Junie sont en fin d'étape. Le point de départ de la documentation : dans la plupart des cas, un prompt simple dans une session neuve fait déjà la bonne chose. Les bonnes pratiques servent quand votre projet a des connaissances, des règles ou des contraintes que l'agent ne peut pas deviner en lisant le code.

Le travail de l'étape : appliquez ces pratiques à votre application, puis ajoutez une deuxième fonctionnalité en les utilisant.

Instruction ou configuration ?

La documentation distingue deux familles :

• Non déterministe : votre prompt, AGENTS.md, une skill. Le modèle lit et décide. Il suit presque toujours, sans garantie.
• Déterministe : un hook, le bac à sable. L'outil l'applique à chaque fois, quoi que décide le modèle.

Par défaut, laissez l'agent décider. Réservez le déterministe à ce qui doit arriver toujours (ou jamais). Si vous ajoutez « IMPORTANT » à une ligne d'AGENTS.md et qu'elle est encore ignorée, elle devrait être un hook.

1. Dire à l'agent ce qu'il ne voit pas

L'agent lit très bien un dépôt. Il ne peut pas connaître ce qui n'y est pas : une décision prise en réunion, une procédure qui est dans votre tête, une variable d'environnement. Avant d'écrire quelque chose pour lui, posez-vous deux questions : pourrait-il le trouver en lisant le code ? Irait-il vraiment chercher ? Si les deux réponses sont oui, ne l'écrivez pas.

Un prompt précis

Nommez le fichier, décrivez le symptôme, dites à quoi ressemble « réparé ».

• Donnez la chose plutôt que sa description : #file:chemin/du/fichier (ou glissez le fichier dans le chat), une capture d'écran collée dans le prompt (maquette, erreur), ou la sortie exacte d'une commande, copiée depuis le terminal.
• « Réfléchis étape par étape » ou « sois exhaustif » ne sont que du texte. Sur Copilot Free, le modèle est choisi automatiquement : la précision du prompt est votre principal levier.
• « Sois ambitieux » aide vraiment : les agents lisent les demandes de façon prudente et construisent le minimum. Si vous voulez la version complète, dites-le :

Construis la page de paramètres à partir de la maquette. Sois ambitieux : états vide et erreur, enregistrement branché, navigation au clavier, pas seulement la mise en page.

Pour explorer plutôt que corriger, un prompt vague comme « qu'est-ce que tu améliorerais dans ce fichier ? » convient très bien.

Brainstormer d'abord : l'interview

C'est l'équivalent natif des prompts 1 et 2 de l'étape 1. Utilisez-le pour votre deuxième fonctionnalité, de préférence avec l'agent Plan :

Je veux ajouter [VOTRE FONCTIONNALITÉ] mais je n'y ai pas encore bien réfléchi. Interroge-moi, une question à la fois, jusqu'à pouvoir écrire la spécification, puis écris-la dans SPEC.md.

Ensuite, ouvrez une nouvelle session (bouton + du chat) pour construire : le travail démarre avec un contexte propre et une définition écrite de « terminé ». Une session neuve consomme aussi moins de quota qu'une longue conversation.

Un AGENTS.md court

Vous avez écrit AGENTS.md à l'atelier 1. Il est chargé à chaque requête : chaque ligne prend un peu d'attention, sur chaque tâche. Relisez-le et n'y gardez que :

• comment vérifier le travail : les commandes exactes de test, de typecheck et de lint, et comment lancer un seul fichier de test ;
• les endroits où le code est trompeur (un vieux modèle à ne pas copier, un dossier qui a l'air inutilisé mais ne l'est pas) ;
• les décisions qui ne sont pas dans le dépôt ;
• tout ce que vous avez déjà dû corriger deux fois.

# Commandes
- Installer : pnpm install
- Lancer un fichier de test : pnpm vitest run chemin/du/fichier.test.ts
- Typecheck : pnpm tsc --noEmit

# Conventions
- Utiliser les helpers d'erreur de src/lib/errors.ts, jamais de chaîne brute

# Pièges
- Les tests d'intégration ont besoin de DATABASE_URL, voir .env.example

• Vérifiez qu'il est chargé : AGENTS.md apparaît dans les références de la réponse.
• Avec Claude Code : le même contenu va dans CLAUDE.md (ou une seule ligne @AGENTS.md pour réutiliser le fichier). /init en génère une première version à partir du code, /context confirme qu'il est chargé, et vos préférences personnelles vont dans CLAUDE.local.md, ajouté au .gitignore.
• Une règle qui ne concerne qu'une partie du code va dans .github/instructions/<nom>.instructions.md, avec un filtre applyTo: "src/api/**" dans l'en-tête.
• Une procédure que vous lancez vous-même (publier une version, écrire la doc) va dans un fichier de prompt, .github/prompts/<nom>.prompt.md, appelé par /<nom> dans le chat. Une procédure que l'agent doit pouvoir déclencher seul va dans une skill : .github/skills/<nom>/SKILL.md.
• Les outils externes : un serveur MCP, comme à l'atelier 1.

2. Donner à l'agent une vérification à lancer

L'agent s'arrête quand le travail a l'air fini. Sans rien à lancer qui réponde « réussi » ou « échoué », c'est vous qui devenez la suite de tests. Avec une vérification, il boucle seul : il modifie, lance, lit l'erreur, corrige, relance.

La vérification peut être un fichier de test, le code de sortie d'un build, un linter, un script qui compare une sortie à une référence, ou une capture d'écran du navigateur à côté de la maquette.

Demandez toujours des preuves : la commande lancée et sa sortie, ou la capture. « Tous les tests passent », seul, ne dit presque rien.

Un relecteur qui ne peut rien modifier

---
description: Relit les fichiers modifiés par rapport à la spec dont ils sont issus. À utiliser après une fonctionnalité, avant le commit.
tools: ['search', 'read']
---
Tu relis du code que tu n'as pas écrit. Compare les fichiers modifiés à la spec fournie,
vérifie que chaque exigence est implémentée et que les cas limites listés ont des tests,
et ne signale que les écarts qui touchent à la correction. Ignore le style.
Tu ne modifies aucun fichier.

---
name: reviewer
description: Relit les fichiers modifiés par rapport à la spec dont ils sont issus. À utiliser après avoir implémenté une fonctionnalité, avant d'ouvrir la PR.
tools: Read, Grep, Glob
---
Tu relis du code que tu n'as pas écrit. Compare les fichiers modifiés à la spec fournie,
vérifie que chaque exigence est implémentée et que les cas limites listés ont des tests,
et ne signale que les écarts qui touchent à la correction. Ignore le style.

Avec Claude Code, demandez : « Utilise le sous-agent reviewer pour relire le diff de [FONCTIONNALITÉ] par rapport à SPEC.md. » /code-review fait une relecture comparable sans configuration.

Avec Copilot, ouvrez le fichier : le bouton Configurer les outils au-dessus de l'en-tête permet de vérifier que seuls des outils de lecture sont cochés. Puis, dans une nouvelle session, choisissez l'agent relecteur dans le sélecteur et envoyez :

Relis les modifications de [FONCTIONNALITÉ] (git diff) par rapport à SPEC.md : vérifie que chaque exigence est implémentée et que les cas limites listés ont des tests. Ne signale que les écarts qui touchent à la correction du code, ignore le style.

Gardez « ignore le style » : un relecteur à qui l'on demande des problèmes en trouvera toujours. Tout corriger mène à des couches d'abstraction en trop et à des tests de cas impossibles.

Exemple de hook de fin (aperçu)

Les hooks de VS Code sont en aperçu : le format peut changer, testez-le sur votre version. Ce script demande Node.js ; remplacez npm test par votre commande (pytest, cargo test, mvn -q test…).

{
  "version": 1,
  "hooks": {
    "agentStop": [
      { "type": "command", "command": "node .github/hooks/verifier.cjs", "timeoutSec": 120 }
    ]
  }
}

const { execSync } = require('node:child_process');

let entree = '';
process.stdin.on('data', (morceau) => (entree += morceau));
process.stdin.on('end', () => {
  // Déjà relancé une fois par ce hook : on laisse l'agent s'arrêter.
  if (/"stop_hook_active"\s*:\s*true/.test(entree)) return;
  try {
    execSync('npm test', { stdio: 'pipe' });
  } catch (erreur) {
    const sortie = String(erreur.stdout || '') + String(erreur.stderr || '');
    console.log(JSON.stringify({
      decision: 'block',
      reason: 'Les tests échouent. Corrige-les avant de terminer :\n' + sortie.slice(-2000)
    }));
  }
});

Le champ stop_hook_active évite une boucle sans fin quand les tests ne peuvent jamais passer : ici, l'agent est relancé une seule fois. Si le hook ne se déclenche pas sur votre version, la vérification dans le prompt suffit pour l'atelier.

3. Imposer les règles sans exception

« Ne jamais lire .env », « toujours formater après une modification », « ne pas toucher aux migrations » : l'agent les suit presque toujours. Quand « presque » ne suffit pas, sortez-les d'AGENTS.md.

Un hook qui interdit

Un hook preToolUse est lancé avant chaque outil. S'il répond deny, l'outil n'est pas appelé, quel que soit le niveau de permission. Ici, toute action qui mentionne un fichier .env est refusée.

{
  "version": 1,
  "hooks": {
    "preToolUse": [
      { "type": "command", "command": "node .github/hooks/proteger-env.cjs", "timeoutSec": 10 }
    ]
  }
}

let entree = '';
process.stdin.on('data', (morceau) => (entree += morceau));
process.stdin.on('end', () => {
  if (/\.env\b/.test(entree)) {
    console.log(JSON.stringify({
      permissionDecision: 'deny',
      permissionDecisionReason: "Les fichiers .env sont interdits à l'agent."
    }));
  }
});

Testez : « Affiche le contenu de .env ». L'agent doit recevoir le refus et vous l'expliquer. Si le script plante, l'appel est refusé ; s'il dépasse son délai, les permissions normales s'appliquent.

Les approbations du terminal

{
  "chat.tools.terminal.autoApprove": {
    "/^git (status|diff|log)\\b/": true,
    "git push": false,
    "rm": false
  }
}

Les commandes à true passent sans demander, celles à false demandent toujours votre accord. Rappel : demander n'est pas interdire.

• Le bac à sable (chat.agent.sandbox.enabled) limite l'accès des commandes au système de fichiers et au réseau, même en « Allow all ». En aperçu sur macOS, Linux et WSL2, expérimental sous Windows.
• Gardez peu de règles imposées : une préférence comme « préférer les exports nommés » a des exceptions et reste dans AGENTS.md.

4. Changer un réglage

• Niveau de permission. Par défaut, VS Code applique vos réglages d'approbation (« Manual permissions »). « Allow all » et Autopilot exécutent tout sans demander : restez en manuel pendant l'atelier.
• Mode plan. L'agent Plan lit et propose une approche sans rien modifier : utile pour cadrer une fonctionnalité avant de coder.
• Modèle. Sur Copilot Free, le choix est automatique. Avec un abonnement, un modèle plus rapide pour un premier jet, un plus puissant pour un bug dans du code que vous n'avez pas écrit.
• Quota. Le menu Copilot de la barre d'état montre votre consommation. Une nouvelle session entre deux tâches sans rapport coûte moins qu'une conversation qui s'allonge.

5. Piloter la session

Regardez la première minute. Arrêtez l'agent dès qu'il dérive. Après deux corrections ratées, une nouvelle session et un meilleur prompt plutôt qu'une troisième correction.

Ce que vous pouvez arrêter de faire

Avec un autre agent

Les principes restent les mêmes, seuls les noms changent.

{
  "hooks": {
    "Stop": [
      {
        "hooks": [
          { "type": "command", "command": "pnpm tsc --noEmit 1>&2 || exit 2" }
        ]
      }
    ]
  },
  "permissions": {
    "allow": ["Bash(pnpm tsc --noEmit)"],
    "ask": ["Bash(git push *)"],
    "deny": ["Read(./.env)", "Read(./.env.local)", "Read(./secrets/**)"]
  }
}

Étape 3 (bonus) · Avec un plugin : Superpowers

Superpowers (Jesse Vincent, licence MIT) est un ensemble de skills pour les agents de code. Il automatise une bonne partie de ce que vous venez de faire à la main : le brainstorming, le plan découpé en petites tâches, le TDD, la relecture. Les skills se déclenchent seules, au bon moment.

Installation avec Copilot (VS Code)

Superpowers ne documente officiellement, côté Copilot, que Copilot CLI (copilot plugin marketplace add obra/superpowers-marketplace, puis copilot plugin install superpowers@superpowers-marketplace) : c'est la voie la plus sûre si vous travaillez en CLI. Dans VS Code, deux voies, à tester avant de s'y fier.

Voie 1 · le plugin, avec les plugins d'agent de VS Code (fonction en aperçu ; VS Code lit le format de plugin de Claude Code, sans garantir que tous ses composants fonctionnent). Dans les réglages :

"chat.plugins.enabled": true,
"chat.plugins.marketplaces": ["obra/superpowers-marketplace"]

Puis installez Superpowers depuis la vue Extensions (filtre @agentPlugins) ou la commande « Chat: Plugins ». Autre possibilité : la commande « Chat: Install Plugin from Source », avec l'adresse https://github.com/obra/superpowers. Un plugin peut contenir des hooks qui exécutent du code sur votre machine : n'ajoutez que des sources que vous avez vérifiées.

Voie 2 · copier les skills (la plus simple, et la seule qui ne dépend d'aucune fonction en aperçu). Les skills de Superpowers suivent le format ouvert Agent Skills, que VS Code lit dans .github/skills/. Récupérez le dépôt à côté de votre projet, puis copiez ses skills :

git clone --depth 1 https://github.com/obra/superpowers ../superpowers
mkdir -p .github/skills
cp -r ../superpowers/skills/* .github/skills/

git clone --depth 1 https://github.com/obra/superpowers ../superpowers
New-Item -ItemType Directory -Force .github/skills
Copy-Item -Recurse ../superpowers/skills/* .github/skills/

Installation dans Claude Code (avec un abonnement)

/plugin install superpowers@claude-plugins-official

/plugin marketplace add obra/superpowers-marketplace
/plugin install superpowers@superpowers-marketplace

Le cycle de base

Les autres skills : systematic-debugging, verification-before-completion, dispatching-parallel-agents, receiving-code-review, writing-skills, using-superpowers, diagnosing-superpowers.

Le travail de l'étape

1. Installez les skills (ou le plugin) et ouvrez une nouvelle session.
2. Décrivez une troisième fonctionnalité en une phrase, sans autre consigne. Laissez les skills se déclencher (avec Copilot, demandez d'abord la skill brainstorming).
3. Comparez avec les étapes 1 et 2.

Les trois façons, côte à côte

Livrables et démo

• Le dépôt, avec un commit par étape qui marche.
• spec.md, prompt_plan.md, todo.md (étape 1) et SPEC.md, AGENTS.md, .github/hooks/ (étape 2).
• PROMPTS.md : vos prompts, ceux qui ont marché et ceux qui non.
• La liste de vos corrections humaines : ce que l'agent n'aurait pas trouvé seul.