15 prompts Claude Code, un pour chaque étape d'un build

Quatre prompts avant d'écrire une ligne. C'est la phase que tout le monde saute, et c'est celle qui décide de tout le reste.

01. Écrire un PRD complet

Écris un PRD complet pour la fonctionnalité ci-dessous.

Fonctionnalité : [DÉCRIS LA FONCTIONNALITÉ]
Utilisateurs : [QUI S'EN SERT]
Stack : [TA STACK]

Inclus :
* L'énoncé du problème et les métriques de succès
* Les user stories avec leurs critères d'acceptation
* Le périmètre : ce qui sort en v1, ce qui ne sort pas
* Les changements de modèle de données
* Les cas limites et les états d'échec
* Les questions ouvertes auxquelles je dois répondre

Tiens en deux pages maximum. Sois précis, pas de remplissage.
Sauvegarde dans docs/prd-[fonctionnalite].md pour que tous les
prompts suivants puissent y renvoyer.

02. Créer ton CLAUDE.md

Lis tout ce dépôt, puis écris un CLAUDE.md.

Inclus :
* Ce qu'est ce projet, en deux lignes
* La stack technique et les versions qui comptent
* Les commandes : [DEV / BUILD / TEST / LINT]
* L'architecture : où vivent les choses et pourquoi
* Les conventions de code que tu détectes réellement dans le code
* Les règles dures : [TES NON-NÉGOCIABLES], ce qu'on ne touche
  jamais sans demander
* Les pièges qu'un nouveau développeur rencontrerait la première semaine

Écris les règles en impératifs courts. Rien de générique, uniquement
ce qui est vrai pour CE dépôt. Quand tu hésites sur une règle,
demande-moi au lieu de l'inventer.

03. Plan mode poussé

Passe en mode plan. N'écris AUCUN code pour l'instant.

Tâche : [COLLE LA TÂCHE]
Contraintes : [DEADLINE / STACK / ZONES INTERDITES]

1. Lis tous les fichiers que cette tâche touche, liste les avec une
   ligne sur ce que chacun fait aujourd'hui
2. Compare le comportement actuel au comportement visé
3. Propose deux ou trois approches avec leurs vrais arbitrages :
   complexité, risque, rayon d'impact
4. Choisis en une et justifie en trois lignes
5. Découpe en étapes assez petites pour être vérifiées une par une,
   chacune avec son propre contrôle
6. Liste les risques et le rollback exact de chacun
7. Signale tout ce qui touche [AUTH / PAIEMENTS / DONNÉES DE PROD]
   pour mon accord explicite

Puis arrête toi. Montre moi le plan et attends mon feu vert avant
de toucher le moindre fichier.

04. Développement piloté par la spec

On écrit la spec avant le code. Écris une spec pour : [FONCTIONNALITÉ]

Contexte : [QUI S'EN SERT ET POURQUOI MAINTENANT]

Format de la spec :
* Comportement : étant donné, quand, alors, pour chaque cas :
  chemin nominal, cas limites, états d'échec
* Contrat d'API : entrées, sorties, formes d'erreur, codes de statut
* Données : changements de schéma et migrations nécessaires
* États d'interface : chargement, vide, erreur, succès
* Hors périmètre : ce que cette spec écarte volontairement
* Checklist d'acceptation que je peux vérifier ligne par ligne

Une fois la spec validée, implémente EXACTEMENT la spec. Si la réalité
impose un écart, arrête toi, mets la spec à jour, obtiens mon accord,
puis continue. La source de vérité est la spec, pas le code.

05. Brief UI et UX complet

Crée un brief UI et UX complet pour : [ÉCRAN OU PARCOURS]

Audience : [UTILISATEURS]
Marque : [COULEURS / POLICES / TON]

Livre :
* Le parcours utilisateur dans le flux, étape par étape
* La mise en page par écran : hiérarchie, espacements, points de rupture
* L'inventaire des composants avec chaque état : survol, vide,
  erreur, chargement
* Les tokens de typographie et de couleur
* Le mouvement : ce qui s'anime, la durée, la courbe
* Les notes d'accessibilité

Étudie les patterns de [2 OU 3 PRODUITS QUE TU ADMIRES] pour la
direction. Ne les copie jamais.

06. Plan d'implémentation

Crée un plan d'implémentation pour : [SPEC OU PRD VALIDÉ]

Règles :
* Séquence les étapes pour que l'app compile et tourne après CHAQUE
  étape
* Chaque étape : fichiers touchés, ce qui change, comment je vérifie
  que ça marche
* Signale les étapes qui demandent une migration ou une nouvelle
  dépendance
* Mets les inconnues les plus risquées en premier
* Dimensionne chaque étape : [S / M / L]

Sors une séquence numérotée que je peux exécuter une étape à la fois.
Attends mon feu vert entre chaque étape.

07. Brancher un serveur MCP

Branche un serveur MCP pour : [SERVICE / API]

Ce dont j'ai besoin : [TÂCHES À COUVRIR]

1. Cherche d'abord un serveur officiel ou bien maintenu, et cite ta source
2. S'il en existe un : la commande d'installation exacte plus la config
   .mcp.json, limitée à ce projet
3. S'il n'en existe pas : construis en un avec le SDK MCP. Outils,
   authentification, gestion d'erreurs, réponses typées
4. Ajoute UNIQUEMENT les outils que je vais réellement utiliser : [LISTE]
5. Fais passer les secrets par [VARIABLES D'ENVIRONNEMENT], jamais de
   clé en dur dans le fichier de config
6. Vérifie la connexion et appelle un outil de bout en bout, montre moi
   la sortie
7. Documente chaque outil en une ligne pour que les sessions futures
   sachent quand y recourir

08. Connecter ta base de données

Connecte cette app à [POSTGRES / SUPABASE / TA BASE].

* Choisis le client qui convient à cette stack, justifie en une ligne
* Variables d'environnement : nomme les, ajoute les à .env.example,
  ne commit jamais les vraies valeurs
* Schéma : tables pour [ENTITÉS] avec types, relations, et index pour
  [REQUÊTES FRÉQUENTES]
* Crée et lance les migrations, et montre moi le rollback de chacune
* Un helper de requête typé par table, pas de SQL brut éparpillé dans
  les composants
* Règles d'accès et sécurité au niveau des lignes si c'est [MULTI-CLIENT]
* Pooling de connexions si on est en serverless

Puis prouve le : insère une ligne, relis la, montre moi la sortie.

09. Trouver les failles de sécurité

Audite ce dépôt à la recherche de failles. Attaque le comme si tu
voulais entrer.

Zones prioritaires : [AUTH / PAIEMENTS / DONNÉES UTILISATEURS]

Vérifie :
* Les secrets dans le code, la config, ou l'historique git
* Les injections : SQL, XSS, commandes, traversée de chemin
* L'authentification : routes sans contrôle, sessions faibles,
  redirections cassées
* IDOR : est ce que l'utilisateur A peut lire les données de B ?
* Les uploads de fichiers et la validation d'entrée sur chaque formulaire
* Les CVE des dépendances, lance l'audit et lis le
* Le rate limiting sur [ENDPOINTS COÛTEUX]
* Ce qui fuit par les messages d'erreur et les logs

Classe les trouvailles par gravité avec le fichier et la ligne exacts,
corrige les critiques maintenant, et liste le reste en tickets avec
une estimation d'effort.

10. Déboguer une erreur vite

Débogue cette erreur. Ne devine PAS.

Erreur : [COLLE L'ERREUR COMPLÈTE + LA STACK TRACE]
Quand ça arrive : [ÉTAPES POUR REPRODUIRE]

1. Lis la stack trace, ouvre les fichiers exacts concernés
2. Énonce le comportement attendu contre le comportement réel, en une ligne
3. Liste trois hypothèses, classées par probabilité
4. Prouve ou élimine chacune avec des logs ou un test minuscule.
   Des preuves, pas des intuitions
5. Corrige la cause racine, pas le symptôme
6. Cherche le même pattern dans le dépôt. Si ça casse ici, ça casse ailleurs
7. Ajoute un test de régression qui échoue sans le correctif
8. Dis moi en deux lignes pourquoi ça a cassé et pourquoi ça ne peut
   plus jamais casser comme ça

11. Tester ton application de bout en bout

Écris des tests Playwright de bout en bout pour : [PARCOURS]

Stack : [TA STACK]   CI : [GITHUB ACTIONS / AUTRE]

* Les parcours qui rapportent d'abord : [INSCRIPTION / PAIEMENT /
  ACTION PRINCIPALE]
* Teste ce que l'utilisateur voit, pas les détails d'implémentation
* Sélecteurs : rôles et libellés, jamais de chaînes CSS fragiles
* Un parcours en échec par flux : mauvaise saisie, panne réseau,
  session expirée
* Les tests restent indépendants : n'importe quel ordre, aucun état
  partagé, chacun crée ses propres données
* Headless en CI, avec interface en local pour déboguer
* Captures et traces uniquement en cas d'échec

Lance la suite, montre moi les résultats, corrige ce qui échoue, et dis
moi ce que la suite ne couvre toujours PAS.

C'est la phase que presque personne ne fait, et c'est elle qui sépare un projet qu'on reprend six mois plus tard d'un projet qu'on réécrit.

12. Nettoyer le code mort

Trouve et supprime le code mort dans ce dépôt.

Périmètre : [TOUT LE DÉPÔT / DOSSIER PRÉCIS]

* Exports, composants, hooks et utilitaires inutilisés
* Branches inatteignables et blocs commentés
* Dépendances de package.json que rien n'importe
* Feature flags figés en permanence sur on ou sur off
* Logique dupliquée qui devrait fusionner
* Classes CSS mortes et assets inutilisés

Vérifie par une recherche avant CHAQUE suppression : les imports
dynamiques et les références en chaîne de caractères comptent.
Supprime en petits commits, lance [BUILD + TESTS] après chacun, et
rapporte le total de lignes retirées plus tout ce dont tu n'étais
pas certain.

13. Écrire des commits git propres

Commit mes changements indexés proprement.

Convention : [CONVENTIONAL COMMITS / TON FORMAT]

* Sépare les changements sans rapport en commits distincts
* Format : type(scope): ce qui change et pourquoi.
  feat, fix, refactor, chore, docs, test
* Sujet sous 50 caractères, à l'impératif
* Le corps explique le POURQUOI, à la ligne à 72 caractères
* Référence le ticket : [ID-TICKET]
* Ne mélange jamais un refactor et un changement de comportement
  dans un même commit
* Ne commit jamais [SECRETS / .ENV / FICHIERS GÉNÉRÉS]

Montre moi le plan, les fichiers par commit plus les messages, avant
de commit quoi que ce soit. Puis commit un par un pour que je puisse
t'arrêter entre chaque.

14. Des hooks comme garde-fous

Mets en place des hooks Claude Code comme garde-fous ici.

Stack : [TA STACK + GESTIONNAIRE DE PAQUETS]

* PostToolUse : lance [LINT + TYPECHECK] après chaque édition de
  fichier, renvoie les erreurs directement
* PreToolUse : bloque les éditions sur [CHEMINS PROTÉGÉS :
  MIGRATIONS, .ENV, CONFIG DE PROD]
* Stop : lance [LA SUITE DE TESTS] avant la fin d'une session
* Notification : préviens moi avec [SON / SLACK] quand tu as besoin de moi

Écris les scripts de hook et les entrées settings.json. Garde chaque
script sous 20 lignes et sors en code non nul avec un message clair
pour que l'agent sache exactement quoi corriger. Puis déclenche chaque
hook exprès et montre moi qu'il se déclenche.

15. Transformer une tâche en skill

Transforme cette tâche répétitive en skill Claude Code.

La tâche que je refais sans arrêt : [DÉCRIS LA TÂCHE + LES ÉTAPES]

* Crée .claude/skills/[NOM]/SKILL.md
* Frontmatter : name plus description avec les phrases exactes que je
  dis vraiment pour la déclencher
* Corps : workflow numéroté, mes conventions, cas limites
* Ce qu'il doit me demander contre ce qu'il déduit tout seul
* À quoi ressemble "terminé"

Puis fais tourner le skill à blanc sur un exemple réel et affine
jusqu'à ce que la sortie corresponde à ce que je fais à la main.