ChristianSavinoDP/Claude-Skills

Revue de PR

Procédure pour la revue d'une Pull Request. Les règles de la revue (ton, catégories de commentaires, flux de décision, ce qu'il ne faut pas faire) se trouvent dans le Playbook sous "Revues de PR" ; cette compétence décrit le comment. Ne répétez pas les règles ici, appliquez-les. Les "Standards partagés" du Playbook s'appliquent tout au long (concis, pas de contenu IA superflu, vérifiez n'affirmez pas, n'inventez jamais).

Avant la revue

1. Demandez d'abord le ticket. Conformément à l'étape obligatoire du Playbook, ne récupérez pas le diff et n'analysez rien avant d'avoir le ticket. Le ticket définit le type de travail (fonctionnalité vs suivi vs investigation) et les critères d'acceptation, qui modifient la façon de revoir.
2. Identifiez la PR : demandez le numéro/URL de la PR si non fourni(e).

Rassembler le contexte

• Récupérez le diff et les métadonnées avec la CLI GitHub : gh pr view <pr> et gh pr diff <pr>.
• Pour une PR d'investigation, vérifiez également docs/investigations/ pour le format attendu.
• Lisez les fichiers modifiés en entier, pas seulement les extraits du diff, lorsque le comportement dépend du code environnant.

Revue

Parcourez le diff fichier par fichier. Appliquez la section "Revues de PR" du Playbook :

• Exécutez la checklist du Playbook (critères d'acceptation, échecs de compilation/test, appelants mis à jour, couverture de test, preuves pour les investigations).
• Classez chaque observation comme bloquante, mineure ou question, conformément au Playbook.
• Utilisez le flux de décision du Playbook pour décider si chaque observation mérite un commentaire.
• Les règles de périmètre diffèrent selon le type de ticket (suivi : tout résoudre ici ; fonctionnalité : les refactorings sont valides). Confirmez le type à partir du ticket.
• Conformément au Playbook "Vérifiez, n'affirmez pas" : vérifiez les affirmations vous-même avant de les répéter. Lancez gh pr checks <pr> pour la CI, cherchez les symboles supprimés dans le dépôt. La description de la PR est une affirmation de l'auteur, pas une preuve.
• Conformément au Playbook "Ne supprimez pas silencieusement un comportement existant" : une régression comportementale non confirmée est une observation bloquante, même si l'auteur l'a signalée dans la description.

Sortie

Suivez le Playbook "Revues de PR > Format". Produisez la revue directement dans le chat (pas un fichier, sauf si l'utilisateur en demande un), sous forme d'un verdict sur une ligne puis des constats. Ce n'est PAS un essai en prose, un journal de conversation ou des sections comme "Contexte rassemblé"/"Revue initiale". Chaque constat est exactement : une ligne de référence de localisation+code, le commentaire dans un bloc fencé prêt à être copié-collé, puis le pourquoi. Concrètement, un constat ressemble à ceci :

### Bloquant

`internal/adapters/users/adapter.go:281`
```go
_, err := u.providersClient.Update(ctx, request)
```

Commentaire (à coller dans la PR) :

Cela supprime la reprise sur erreur de cohérence éventuelle sur laquelle ces écritures comptent. Le décalage Core->Utilisateurs se manifeste par NotFound, que la nouvelle politique uniquement transitoire ne relancera pas, donc l'écriture échoue immédiatement.

Pourquoi : Le CA #3 demande de confirmer qu'aucun chemin ne repose sur la relance des erreurs au niveau applicatif ; ce chemin le faisait, et le diff le supprime sans confirmer que la fenêtre a disparu.
````

Répétez un tel bloc par constat, regroupés sous `### Bloquant` / `### Mineurs` / `### Questions` (omettez les groupes vides). Le bloc fencé après "Commentaire" est la seule chose que l'utilisateur copie dans GitHub ; tout le reste est pour la navigation. Si tout est bon, seulement la ligne de verdict.

## Publication (uniquement si demandé)

Si l'utilisateur souhaite que les commentaires soient publiés plutôt que rédigés dans le chat, confirmez d'abord, puis utilisez `gh pr review` / `gh pr comment`. Par défaut, rédigez dans le chat.