Bibliothèque de prompts

Quand tu veux restructurer du code existant sans changer son comportement.

Refactore <FICHIER/MODULE> pour améliorer <OBJECTIF, ex. lisibilité/structure>.
Règles :
- NE change PAS le comportement externe (input/output, API, effets de bord restent identiques)
- Travaille par petites étapes, vérifiables une par une
- Après chaque étape, lance les tests (<COMMANDE DE TEST>) et montre-moi le résultat
- Arrête-toi et demande si une étape changerait le comportement
À la fin, résume toutes les étapes et les résultats des tests comme preuve.

💡 Garde les diffs petits — une revue par étape est plus simple qu'une revue de tout d'un coup.

Claude Code: Best practices ↗

Quand une fonction/méthode est trop grande ou trop imbriquée et que tu veux en extraire proprement une partie.

Dans <FICHIER>, fonction <NOM DE LA FONCTION> : extrais le bloc de code qui <DESCRIPTION DE LA PARTIE> dans une fonction séparée, avec un nom clair.
- Le comportement doit rester exactement identique (mêmes entrées -> mêmes sorties, mêmes cas d'erreur)
- Suis les conventions de nommage/style déjà utilisées dans le fichier
- Si aucun test n'existe : écris d'abord un test qui verrouille le comportement actuel, puis refactore
- Lance les tests ensuite et montre-moi le résultat
Explique brièvement pourquoi la nouvelle structure est plus claire.

💡 Pas de test ? Écris d'abord un test de caractérisation (voir les modèles Tests), puis refactore.

Claude Code: Best practices ↗

Quand tu migres une librairie, un pattern ou une version d'API sur plusieurs fichiers.

Migre <ANCIEN PATTERN/LIBRAIRIE> vers <NOUVEAU PATTERN/LIBRAIRIE> dans <PÉRIMÈTRE, ex. dossier/module>.
- Liste d'abord TOUS les fichiers concernés avant de changer quoi que ce soit
- Migre les fichiers un par un (les fichiers interdépendants en petit groupe), montre chaque changement séparément
- Après chaque fichier, lance les tests/le build (<COMMANDE DE TEST>) et montre le résultat
- En cas de doute (ex. ancien comportement pas clair) : arrête-toi et demande plutôt que de deviner
À la fin : liste des fichiers migrés plus les cas encore en suspens.

💡 S'il y a beaucoup de fichiers : teste d'abord sur 2-3, affine le prompt, puis applique-le au reste.

Claude Code: Best practices ↗ · Anthropic: Building Effective Agents ↗

Quand un bug apparaît et que la cause n'est pas évidente.

Bug : <DESCRIPTION DE L'ERREUR / MESSAGE D'ERREUR>
Zone probable : <FICHIER/MODULE, si connu>
Procède comme ça :
1. Formule 2-3 hypothèses concrètes sur la cause possible
2. Vérifie chaque hypothèse de façon ciblée (lire le code, les logs, un petit test) — ne devine pas
3. Écris un test qui reproduit le bug AVANT de le corriger
4. Corrige la cause racine, pas juste le symptôme (pas de try/catch qui étouffe l'erreur)
5. Montre le test qui échoue avant, puis qui passe après
Arrête-toi et demande si aucune hypothèse n'explique le bug.

💡 « Root cause, not symptom » — ne te contente pas d'attraper l'erreur, corrige ce qui la cause.

Claude Code: Best practices ↗

Quand un test échoue parfois et que tu veux trouver la cause (timing, ordre, état partagé).

Le test <NOM DU TEST/FICHIER> est flaky (échoue de temps en temps).
- Lance le test <N, ex. 20> fois de façon isolée (<COMMANDE DE TEST>) et note succès/échec
- Vérifie les causes classiques : état partagé entre les tests, race conditions, dépendance au timing/à l'ordre, appels externes non mockés
- Formule une hypothèse sur la cause et prouve-la avec un test de reproduction ciblé
- Propose un fix qui corrige la cause (pas juste un retry/skip)
- Après le fix : relance le test plusieurs fois et montre le résultat
Si aucune cause claire n'est trouvée : résume ce qui a été écarté et ce qu'il faudrait vérifier ensuite.

💡 Une logique de retry ou @skip n'est pas un fix — juste un pansement, que ce prompt exclut volontairement.

Claude Code: Best practices ↗

Quand un utilisateur/rapport signale un bug, mais que tu n'as pas encore de moyen fiable de le reproduire.

Bug signalé : <DESCRIPTION, ex. venant d'un ticket/du support>
Comportement attendu : <CE QUI DEVRAIT SE PASSER>
Comportement réel : <CE QUI SE PASSE À LA PLACE>
1. Trouve le chemin de code concerné (point de départ : <ZONE CONCERNÉE, ex. src/auth/>)
2. Écris un test qui échoue et reproduit exactement le bug
3. Montre-moi le test qui échoue AVANT d'écrire le fix — je confirme que c'est le bon bug
Si tu n'arrives pas à reproduire le bug : arrête-toi et rapporte ce que tu as vérifié et écarté.
4. Seulement après : implémente le fix, le nouveau test doit passer, et toute la suite de tests doit rester verte

💡 Cette pause de confirmation avant le fix évite de corriger le mauvais bug.

Claude Code: Best practices ↗

Avant de marquer un changement comme terminé — fais-le examiner d'un œil critique par une instance fraîche.

Utilise un subagent/une session fraîche pour vérifier le diff de <PÉRIMÈTRE, ex. PR/branche/fichier> par rapport à <PLAN/EXIGENCE, ex. PLAN.md ou description du ticket>.
Le reviewer ne reçoit QUE le diff et l'exigence — pas la justification de pourquoi le changement a été fait ainsi.
Vérifie :
- Est-ce que chaque exigence est vraiment implémentée ?
- Y a-t-il des cas limites de l'exigence sans test ?
- Est-ce que quelque chose en dehors du périmètre a été modifié ?
Ne signale que les lacunes qui concernent la correction ou les exigences — pas de simples préférences de style.

💡 Un reviewer qui cherche activement des lacunes en trouve presque toujours — ne pourchasse pas chaque trouvaille, seulement celles qui ont un vrai impact sur la correction.

Claude Code: Best practices ↗

Quand tu veux reviewer une pull request/un diff de façon structurée plutôt qu'avec une longue liste non triée.

Review le diff dans <PÉRIMÈTRE, ex. PR #123 / nom de branche>.
Classe chaque trouvaille dans exactement un niveau :
- CRITICAL : bug, faille de sécurité ou risque de perte de données
- MAJOR : comportement incorrect dans un cas réaliste, gestion d'erreur manquante
- MINOR : style, nommage, petites améliorations
Pour chaque trouvaille : fichier:ligne, quel est le problème, proposition de fix concrète.
Pas de commentaires élogieux génériques. Si rien n'est trouvé, dis-le explicitement plutôt que d'inventer des findings.

💡 Des niveaux explicites évitent qu'un détail cosmétique ait autant de poids qu'un vrai bug.

Claude Code: Best practices ↗

Après l'implémentation d'une tâche planifiée — vérifier que tout ce qui était dans le plan a vraiment été réalisé.

Compare l'implémentation actuelle dans <PÉRIMÈTRE> avec le plan dans <SOURCE DU PLAN, ex. PLAN.md ou ticket>.
Établis une checklist à partir du plan et passe-la en revue point par point :
- Implémenté et testé
- Implémenté, mais sans test
- Non implémenté
- Fait en plus (pas dans le plan, mais présent dans le diff)
Justifie chaque point avec une référence fichier/ligne ou un résultat de test, pas de suppositions.

💡 Utilise ça comme critère d'arrêt — la tâche n'est considérée comme terminée que quand tous les points sont « implémenté et testé ».

Claude Code: Best practices ↗

Pour les tâches qui touchent plusieurs fichiers, dont l'approche n'est pas claire, ou quand tu ne connais pas bien le module.

Avant de changer quoi que ce soit : lis <ZONE CONCERNÉE, ex. src/auth/> et comprends comment <SUJET, ex. login/sessions> fonctionne actuellement.
Établis ensuite un plan pour <OBJECTIF/FEATURE> :
- Quels fichiers doivent changer ?
- Quel ordre des étapes a du sens ?
- Quels cas limites/risques vois-tu ?
- Comment ce sera vérifié à la fin (quels tests/checks) ?
Montre-moi le plan d'abord. Ne commence le code qu'après que j'ai confirmé le plan.

💡 Pour les petits changements évidents (faute de frappe, une ligne), l'étape de planification n'en vaut pas la peine — fais-le implémenter directement.

Claude Code: Best practices ↗

Quand une feature est trop grosse pour être faite en une fois et doit être découpée en morceaux vérifiables.

Je veux construire <DESCRIPTION DE LA FEATURE>.
Découpe la feature en étapes, où chaque étape :
- fonctionne/est testable de manière autonome (pas d'état intermédiaire à moitié cassé)
- a une vérification claire (test, build, check manuel)
Liste les étapes dans l'ordre avec 1-2 phrases de description chacune.
Implémente SEULEMENT l'étape 1, lance la vérification, et montre-moi le résultat avant de passer à l'étape suivante.

💡 Comme ça, chaque étape reste review-able, au lieu de te retrouver avec un diff énorme à la fin.

Claude Code: Best practices ↗ · Anthropic: Building Effective Agents ↗

Pour les features plus grosses/nouvelles, où tu n'as pas encore réfléchi à tous les détails toi-même.

Je veux construire <IDÉE DE FEATURE COURTE>. Interviewe-moi en détail à ce sujet avant que quoi que ce soit soit construit.
Pose des questions sur l'implémentation technique, l'UX, les cas limites, les compromis — pas de questions évidentes, mais les points difficiles que j'ai peut-être négligés.
Continue à poser des questions jusqu'à ce que tout soit clarifié.
Écris ensuite une spec complète (fichiers/interfaces concernés, ce qui est explicitement HORS périmètre, étape de vérification à la fin) dans <FICHIER SPEC, ex. SPEC.md>.

💡 Pour l'implémentation proprement dite, démarre une nouvelle session propre avec la spec finalisée comme contexte.

Claude Code: Best practices ↗

Quand tu dois toucher à du code legacy inconnu/non testé et que tu veux d'abord verrouiller le comportement actuel.

Le fichier/module <FICHIER/MODULE> n'a actuellement pas (assez) de tests, et je dois bientôt le modifier.
Écris d'abord des tests de caractérisation : des tests qui documentent et verrouillent le comportement ACTUEL — y compris les cas limites et d'erreur, même si le comportement semble bizarre.
- Pas de changement de comportement du code lui-même à cette étape
- Lance les tests et montre qu'ils passent
- Liste brièvement quel comportement était surprenant/discutable (pour clarification ultérieure)

💡 Ces tests sont ton filet de sécurité pour la prochaine étape de refactoring — ne les supprime pas, même si le comportement est volontairement changé plus tard.

Claude Code: Best practices ↗

Quand tu corriges un bug concret et que tu veux t'assurer qu'il ne revienne pas.

Bug : <DESCRIPTION/MESSAGE D'ERREUR> dans <FICHIER/MODULE>
1. Écris d'abord un test qui échoue actuellement et reproduit exactement ce bug
2. Montre-moi le test qui échoue
3. Implémente le fix seulement après
4. Le nouveau test doit passer, tous les tests existants doivent rester au vert
Exemples de cas que le test doit couvrir : <CAS DE TEST, ex. l'entrée X donne Y>

💡 Le test reste dans le repo après le fix — il évite que le même bug revienne discrètement (régression).

Claude Code: Best practices ↗

Quand tu débarques dans une codebase ou un module nouveau/inconnu.

Donne-moi une vue d'ensemble de <PÉRIMÈTRE, ex. ce repo / le dossier src/payments> sur 3 niveaux :
1. Vue générale : que fait le système, quels sont les principaux blocs (1 paragraphe + liste)
2. Structure : dossiers/modules les plus importants et leur responsabilité
3. Détails : pour <PARTIE SPÉCIFIQUE, ex. le flux d'une requête> : étape par étape, quels fichiers/fonctions sont impliqués
N'utilise que ce qui se trouve vraiment dans le code, pas de suppositions — quand quelque chose n'est pas clair, dis-le explicitement.

💡 Pose ensuite des questions ciblées, plutôt que de tout demander d'un coup — ça garde le contexte réduit.

Claude Code: Best practices ↗

Quand tu veux comprendre d'où viennent les données et où elles circulent dans un flux donné.

Retrace le flux de données à partir de <POINT DE DÉPART, ex. fonction/endpoint X>.
- D'où viennent les données d'entrée (appelant, requête, BDD, etc.) ?
- Quelles fonctions/modules traitent les données, dans quel ordre ?
- Où l'état est-il modifié (state, écritures en BDD, effets de bord) ?
- Où le flux se termine-t-il (réponse, stockage, transmission) ?
Présente ça comme une liste numérotée étape par étape avec des références fichier:ligne. Si une étape n'est pas claire/ambiguë, signale-le au lieu de deviner.

💡 Pour des flux plus complexes, demande en plus un court diagramme Mermaid.

Claude Code: Best practices ↗