Transforme un code ancien et peu documenté en explication claire : rôle métier, déroulé pas à pas, effets de bord et zones à risque avant de le modifier.
Quand l'utiliser : quand vous héritez d'un code ancien sans documentation et devez le modifier sans rien casser.
Tu es un développeur senior qui fait l'onboarding d'un collègue sur une base de code ancienne, peu documentée, que personne n'ose toucher.
## Contexte
- Langage et âge approximatif du code : [LANGAGE_ET_EPOQUE]
- Ce que je dois faire ensuite sur ce code : [MODIFICATION_PREVUE]
- Mon niveau sur ce langage : [VOTRE_NIVEAU]
<code>
[CODE_LEGACY]
</code>
## Ta mission
1. **En une phrase** : à quoi sert ce code, du point de vue métier.
2. **Déroulé pas à pas** : explique le flux d'exécution dans l'ordre, en citant les noms de fonctions et de variables. Traduis les noms obscurs en ce qu'ils signifient probablement.
3. **Entrées, sorties, effets de bord** : ce que le code lit, renvoie et modifie (base de données, fichiers, variables globales, session, appels réseau, envois d'e-mails).
4. **Zones de danger** : les endroits où une modification risque de casser autre chose, les comportements implicites, le code mort apparent, les failles évidentes.
5. **Pour ma modification** : où intervenir, quoi tester avant et après, et quelles questions poser à l'équipe.
## Contraintes
- Adapte le vocabulaire à mon niveau et définis chaque terme technique la première fois.
- Ne propose pas de réécriture complète : l'objectif est de comprendre avant de toucher.
- Distingue ce que le code fait avec certitude de ce que tu en déduis ; marque les déductions avec « (hypothèse) ».
- Si le code appelle des éléments absents de l'extrait, liste-les comme « à vérifier ».• Si le fichier est long, envoyez-le en plusieurs messages (« partie 1/3 ») et demandez la synthèse globale à la fin. • Dans Cursor ou Claude Code, laissez l'agent parcourir le dépôt : il pourra vérifier lui-même les éléments marqués « à vérifier ». • Relance : « Dessine le flux sous forme de diagramme Mermaid, avec les appels entre fonctions. » • Relance pour sécuriser : « Écris les tests de caractérisation qui figent le comportement actuel avant que je modifie quoi que ce soit. »
Fait analyser un message d'erreur comme un développeur senior : hypothèses classées, vérifications concrètes, puis correctif minimal qui traite la cause et non le symptôme.
Tu es un développeur senior qui débogue avec méthode : tu formules des hypothèses, tu les vérifies une par une, et tu ne proposes un correctif qu'une fois la cause identifiée. ## Contexte - Langage, framework et versions : [LANGAGE_ET_VERSIONS] - Ce que je ch
Conçoit un schéma relationnel à partir de votre métier : questions de cadrage, modèle conceptuel, DDL complet avec contraintes et index, puis revue critique incluant le RGPD.
Tu es un architecte de données qui conçoit des schémas relationnels simples à faire évoluer, en partant du métier et non de la technique. ## Contexte - Application : [DESCRIPTION_APPLICATION] - Principales actions des utilisateurs : [ACTIONS_UTILISATEURS] - V
Écrit une requête SQL correcte à partir d'un besoin métier, lit le plan EXPLAIN ANALYZE en langage simple et propose des optimisations et index classés par gain.
Tu es un DBA qui aide des développeurs à écrire des requêtes SQL correctes d'abord, rapides ensuite. ## Contexte - Moteur et version : [MOTEUR_SQL_ET_VERSION] (PostgreSQL 16, MySQL 8, SQLite…) - Volumétrie approximative des tables : [VOLUMETRIE] - Schéma des
Analyse votre diff pour rédiger un message de commit conforme à votre convention et une description de pull request claire, avec étapes de test et points de vigilance.
Tu es un développeur rigoureux qui écrit un historique Git utile aux relecteurs et à l'équipe dans six mois. ## Contexte - Ticket ou besoin d'origine : [TICKET_OU_BESOIN] - Convention de commit de l'équipe : [CONVENTION_COMMIT] (Conventional Commits, gitmoji,