PixiBixi/claude-skills

Traitement des commentaires de révision des MR GitLab

Vue d'ensemble

Les commentaires de révision en ligne sur une MR GitLab se trouvent dans des discussions (fils accrochés à un fichier + ligne). L'ensemble du cycle (récupération avec position → correction → réponse → résolution) passe par glab api. Cette compétence fournit la séquence de commandes éprouvée ; l'écueil est que la commande évidente (glab mr view --comments) donne le texte du commentaire mais pas la position fichier/ligne, ce qui empêche de savoir à quoi chaque commentaire se réfère.

CONTEXTE REQUIS : Utilisez superpowers:receiving-code-review pour la partie jugement : évaluez chaque commentaire avec rigueur technique et vérifiez qu'il est correct avant de l'appliquer. Cette compétence ne couvre que la mécanique GitLab.

Configuration

MR=511                                          # le iid de la MR
PROJ="<groupe>%2F<sous-groupe>%2F<projet>"    # chemin complet encodé URL
API="projects/$PROJ/merge_requests/$MR"

Encodez le chemin dans l'URL (/ → %2F). Obtenez-le avec glab repo view si nécessaire.

1. Récupérer les commentaires AVEC position

glab mr view $MR --comments n'inclut PAS les positions de ligne, ne l'utilisez donc pas pour les commentaires en ligne. Interrogez l'API des discussions et analysez position. --paginate est obligatoire : le point d'accès renvoie 20 fils par page, et sans lui le reste est ignoré sans erreur. Les fils déjà résolus sont ignorés :

glab api --paginate --output ndjson "$API/discussions" | python3 -c '
import sys, json
for line in sys.stdin:
    d = json.loads(line)
    n = d["notes"][0]
    if n.get("system") or n.get("resolved"): continue
    p = n.get("position") or {}
    print(d["id"], "|", n["author"]["username"], "|", n["body"])
    if p: print("   ->", p.get("new_path"), "new_line:", p.get("new_line"), "old_line:", p.get("old_line"))
'

• new_line = la ligne dans le fichier actuel (après modification) → c'est celle que vous lisez pour interpréter le commentaire.
• Un commentaire sur une ligne modifiée porte à la fois old_line et new_line ; ancrez-vous sur new_path + new_line.
• Pas de position → c'est un commentaire général (non en ligne).

2. Lire le code à chaque new_path:new_line, puis corriger

Ouvrez le fichier à la ligne citée pour que le commentaire ait du sens dans son contexte. Appliquez la correction seulement après l'avoir évaluée (voir receiving-code-review). Validez en un seul commit de correction de révision et poussez :

git add <fichiers>
git commit -m "fix(<portée>): corrige la révision sur <chose>"   # Conventional Commits, id du ticket dans le corps
git fetch origin <cible> && git rebase origin/<cible>
git push --force-with-lease   # un simple `git push` suffit seulement si le rebase était sans effet

3. Répondre à chaque fil et le résoudre

Publier sur le point d'accès notes d'une discussion auto-filète la réponse (pas besoin de in_reply_to_id). Puis mettez resolved=true :

DISC="<id de la discussion de l'étape 1>"
glab api -X POST "$API/discussions/$DISC/notes" -f "body=Fait: <ce que vous avez changé>."
glab api -X PUT  "$API/discussions/$DISC?resolved=true"

N'enveloppez jamais glab dans une fonction shell : les règles d'autorisation ne correspondent qu'à la commande littérale, écrivez donc les deux appels en entier pour chaque fil.

Rédaction de la réponse

Limitez-vous à ce qui a changé et pourquoi. Un relecteur veut le delta, pas l'enquête.

• Appliqué : une ou deux phrases. Ce que vous avez changé, tout ce que vous avez étendu au-delà de la ligne citée, le sha du commit. Fait, style bloc partout : les six composants, pas seulement cette ligne. Sortie rendue inchangée. f6511f29
• Désaccord ou reporté : le fait décisif en premier, l'option en second, la balle dans leur camp. Deux courts paragraphes au maximum. Coupez la remarque latérale, le troisième argument justificatif, le « heureux d'en discuter » de clôture.
• Ne racontez jamais la séquence de vos propres corrections et ne reformulez jamais le commentaire du relecteur.

Quels fils résoudre

Ne résolvez que ceux que vous avez effectivement clos.

• Changement appliqué -> réponse + résolution.
• Répondu à une question et la réponse la règle -> réponse + résolution.
• Une décision qui n'est pas la vôtre (environnement cible, portée, priorité) -> répondez, ne résolvez pas. Résoudre un fil que le relecteur doit encore arbitrer donne l'impression de le balayer, et il disparaît de leur liste de révision.

Référence rapide

Étape	Commande
Lister les commentaires en ligne + position	glab api --paginate --output ndjson "$API/discussions" → analyser .notes[].position.{new_path,new_line,old_line}
Répondre à un fil	glab api -X POST "$API/discussions/<id>/notes" -f "body=..."
Résoudre un fil	glab api -X PUT "$API/discussions/<id>?resolved=true"

Erreurs courantes

• Utiliser glab mr view --comments pour les commentaires en ligne : donne le texte sans fichier/ligne ; impossible de les localiser. Utilisez l'API des discussions.
• Inventer glab mr note resolve : résolvez via glab api -X PUT ".../discussions/<id>?resolved=true".
• Lire old_line au lieu de new_line : pour un commentaire sur une ligne modifiée, le code actuel est à new_line.
• Oublier --paginate : au-delà de 20 fils, l'API des discussions ne renvoie silencieusement que la première page.
• --force nu après le rebase : utilisez --force-with-lease, pour ne pas écraser un commit que le relecteur a poussé entre-temps.
• Appliquer les commentaires aveuglément : évaluez d'abord (receiving-code-review). Répondez avec ce que vous avez réellement changé, puis résolvez.
• Tronquer l'id de la discussion en listant les fils : l'API veut l'id complet de 40 caractères, un préfixe de 8 caractères renvoie 404 Discussion Not Found. Affichez d["id"] en entier.
• Trop expliquer dans la réponse : voir « Rédaction de la réponse ». Le raisonnement appartient à la description de la MR ou au ticket.
• Résoudre une décision reportée : si le relecteur doit encore choisir, laissez le fil ouvert.