Bibliothèque de prompts pour le codage assisté par IA
40 prompts prêts à copier pour les agents de codage et les assistants IA, classés par tâche, de la compréhension du code au débogage, à la revue, à la sécurité et aux migrations.
par Patrick Kamtchueng Kom · Publié
↓ Télécharger: prompts-codage-ia.mdLa plupart des mauvais résultats que je vois avec les agents de codage viennent de prompts faibles, pas de modèles faibles. Un prompt qui marche contient généralement les cinq mêmes éléments.
- ObjectifCe qui doit être vrai une fois le travail terminé, en une ou deux phrases.
- ContexteLes fichiers, erreurs ou tickets qui comptent. Pointe-les; ne laisse pas l'agent deviner.
- ContraintesCe qui ne doit pas changer : API, dépendances, règles de style, fichiers interdits.
- Critères d'acceptationDes tests qui passent, un comportement observable, des commandes qui roulent sans erreur.
- Un plan d'abordPour tout ce qui dépasse le correctif d'une ligne, révise un plan avant qu'une ligne de code soit écrite.
Anatomie d’un bon prompt
Réchauffement : faible ou solide?
🎮 Prompt faible ou prompt solide?
1 / 8 · Pointage: 0
Classe chaque prompt. Les solides donnent à l'agent un objectif, du contexte, des limites et une ligne d'arrivée.
La bibliothèque
Remplace chaque [ESPACE_RÉSERVÉ], supprime les lignes qui ne s’appliquent pas et ajoute ce qui manque pour ton code. Ton outil ne lit pas les fichiers? Colle le code là où le prompt y fait référence.
🧭 40 prompts de codage
40 affichés · 0 / 40 terminé
Visite guidée d'un dépôt
#1Comprendre le code
À utiliser lors de ta première journée dans un dépôt que tu ne connais pas.
▸ Détails
Prompt de départ
Je suis nouveau dans ce dépôt. Fais-moi une visite guidée avant que je modifie quoi que ce soit. 1. Résume ce que fait le projet et qui l'utilise, d'après le code et la documentation que tu peux voir. 2. Liste les principaux répertoires et la responsabilité de chacun. 3. Identifie les points d'entrée (où l'exécution commence pour l'application, la CLI, les jobs ou les tests). 4. Nomme les dépendances clés et à quoi elles servent. 5. Signale tout ce qui sort de l'ordinaire : étapes de build personnalisées, génération de code, conventions non standard. Décris seulement ce que tu peux vérifier dans le code. Indique clairement ce qui relève de l'hypothèse. Ne modifie aucun fichier.
Suivre une requête de bout en bout
#2Comprendre le code
À utiliser quand tu dois comprendre comment une fonctionnalité circule réellement dans le système.
▸ Détails
Prompt de départ
Retrace ce qui se passe quand [ACTION OU REQUÊTE, p. ex. « un utilisateur soumet le formulaire de paiement »]. Commence à [POINT D'ENTRÉE, p. ex. la route, le handler ou le composant d'interface] et suis le flux à travers chaque couche jusqu'à [ÉTAT FINAL, p. ex. les données sont enregistrées et une réponse est retournée]. Pour chaque étape, donne : - le fichier et la fonction - ce qu'elle fait avec les données - les effets de bord (écritures en base de données, appels réseau, événements, mises à jour de cache) Termine avec une courte liste des endroits où ce flux pourrait échouer et comment chaque échec est géré aujourd'hui. Ne modifie aucun fichier.
Expliquer un bout de code déroutant
#3Comprendre le code
À utiliser quand une fonction ou un module n'a pas de sens pour toi.
▸ Détails
Prompt de départ
Explique-moi [CHEMIN DU FICHIER, NOM DE LA FONCTION OU DE LA CLASSE]. - Quel problème ce code résout-il? - Explique la logique étape par étape, en langage simple. - Pourquoi aurait-il été écrit de cette façon? Appuie-toi sur des indices dans le code, les commentaires ou les modules voisins. - Quelles sont les entrées, les sorties et les dépendances cachées (variables globales, variables d'environnement, état partagé)? - Qu'est-ce qui briserait si je modifiais [PARTIE PRÉCISE QUE J'ENVISAGE DE CHANGER]? Si quelque chose n'est vraiment pas clair à partir du code seulement, dis-le au lieu de deviner.
Cartographier l'impact d'un changement
#4Comprendre le code
À utiliser avant de toucher à du code dont plusieurs autres parties pourraient dépendre.
▸ Détails
Prompt de départ
Je prévois modifier [FONCTION, TYPE, TABLE, API OU CONFIGURATION] pour que [DESCRIPTION DU CHANGEMENT]. Trouve tout ce qui en dépend : - appels et imports directs - usages indirects (réflexion, références sous forme de chaînes, fichiers de configuration, données sérialisées, gabarits) - tests qui le couvrent - consommateurs externes dont tu vois des traces (API publique, autres services, scripts) Regroupe les résultats par niveau de risque : va certainement briser, pourrait briser, sans risque. Ne modifie aucun fichier.
Le plan avant le code
#5Planification
À utiliser pour toute tâche qui touche plus que quelques fichiers.
▸ Détails
Prompt de départ
Objectif : [CE QUI DOIT ÊTRE VRAI UNE FOIS LE TRAVAIL TERMINÉ]. Contexte : [TICKET, LIENS, FICHIERS OU MODULES PERTINENTS]. Contraintes : - [p. ex. aucune nouvelle dépendance] - [p. ex. garder l'API publique inchangée] - [p. ex. doit fonctionner avec le schéma de base de données actuel] Avant d'écrire du code, produis un plan : 1. Les fichiers que tu comptes créer ou modifier, et pourquoi. 2. L'ordre des changements. 3. Comment tu vas vérifier chaque étape (tests, commandes, vérifications manuelles). 4. Les questions ouvertes ou hypothèses que je devrais confirmer. Arrête-toi après le plan et attends mon approbation.
Comparer des options d'implémentation
#6Planification
À utiliser quand il y a plus d'une façon raisonnable de bâtir quelque chose.
▸ Détails
Prompt de départ
Je dois [PROBLÈME À RÉSOUDRE] dans [PARTIE DE LA BASE DE CODE]. Propose deux ou trois approches différentes. Pour chacune : - une courte description - ce qu'elle change dans le code existant - les compromis : complexité, performance, testabilité, facilité à revenir en arrière - ce qui en ferait le mauvais choix Ensuite, recommande une approche pour notre situation, selon ces priorités : [p. ex. livrer vite, minimiser le risque, maintenabilité à long terme]. N'écris pas encore de code d'implémentation.
Découper une fonctionnalité en petites étapes
#7Planification
À utiliser pour transformer une grosse fonctionnalité en morceaux faciles à réviser et à livrer.
▸ Détails
Prompt de départ
Découpe cette fonctionnalité en une suite de petits changements qu'on peut réviser indépendamment : [DESCRIPTION DE LA FONCTIONNALITÉ] Règles : - Chaque étape doit laisser la base de code fonctionnelle, avec les tests qui passent. - Chaque étape doit être assez petite pour être révisée d'une traite. - Place le travail risqué ou incertain au début pour apprendre vite. - Indique quelles étapes pourraient être derrière un feature flag. Pour chaque étape, donne un titre d'une ligne, ce qui change et comment le vérifier.
Faire ressortir les exigences cachées
#8Planification
À utiliser quand un ticket semble trop simple pour être vrai.
▸ Détails
Prompt de départ
Voici la tâche qu'on m'a confiée : [TEXTE DU TICKET OU DE L'EXIGENCE] Avant de planifier quoi que ce soit, joue le rôle d'un développeur senior sceptique. En te basant sur cette base de code, liste : - les questions que je devrais poser au demandeur - les cas limites que le ticket ne mentionne pas - les comportements existants avec lesquels ça pourrait entrer en conflit - les enjeux non fonctionnels (permissions, performance, journalisation, localisation, accessibilité, migration de données) Garde seulement les éléments qui s'appliquent vraiment ici, pas une liste générique.
Implémenter à partir d'un plan approuvé
#9Implémentation
À utiliser juste après avoir révisé et approuvé un plan.
▸ Détails
Prompt de départ
Le plan ci-dessus est approuvé. Implémente l'étape [N] : [TITRE DE L'ÉTAPE]. - Suis les patterns existants dans [FICHIER OU MODULE SEMBLABLE]. - Modifie seulement les fichiers listés dans le plan. Si tu dois toucher à autre chose, arrête-toi et explique-moi pourquoi d'abord. - Ajoute ou mets à jour les tests pour le nouveau comportement. - Roule [COMMANDE DE TESTS] et [COMMANDE DE LINT/VÉRIFICATION DE TYPES] et corrige tout ce qui échoue. Quand tu as terminé, résume ce qui a changé et tout ce qui diffère du plan.
Bâtir une fonctionnalité en s'inspirant d'une existante
#10Implémentation
À utiliser quand la base de code contient déjà quelque chose de très semblable à ce dont tu as besoin.
▸ Détails
Prompt de départ
Bâtis [NOUVELLE FONCTIONNALITÉ] en suivant la même structure que [FONCTIONNALITÉ EXISTANTE, avec les chemins de fichiers]. Reprends : - l'organisation et le nommage des fichiers - la gestion des erreurs - l'approche de validation - le style des tests Différences avec la fonctionnalité existante : - [DIFFÉRENCE 1] - [DIFFÉRENCE 2] Montre-moi la liste des fichiers que tu comptes créer ou modifier avant de les écrire.
Ajouter un endpoint d'API
#11Implémentation
À utiliser pour une nouvelle route, un nouveau handler ou une nouvelle méthode RPC.
▸ Détails
Prompt de départ
Ajoute un endpoint [MÉTHODE HTTP] à [CHEMIN] qui [CE QU'IL FAIT]. Requête : [CHAMPS, TYPES, LESQUELS SONT OBLIGATOIRES] Réponse : [FORME EN CAS DE SUCCÈS] Erreurs : [CAS D'ERREUR ATTENDUS ET CODES DE STATUT] Authentification : [QUI A LE DROIT DE L'APPELER] Suis les conventions de [FICHIER D'UN ENDPOINT EXISTANT] pour le routage, la validation, le format des erreurs et la journalisation. Ajoute des tests pour le succès, l'échec de validation, l'accès non autorisé et [AUTRE CAS]. Ne modifie pas les endpoints existants.
Bâtir un composant d'interface
#12Implémentation
À utiliser pour un nouveau composant front-end qui doit s'intégrer à un design system existant.
▸ Détails
Prompt de départ
Crée un composant [NOM DU COMPOSANT] dans [RÉPERTOIRE]. Il doit : - [COMPORTEMENT 1] - [COMPORTEMENT 2] - gérer les états de chargement, vide et d'erreur Contraintes : - Utilise les composants et les styles existants de [DESIGN SYSTEM OU DOSSIER]. N'ajoute aucune nouvelle librairie de style. - Il doit être utilisable au clavier et avoir des libellés appropriés pour les lecteurs d'écran. - Suis les conventions de props et de fichiers de [COMPOSANT EXISTANT SEMBLABLE]. Ajoute des tests pour les interactions principales, avec la même approche de test que le reste du projet.
Tests pour du code existant
#13Tests
À utiliser pour ajouter de la couverture à du code qui n'en a pas.
▸ Détails
Prompt de départ
Écris des tests pour [FICHIER OU FONCTION]. D'abord, liste les comportements qui devraient selon toi être testés : cas normaux, cas limites et cas d'erreur. Attends que je confirme la liste. Ensuite, écris les tests : - Utilise [FRAMEWORK DE TEST] et suis le style de [FICHIER DE TEST EXISTANT]. - Teste le comportement à travers l'interface publique, pas les détails d'implémentation. - Simule (mock) seulement les frontières externes (réseau, système de fichiers, temps, services tiers). - Ne modifie pas le code testé. Si quelque chose est difficile à tester, explique-moi pourquoi plutôt.
Tests d'abord pour un nouveau comportement
#14Tests
À utiliser quand tu veux que l'agent travaille en mode rouge, puis vert.
▸ Détails
Prompt de départ
Je veux ajouter ce comportement : [DESCRIPTION]. Travaille en commençant par les tests : 1. Écris un test qui échoue et qui décrit le comportement. Roule-le et montre-moi qu'il échoue pour la bonne raison. 2. Écris le minimum de code pour le faire passer. 3. Roule toute la suite de tests de [MODULE] pour confirmer que rien d'autre n'a brisé. 4. Suggère du refactoring au besoin, mais ne l'applique pas sans me demander. Répète pour chacun de ces cas : [CAS 1], [CAS 2], [CAS 3].
Trouver les trous dans une suite de tests
#15Tests
À utiliser quand les tests existent, mais que tu ne leur fais pas confiance.
▸ Détails
Prompt de départ
Révise les tests de [MODULE] dans [FICHIER(S) DE TEST] en les comparant au code de [FICHIER(S) SOURCE]. Dis-moi : - quels comportements et quelles branches n'ont aucun test - les tests qui passeraient encore si le code était brisé (assertions faibles, trop de mocks) - les tests fragiles parce qu'ils dépendent de détails d'implémentation - les cas limites manquants : entrées vides, bornes, données invalides, concurrence, fuseaux horaires Classe les trous par niveau de risque et propose les cinq tests que je devrais ajouter en premier. Ne les écris pas encore.
Stabiliser un test instable (flaky)
#16Tests
À utiliser quand un test passe et échoue sans que le code change.
▸ Détails
Prompt de départ
Ce test est instable : [NOM DU TEST ET FICHIER]. Symptômes : [COMMENT IL ÉCHOUE, À QUELLE FRÉQUENCE, OÙ (en local, en CI, les deux)]. Sortie de l'échec : [COLLER L'ERREUR] Examine les causes probables, comme les délais et les attentes asynchrones, l'état partagé entre les tests, l'ordre des tests, les vraies horloges ou les valeurs aléatoires, les appels réseau et les différences d'environnement. Explique la cause la plus probable avec des preuves tirées du code, puis propose un correctif qui rend le test déterministe. N'ajoute pas de nouvelles tentatives ni de délais plus longs comme correctif, à moins de pouvoir expliquer pourquoi c'est vraiment la bonne solution.
Diagnostiquer à partir d'une erreur
#17Débogage
À utiliser quand tu as une trace de pile ou un message d'erreur et pas grand-chose d'autre.
▸ Détails
Prompt de départ
J'obtiens cette erreur : [COLLER L'ERREUR COMPLÈTE ET LA TRACE DE PILE] Elle survient quand [ÉTAPES POUR REPRODUIRE]. Résultat attendu : [COMPORTEMENT ATTENDU]. Environnement : [p. ex. dev local / staging / production, versions si pertinent]. Avant de proposer un correctif : 1. Explique ce que l'erreur veut dire. 2. Liste les causes probables, en ordre, avec les indices pour chacune dans le code. 3. Dis-moi quoi vérifier ou journaliser pour confirmer laquelle est la bonne. Ne modifie aucun code tant qu'on n'a pas confirmé la cause.
Reproduire avant de corriger
#18Débogage
À utiliser pour les rapports de bogue vagues ou difficiles à déclencher.
▸ Détails
Prompt de départ
Rapport de bogue : [COLLER LE RAPPORT] Ta première tâche est de le reproduire, pas de le corriger. - Écris le plus petit test ou script possible qui échoue et qui montre le bogue. - Si tu n'arrives pas à le reproduire, dis-moi quelle information manque et ce que tu as essayé. Une fois qu'on a une reproduction fiable, propose un correctif, applique-le et montre que la reproduction passe maintenant, avec les tests existants.
Déboguer par hypothèses
#19Débogage
À utiliser quand tu es bloqué et que les correctifs évidents n'ont pas marché.
▸ Détails
Prompt de départ
Je suis bloqué sur ce bogue : [DESCRIPTION]. Ce que j'ai déjà essayé : - [ESSAI 1 ET RÉSULTAT] - [ESSAI 2 ET RÉSULTAT] Procède de façon méthodique : 1. Liste au moins trois hypothèses compatibles avec tous les indices, y compris ce que j'ai déjà écarté. 2. Pour chacune, décris une expérience rapide qui la confirmerait ou l'éliminerait. 3. Dis-moi quelle expérience faire en premier et pourquoi. Après que je t'aurai partagé les résultats, mets les hypothèses à jour. Ne saute pas au correctif tant qu'une hypothèse n'est pas confirmée.
Trouver le changement qui a causé une régression
#20Débogage
À utiliser quand quelque chose marchait avant et ne marche plus.
▸ Détails
Prompt de départ
[FONCTIONNALITÉ OU COMPORTEMENT] fonctionnait à [VERSION, COMMIT OU DATE CONNUE COMME BONNE] et est brisé à [VERSION ACTUELLE]. Voici les changements entre les deux : [COLLER LE GIT LOG, UN RÉSUMÉ DU DIFF OU LA LISTE DES PULL REQUESTS] 1. Identifie les changements qui pourraient plausiblement affecter ce comportement, et explique pourquoi. 2. Classe-les par probabilité. 3. Si la liste est longue, donne-moi les commandes exactes pour faire un bisect. Une fois la cause trouvée, propose le plus petit correctif qui rétablit l'ancien comportement sans annuler du travail qui n'a rien à voir.
Refactoring qui préserve le comportement
#21Refactorisation
À utiliser pour nettoyer du code sans changer ce qu'il fait.
▸ Détails
Prompt de départ
Refactorise [FICHIER OU FONCTION] pour [OBJECTIF, p. ex. « réduire l'imbrication et le séparer en plus petites fonctions »]. Règles : - Le comportement doit rester exactement le même. Pas de nouvelles fonctionnalités, pas de correctifs de bogues mélangés. Liste à part les bogues que tu remarques. - Garde l'interface publique inchangée : [SIGNATURES DE FONCTIONS, EXPORTS, API]. - Assure-toi d'abord que les tests couvrent le comportement actuel. Sinon, ajoute des tests de caractérisation avant de refactoriser. - Roule [COMMANDE DE TESTS] après chaque étape. Montre-moi le plan d'abord, puis procède par petites étapes.
Séparer un gros fichier ou une grosse classe
#22Refactorisation
À utiliser quand un seul fichier a fini par cumuler plusieurs responsabilités.
▸ Détails
Prompt de départ
[CHEMIN DU FICHIER] fait maintenant [TAILLE] et mélange plusieurs responsabilités. 1. Liste les responsabilités distinctes que tu vois et quelles fonctions appartiennent à chacune. 2. Propose une nouvelle structure : quels modules créer, quoi mettre où et comment ils dépendent les uns des autres. Évite les dépendances circulaires. 3. Planifie le déplacement en étapes qui gardent le code fonctionnel après chacune. Garde les imports existants fonctionnels (réexporte au besoin), à moins que j'approuve de les changer. Attends mon approbation avant de déplacer du code.
Éliminer la duplication
#23Refactorisation
À utiliser quand la même logique apparaît à plusieurs endroits.
▸ Détails
Prompt de départ
La logique pour [CE QUI EST DUPLIQUÉ] apparaît à plusieurs endroits, notamment [FICHIER 1], [FICHIER 2], [FICHIER 3]. 1. Trouve chaque copie, y compris les variantes légèrement différentes. 2. Compare-les et liste les vraies différences. Certaines peuvent être voulues. 3. Propose une seule implémentation partagée qui gère les différences légitimes sans empiler les flags. 4. Montre comment chaque endroit qui l'appelle changerait. Ne fusionne pas les copies dont tu ne peux pas expliquer les différences. Signale-les-moi plutôt.
Améliorer les noms et la lisibilité
#24Refactorisation
À utiliser pour une passe à faible risque sur du code difficile à lire.
▸ Détails
Prompt de départ
Améliore la lisibilité de [FICHIER OU FONCTION] sans changer le comportement. Concentre-toi sur : - des noms plus clairs pour les variables, fonctions et types - le remplacement des nombres et chaînes magiques par des constantes nommées - la simplification des conditions - la suppression du code mort et des commentaires périmés - l'ajout d'un court commentaire seulement là où le « pourquoi » n'est pas évident Garde les noms publics inchangés à moins que je l'approuve. Montre les changements sous forme de diff, avec une raison d'une ligne pour chaque changement non trivial.
Réviser un diff avant d'ouvrir une pull request
#25Revue de code
À utiliser comme première passe de revue sur ton propre travail.
▸ Détails
Prompt de départ
Révise ce changement avant que j'ouvre une pull request. But du changement : [CE QU'IL EST CENSÉ FAIRE] Diff : [COLLER LE DIFF, OU « les changements non commités de ce dépôt », OU « cette branche comparée à main »] Vérifie : - les bogues et les erreurs de logique - les cas limites qui ne sont pas gérés - les tests manquants ou faibles - les incohérences avec les patterns utilisés ailleurs dans la base de code - tout ce qui ne correspond pas au but annoncé Regroupe les constats en : à corriger absolument, à corriger idéalement, détail. Pour chacun, indique l'endroit exact et explique pourquoi. Ne réécris pas le code; fais seulement la revue.
Réviser la pull request de quelqu'un d'autre
#26Revue de code
À utiliser pour te préparer à réviser le travail d'un collègue.
▸ Détails
Prompt de départ
Aide-moi à réviser cette pull request. Description de l'auteur : [COLLER LA DESCRIPTION DE LA PR] Diff : [COLLER LE DIFF OU INDIQUER LA BRANCHE] 1. Résume ce que fait le changement en langage simple. 2. Vérifie si l'implémentation correspond à la description. 3. Liste les questions que je devrais poser à l'auteur. 4. Signale les risques : exactitude, sécurité, performance, rétrocompatibilité, tests manquants. Garde un ton constructif et précis dans les commentaires suggérés. C'est moi qui déciderai quoi publier.
Vérifier un changement selon les standards de l'équipe
#27Revue de code
À utiliser quand ton équipe a des conventions écrites et que tu veux les appliquer de façon constante.
▸ Détails
Prompt de départ
Voici les standards de code de notre équipe : [COLLER LES STANDARDS OU INDIQUER LE FICHIER] Révise [DIFF OU FICHIERS] selon ces standards. Pour chaque écart, donne la règle, l'endroit et un correctif suggéré. Rapporte seulement les vrais écarts aux standards écrits. N'ajoute pas tes propres préférences de style, et dis-le si les standards ne couvrent pas quelque chose qui te semble important.
Écrire un README pour un module
#28Documentation
À utiliser quand un module n'a pas de documentation, ou qu'elle n'est plus à jour.
▸ Détails
Prompt de départ
Écris un README pour [MODULE OU RÉPERTOIRE]. Inclus : - ce qu'il fait et quand l'utiliser - comment l'installer et le rouler en local - les principales fonctions publiques ou les principaux endpoints, avec un court exemple pour chacun - les options de configuration et les variables d'environnement - les limites connues Base-toi entièrement sur le code réel. Si quelque chose n'est pas clair, ajoute un TODO pour moi au lieu de deviner. Reste concis; un développeur devrait pouvoir le parcourir en deux minutes.
Documenter une fonction ou une API
#29Documentation
À utiliser pour de la documentation dans le code qui respecte le style du projet.
▸ Détails
Prompt de départ
Ajoute des commentaires de documentation aux fonctions publiques de [FICHIER]. - Suis le style de commentaires de documentation de [FICHIER EXEMPLE, ou le format standard du langage]. - Pour chaque fonction : ce qu'elle fait, ses paramètres, sa valeur de retour, les erreurs qu'elle peut lever et un court exemple si l'usage n'est pas évident. - Ne répète pas ce que le code dit déjà clairement. Mets l'accent sur l'intention, les contraintes et les pièges. - Ne modifie aucun code.
Consigner une décision d'architecture
#30Documentation
À utiliser pour garder une trace du raisonnement derrière un choix technique pendant qu'il est encore frais.
▸ Détails
Prompt de départ
Rédige un registre de décision d'architecture (ADR) pour cette décision : Décision : [CE QU'ON A DÉCIDÉ] Contexte : [LE PROBLÈME ET LES CONTRAINTES] Options envisagées : [OPTION A, OPTION B, OPTION C] Pourquoi on l'a choisie : [RAISONS] Utilise ces sections : Titre, Statut, Contexte, Décision, Solutions envisagées, Conséquences (positives et négatives). Garde le tout sous une page. Là où je ne t'ai pas donné de raison, laisse un espace réservé clair au lieu d'en inventer une.
Trouver un goulot d'étranglement
#31Performance
À utiliser quand quelque chose est lent et que tu ne sais pas encore pourquoi.
▸ Détails
Prompt de départ
[OPÉRATION, PAGE OU ENDPOINT] est lent. Ça prend environ [TEMPS ACTUEL] et ça devrait prendre moins de [CIBLE]. Code pertinent : [FICHIERS OU POINT D'ENTRÉE] Données de profilage ou de chronométrage, s'il y en a : [COLLER] 1. Lis le chemin d'exécution et liste les goulots probables : travail répété, requêtes N+1, I/O bloquantes, grosses allocations, index manquants, rendus inutiles. 2. Pour chacun, explique comment mesurer si c'est vraiment le problème. 3. N'optimise rien pour l'instant. Dis-moi quoi mesurer en premier.
Optimiser avec une cible mesurable
#32Performance
À utiliser une fois que tu sais où le temps est dépensé.
▸ Détails
Prompt de départ
Le goulot est [CODE PRÉCIS ET CE QUI LE REND LENT], confirmé par [MESURE]. Optimise-le avec ces contraintes : - Le comportement et la sortie doivent rester identiques. Les tests existants doivent passer. - Cible : [p. ex. moins de 200 ms pour 10 000 enregistrements]. - Privilégie le changement le plus simple qui atteint la cible. Explique tout compromis en lisibilité ou en mémoire. Avant et après, donne-moi la commande ou le benchmark exact à rouler pour que je puisse vérifier l'amélioration moi-même.
Réviser les requêtes à la base de données
#33Performance
À utiliser quand l'accès aux données pourrait être la partie lente.
▸ Détails
Prompt de départ
Révise les requêtes à la base de données dans [FICHIERS, COUCHE D'ACCÈS AUX DONNÉES OU MODÈLES DE L'ORM] pour trouver des problèmes de performance. Base de données : [MOTEUR ET VERSION] Taille approximative des tables : [p. ex. orders : 5 M lignes, users : 200 k lignes] Schéma et index : [COLLER OU INDIQUER LES MIGRATIONS] Cherche les patterns N+1, les index manquants ou inutilisés, les balayages complets de tables, la récupération de trop de colonnes ou de lignes, et les requêtes dans des boucles. Pour chaque problème, montre la requête, explique le problème et propose un correctif. Si tu suggères un index, dis-moi comment le vérifier avec le plan d'exécution avant de l'ajouter.
Revue de sécurité d'un changement
#34Sécurité
À utiliser avant de merger quoi que ce soit qui touche au traitement des entrées, à l'authentification ou à l'accès aux données.
▸ Détails
Prompt de départ
Fais une revue de sécurité de [DIFF, FICHIERS OU FONCTIONNALITÉ]. Vérifie : - les injections (SQL, commandes, gabarits, traversée de répertoires) - les vérifications d'authentification et d'autorisation manquantes ou incorrectes - le traitement non sécuritaire des entrées utilisateur et l'encodage des sorties - les secrets ou identifiants dans le code, les logs ou les messages d'erreur - les valeurs par défaut non sécuritaires et les permissions trop larges - les données sensibles exposées dans les réponses ou les logs Pour chaque constat : l'endroit, ce qu'un attaquant pourrait faire, la gravité (élevée, moyenne, faible) et un correctif concret. Rapporte seulement les problèmes que tu peux pointer dans le code, et indique ton niveau de confiance pour chacun.
Auditer un flux d'autorisation
#35Sécurité
À utiliser pour vérifier qui peut réellement faire quoi.
▸ Détails
Prompt de départ
Audite les autorisations pour [FONCTIONNALITÉ OU RESSOURCE, p. ex. « la modification des factures »]. Rôles dans le système : [LISTE DES RÔLES] Règles attendues : [QUI DEVRAIT POUVOIR FAIRE QUOI] 1. Trouve chaque chemin de code qui lit ou modifie cette ressource (interface, API, jobs en arrière-plan, outils d'administration). 2. Pour chaque chemin, montre où l'accès est vérifié, ou indique qu'il ne l'est pas. 3. Compare les vérifications réelles aux règles attendues et liste chaque écart. 4. Signale tout endroit où la vérification repose sur des données contrôlées par le client. Ne modifie pas le code. Présente les constats sous forme de tableau.
Réviser les dépendances et la configuration
#36Sécurité
À utiliser pour une vérification périodique de ce que ton projet importe et de sa configuration.
▸ Détails
Prompt de départ
Révise le manifeste de dépendances [p. ex. package.json, requirements.txt, go.mod] et la configuration dans [FICHIERS DE CONFIGURATION]. Signale : - les dépendances qui semblent inutilisées, en double ou abandonnées - les plages de versions très larges - les réglages de débogage, un CORS trop permissif, des en-têtes de sécurité désactivés ou des messages d'erreur trop détaillés qui pourraient se rendre en production - les secrets commités dans le dépôt Pour tout ce qui dépend d'une version (vulnérabilités connues, dates de fin de vie), ne te fie pas à ta mémoire. Dis-moi quelle commande ou quel outil rouler pour le vérifier.
Planifier la mise à niveau d'une dépendance ou d'un framework
#37Migrations
À utiliser avant de mettre à niveau quoi que ce soit qui comporte des changements incompatibles.
▸ Détails
Prompt de départ
Je veux mettre à niveau [LIBRAIRIE OU FRAMEWORK] de [VERSION ACTUELLE] à [VERSION CIBLE]. Voici les notes de migration officielles ou le changelog : [COLLER OU RÉSUMER] 1. Trouve chaque endroit de la base de code touché par les changements incompatibles listés. 2. Estime l'ampleur de chaque changement (trivial, modéré, important). 3. Propose un ordre de mise à niveau qui garde l'application fonctionnelle, y compris les versions intermédiaires s'il y a lieu. 4. Liste ce qu'il faut tester manuellement après la mise à niveau. Pour les changements propres à une version, fie-toi seulement aux notes de migration que je t'ai fournies. S'il te manque de l'information, demande-la-moi.
Écrire une migration de base de données sécuritaire
#38Migrations
À utiliser pour des changements de schéma sur une base de données déjà en production.
▸ Détails
Prompt de départ
Je dois modifier le schéma : [DESCRIPTION, p. ex. « séparer la colonne name en first_name et last_name »]. Base de données : [MOTEUR ET VERSION] Outil de migration : [OUTIL] Taille de la table : [NOMBRE APPROXIMATIF DE LIGNES] Contraintes : [p. ex. aucune interruption de service, l'ancienne version de l'application doit continuer de fonctionner pendant le déploiement] Écris la migration de façon à ce que : - elle puisse rouler pendant que l'application est en ligne (étendre, migrer les données, puis contracter, au besoin) - elle ait un rollback fonctionnel - le remplissage des données se fasse par lots si la table est grosse Explique l'ordre de déploiement : quelles étapes de migration vont avant, pendant et après le changement de code.
Migrer un pattern dans toute la base de code
#39Migrations
À utiliser pour de gros changements répétitifs, comme passer d'une API ou d'une librairie à une autre.
▸ Détails
Prompt de départ
Migre tous les usages de [ANCIEN PATTERN OU ANCIENNE API] vers [NOUVEAU PATTERN OU NOUVELLE API]. Exemple du changement : Avant : [EXEMPLE DE CODE] Après : [EXEMPLE DE CODE] 1. Trouve chaque occurrence et donne-moi le total, regroupé par répertoire. 2. Identifie les cas qui ne cadrent pas avec l'exemple simple avant/après et explique pourquoi. 3. Migre d'abord les cas simples, un répertoire à la fois, en roulant [COMMANDE DE TESTS] après chaque lot. 4. Laisse-moi les cas inhabituels à réviser, avec une note pour chacun.
Porter du code vers un autre langage ou framework
#40Migrations
À utiliser quand tu réécris un module plutôt que de le mettre à niveau.
▸ Détails
Prompt de départ
Porte [FICHIER OU MODULE] de [LANGAGE OU FRAMEWORK SOURCE] vers [LANGAGE OU FRAMEWORK CIBLE]. - Préserve exactement le comportement, y compris les cas d'erreur et les cas limites. - Écris du code [CIBLE] idiomatique plutôt qu'une traduction ligne par ligne. - Suis les conventions de [CODE EXISTANT DANS LE LANGAGE CIBLE DANS CE DÉPÔT]. - Porte ou écris des tests qui prouvent que la nouvelle version se comporte comme l'ancienne. Avant d'écrire du code, liste tout ce qui ne se traduit pas directement (fonctionnalités de librairies, modèle de concurrence, différences de types) et comment tu comptes gérer chaque élément.