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.
Quand l'utiliser : quand vous finissez une modification et voulez un historique Git propre et une pull request facile à relire.
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, libre…)
- Langue attendue : [LANGUE_DU_DEPOT]
<diff>
[SORTIE_DE_GIT_DIFF]
</diff>
## Ta mission
1. **Analyse le diff** : résume en 3 puces ce qui change réellement. Si le diff mélange plusieurs sujets sans rapport, dis-le et propose un découpage en plusieurs commits, avec les fichiers de chacun.
2. **Message de commit** : un titre de 72 caractères maximum, à l'impératif, conforme à la convention ; une ligne vide ; un corps qui explique le pourquoi (le comment se lit dans le diff). Propose 2 variantes de titre.
3. **Description de pull request** avec ces sections :
- Contexte : le problème résolu et le lien vers le ticket ;
- Changements : les modifications notables ;
- Comment tester : étapes reproductibles pour le relecteur ;
- Risques et points d'attention : migrations, changements cassants, performance, sécurité ;
- Captures ou exemples si l'interface ou une API change.
## Contraintes
- N'affirme rien qui ne se voie pas dans le diff ou le contexte ; si tu supposes une intention, formule-la comme une question pour l'auteur.
- Pas de formules vagues comme « diverses améliorations » ou « mise à jour du code ».
- Signale tout élément suspect dans le diff : secret en clair, log de débogage oublié, fichier généré, TODO.• Utilisez `git diff --staged` pour ne coller que ce qui sera réellement commité. • Sur un gros diff, collez d'abord `git diff --stat` et demandez si un découpage s'impose. • Relance : « Réécris la description de PR pour un relecteur qui ne connaît pas du tout ce module. » • Avec Claude Code, demandez simplement : « Analyse mes changements indexés et propose le commit et la PR selon ces règles. »
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
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.
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 : [MO