nicolasroy-fr/mr-description

Titre et description de MR / PR

Tout ce qui est écrit dans la MR/PR (titre, description) et toute question posée à l'utilisateur se fait en français. Dites « MR » pour GitLab et « PR » pour GitHub.

Arguments (facultatifs)

Contenu reçu : $ARGUMENTS

Argument	Cible
https://github.com/<propriétaire>/<dépôt>/pull/<n>	PR GitHub
https://<hôte>/<groupe>/<dépôt>/-/merge_requests/<iid>	MR GitLab
#<n> / <n> seul	MR ou PR du dépôt courant : déduire la plateforme de git remote -v
rien	MR ou PR de la branche courante : déduire la plateforme de git remote -v

Si la plateforme ne peut pas être déduite (hôte auto-hébergé, plusieurs dépôts distants), demander.

Règles strictes

• Ne jamais modifier la MR/PR sans confirmation explicite du titre et de la description, puis une autorisation explicite séparée pour envoyer.
• Ne jamais inventer de faits (numéro de carte, contexte, tests). Demander ou omettre.
• Aucune mention de Claude dans le contenu de la MR/PR.

Étapes

1. Identifier et récupérer la MR/PR

Résoudre la cible à partir des arguments (tableau ci-dessus), puis lire la référence correspondante avant d'exécuter une commande :

• references/sources/gitlab.md
• references/sources/github.md

Si la CLI (glab / gh) est manquante ou non authentifiée, en informer l'utilisateur (suggérer ! glab auth login / ! gh auth login) plutôt que de deviner.

Récupérer : le titre actuel, la description actuelle, les branches source/cible, et les modifications (diff et liste des commits), en suivant la référence. Lire le diff pour comprendre le contenu réel de la MR/PR.

Déterminer :

• Nom du dépôt : dernier segment du chemin du projet, en MAJUSCULES.
• Numéro de carte : chercher dans le titre existant, le nom de branche, les commits et la description (ex. ABC-123, #123). Si aucun n'est trouvé, demander une fois ; si l'utilisateur dit qu'il n'y en a pas, omettre complètement les crochets.

2. Titre

Modèle (identique sur les deux plateformes) :

[<numéro de carte>] <NOM DU DÉPÔT> - <sujet> - courte description

• Crochets et numéro de carte uniquement si une carte existe.
• <NOM DU DÉPÔT> : nom du dépôt en majuscules.
• <sujet> : toujours demander à l'utilisateur (proposer une suggestion déduite du diff comme option par défaut, mais ne pas décider seul). Si le titre actuel contient déjà un sujet, proposer de le conserver.
• Courte description : succincte, en français, commence par une minuscule, pas de point final.
• Si un titre existant est déjà bien formé et correspond encore au contenu de la MR/PR, le conserver et le signaler. S'il ne correspond plus, proposer une version modifiée et montrer l'avant/après.

3. Description

Structure (Markdown, en français) :

# Description

<Une ou deux phrases résumant l'objectif de la MR/PR.>

## Contexte

<État actuel du code s'il s'agit d'une modification ; résultat attendu : contraintes,
objectifs, architecture, stratégie.>

## Changements

- <Changement de haut niveau>
- ...

## Tests

- <Tests écrits, ou tests manuels effectués>

Guide pour les sections :

• Description : 1 à 2 phrases sur l'objectif. Proposer un brouillon et demander à l'utilisateur de valider ou de corriger.
• Contexte : décrit l'état avant (pour une modification) et le résultat attendu (contraintes, objectifs, architecture, stratégie). Procéder point par point : soumettre chaque point à l'utilisateur pour validation et poser une question chaque fois qu'un point pourrait être clarifié (pourquoi ce choix, quelle contrainte, quelle alternative rejetée). Ne pas continuer avec des hypothèses non validées.
• Changements : liste de haut niveau uniquement. Entrer dans les détails seulement lorsque le changement concerne précisément ce détail ou lorsqu'il est essentiel pour comprendre la MR/PR dans son ensemble.
• Tests : grandes lignes des tests automatisés écrits (fichiers/zones couvertes) et des tests manuels effectués. Si inconnu, demander ; ne jamais prétendre avoir effectué des tests qui ne l'ont pas été.

Préférer regrouper les questions connexes avec AskUserQuestion (sujet, numéro de carte, points de contexte) plutôt que de multiplier les allers-retours.

4. Description existante (cas de mise à jour)

Si la MR/PR a déjà une description :

• Montrer ce qui changerait, section par section (ajouté / modifié / supprimé), pas seulement le nouveau texte.
• Conserver le contenu utile que l'utilisateur a écrit (liens, captures d'écran, listes de vérification, sections de modèle, mots-clés de fermeture comme Closes #12) ; mentionner si quelque chose serait supprimé.
• Demander confirmation des modifications avant d'aller plus loin.

5. Confirmer, puis envoyer

1. Présenter le titre final, la MR/PR cible (URL, branches) et la description complète, et demander confirmation des trois.
2. Ce n'est qu'après cela qu'il faut poser une question séparée : l'autorisation d'envoyer les modifications sur la plateforme.
3. Après approbation, écrire la description dans un fichier temporaire/brouillon et mettre à jour la MR/PR avec la commande issue de la référence de la plateforme. Ces commandes ne sont pas dans allowed-tools intentionnellement, afin que l'utilisateur reçoive une invite d'autorisation.
4. Rapporter le résultat et l'URL de la MR/PR. En cas d'échec, afficher l'erreur ; ne pas réessayer en silence.