L'ouvrier qualifié prend la feuille de route — la story que tu viens de valider — et se met au travail. Brique après brique, le mur monte. Ce n'est plus du papier, plus des plans, plus des discussions. C'est concret. Dans le navigateur, quelque chose qui n'existait pas hier commence à prendre forme. Toi, tu supervisises : tu vérifies que le résultat correspond à ta vision, tu dis ce qui te plaît et ce qui doit changer. C'est exactement le rôle du maître d'ouvrage.
Dans cette fiche, tu apprends le cycle complet story par story — de /clear jusqu'au commit. C'est ce cycle que tu vas répéter pour chaque fonctionnalité de ton app.
Voici le rythme à adopter pour chaque story. Il ne change pas. C'est sa répétition qui fait avancer le chantier.
1. Débarrasser la tableAvant chaque nouvelle story, tape :
La mémoire de Claude, c'est une table de travail. Si tu y empiles plusieurs conversations, plusieurs sujets, plusieurs erreurs accumulées, Claude perd le fil — et ses réponses deviennent approximatives. /clear remet la table à zéro. Tu repars sur une base propre.
Tes fichiers sont intacts. Seule la mémoire de la conversation est vidée. Tu peux /clear sans crainte.
Copie-colle le contenu du fichier story directement dans le chat. Pas juste le titre — le fichier entier. Claude a besoin des critères d'acceptation, des dépendances, des notes techniques.
Un exemple de message efficace :
Une fois que Claude a commencé, ne l'interromps pas toutes les 30 secondes. Il a un plan dans la tête, il suit des étapes. Si tu l'interromps avec "mais attends, et si..." en plein milieu, tu casses son élan et tu risques un résultat incohérent.
Si tu as une question, note-la. Tu la poseras quand Claude aura terminé.
4. Vérifier dans le navigateurLance ton app :
Ouvre http://localhost:3000 dans ton navigateur. Teste la fonctionnalité que Claude vient de construire. Est-ce que ça correspond à tes critères d'acceptation ? Est-ce que ça se comporte comme tu le voulais ?
5. Itérer si nécessaireSi quelque chose ne va pas — une couleur, un comportement, un texte — dis-le à Claude clairement. Un retour précis donne un résultat précis.
6. Faire un commit — "photo de chantier"Quand la story est validée, sauvegarde l'état de ton chantier :
Ce commit, c'est ta photo de chantier. Si quelque chose se casse dans les prochains jours, tu pourras revenir à cet état propre.
Voici à quoi ressemble un vrai échange pour implémenter une story.
Claude va répondre avec son plan avant de coder. Quelque chose comme :
"Je vais créer la page /projets avec un composant ProjectCard réutilisable. Les données seront dans un fichier de mock pour l'instant. Voici ce que je vais faire :
Tu n'as pas à comprendre chaque terme technique. Ce qui compte : Claude a compris la story, il a un plan, et il suit tes critères d'acceptation. Tu peux répondre "go" ou "attends, je veux aussi un bouton Créer en haut de page" avant qu'il commence.
Claude fait les ajustements. Tu retestes. Quand tu es satisfait, tu commites.
Ce n'est pas de la magie — c'est de la méthode. Une story claire donne un résultat prévisible. C'est exactement comme ça que travaillent les équipes qui livrent des projets dans les temps.
Après chaque story validée, sans exception :
Convention de nommage simple :
Ces commits sont ton filet de sécurité. Plus tu en fais souvent, plus le filet est serré. Si quelque chose se casse demain, tu retrouves facilement le dernier état propre.
La tentation est forte de tout commiter en bloc à la fin. Résiste. Un commit par story te permet de revenir exactement à l'état que tu veux, story par story.
Story validée, commit fait ? Lance la suivante.
Puis donne la prochaine story à Claude. Même cycle. C'est volontairement répétitif — c'est sa force. Chaque tour de boucle, une fonctionnalité de plus dans ton app.
| Symptôme | Cause probable | Solution |
|---|---|---|
| Claude part dans tous les sens et ignore les critères | La story n'était pas assez détaillée | Fais /clear, puis relance /brik:corriger story pour compléter la story avant de la redonner |
| L'app ne s'affiche pas dans le navigateur | npm run dev n'est pas lancé, ou erreur de démarrage | Vérifie le terminal — une erreur rouge ? Copie-colle l'erreur dans Claude |
| Le port 3000 est déjà utilisé (EADDRINUSE) | Une autre instance tourne | Ferme l'autre terminal ou utilise npm run dev -- --port 3001 |
| Claude s'arrête au milieu et attend | Il a une question bloquante | Réponds à sa question, puis demande-lui de continuer |
| Je vois du code mais l'app ne change pas | Le serveur doit être redémarré | Arrête npm run dev avec Ctrl+C et relance-le |
| Git dit "nothing to commit" | Les fichiers n'ont pas changé | Vérifie avec git status que tu es dans le bon dossier |
| Claude réimplémente quelque chose qui existait déjà | Contexte perdu (context rot) | /clear et redonne la story avec une note : "Ne touche pas à [fichier X], il fonctionne déjà" |
Le cycle tourne. Stories validées, commits réguliers. Mais tôt ou tard, quelque chose va casser — une erreur rouge dans le terminal, une fonctionnalité qui ne se comporte plus comme prévu. C'est inévitable, et c'est exactement pour ça qu'il y a une fiche suivante.
-> Fiche suivante : Quand ça casse