mr-feedback

Que fait mr-feedback ?

Récupère une Merge Request GitLab, évalue à quel point elle est prête à être relue, et écrit un rapport de feedback dans un nouveau fichier Markdown qui peut être copié directement dans une note de MR.

Ce qu'il faut faire

Jugez la préparation à la relecture. Vérifiez si la MR a le contexte, la clarté du périmètre, les instructions de test et les conseils pour le relecteur qui permettent à celui-ci de la prendre en charge efficacement.

Pourquoi

Une MR bien préparée montre de l'attention et sera relue plus rapidement et mieux. Le rapport doit faire en sorte qu'une bonne MR se sente reconnue et donner à une MR plus faible des actions concrètes et encourageantes pour améliorer sa préparation.

Ce qu'il ne faut pas faire

Ne pas relire ou critiquer le code lui-même et ne pas suggérer de modifications de code/logique

Préférences

Avant toute autre chose, lisez reference/preferences.md (relatif à cette compétence). C'est la source de vérité pour tout comportement configurable – langue de sortie, ton, méthode de récupération, outils autorisés et chemin de sortie. Ce SKILL.md ne réaffirme pas ces valeurs ; lisez toujours les préférences dans ce fichier.

Ordre de priorité, du plus élevé au plus bas :

1. Une instruction explicite dans la demande actuelle de l'utilisateur (par exemple « cette fois, écris-le en portugais »).
2. reference/preferences.md.
3. Les instructions de cette compétence.

Entrées

L'utilisateur fournit l'un des éléments suivants :

• Une URL complète de MR : https://gitlab.com/<groupe>/<sous-groupe>/<projet>/-/merge_requests/<iid>
• Un chemin de projet + iid de MR : groupe/sous-groupe/projet + 42

Extrayez de l'URL :

• project_id = le chemin entre l'hôte et /-/merge_requests/ (encodez l'URL sous la forme groupe%2Fsous-groupe%2Fprojet lors de l'appel des outils)
• mergeRequestIid = le nombre après /-/merge_requests/

Si l'un ou l'autre manque ou est ambigu, demandez avant de récupérer.

Flux de travail

Utilisez la méthode et les outils déclarés dans reference/preferences.md. Les étapes ci-dessous indiquent quelles informations recueillir et pourquoi, pas quel outil appeler – choisissez l'outil correspondant dans les préférences pour chaque étape.

1. Métadonnées de la MR – titre, description, auteur, état, branche source/cible, indicateur de brouillon, labels, milestone, approbations, statut de fusion.
2. Liste des fichiers modifiés – chemins + nombre d'ajouts/suppressions ; donne le périmètre/la taille sans extraire chaque diff.
3. Extraits de diff pour confirmer que la description correspond à la réalité – par lots de 3 à 5 fichiers. Utilisez-les uniquement pour vérifier le périmètre et si des tests ont été touchés – pas pour critiquer le code. Ignorez les fichiers de verrouillage, les fichiers générés et les pur renommages ; échantillonnez si la MR est énorme.
4. Commits – utilisez le résumé des commits déjà inclus dans les métadonnées de la MR (étape 1) pour un signal d'hygiène/atomicité (nombre de commits / résumé des ajouts).
5. Statut CI – dernier état du pipeline pour la MR (succès/échec/aucun).
6. Évaluez par rapport à la grille dans reference/rubric.md.
7. Écrivez le rapport dans un nouveau fichier (voir Sortie) en utilisant reference/report-template.md.
8. Dites à l'utilisateur le chemin du fichier et proposez d'affiner le ton/la longueur avant qu'il ne le copie/colle.

Lisez reference/rubric.md avant de noter et reference/report-template.md avant d'écrire. N'inventez pas de données – si une récupération ne renvoie rien pour une catégorie (par ex. aucun pipeline), marquez-la comme « non disponible » plutôt que de deviner.

Chaque catégorie de la grille comporte une Raison expliquant pourquoi elle est importante pour l'auteur. Lorsque vous signalez une lacune dans « Pour améliorer la préparation », incluez toujours pourquoi c'est important pour l'auteur – afin que le feedback explique l'objectif derrière chaque demande, pas seulement la demande elle-même.

Ne copiez pas la Raison de la catégorie textuellement. La Raison est un contexte qui couvre toute la catégorie ; réécrivez-la pour correspondre au problème exact que vous avez trouvé. Référencez uniquement la chose spécifique qui ne va pas, et ne mentionnez jamais les aspects de la catégorie qui sont corrects. Par exemple, si la branche est en retard sur master mais que le pipeline est vert, expliquez pourquoi le fait d'être en retard sur master est important – ne mentionnez pas le pipeline du tout, puisqu'il a réussi. Le « pourquoi c'est important » doit être vrai pour cette lacune spécifique de la MR, pas une déclaration générique sur la catégorie.

Sortie

Écrivez dans le chemin de sortie déclaré dans reference/preferences.md, en résolvant ses espaces réservés et en créant les dossiers nécessaires au chemin.

Garde-fous

• Lecture seule. Cette compétence ne publie jamais de notes, n'approuve ni ne modifie la MR. Elle écrit seulement un fichier Markdown local. L'utilisateur décide s'il veut le coller.
• N'incluez pas de secrets/tokens qui pourraient apparaître dans les diffs dans le rapport.
• Si la MR est un brouillon ou n'a pas encore de diff, vous pouvez quand même l'évaluer et générer le rapport, mais assurez-vous d'être explicite à ce sujet.