PyTorch PR Review Skill

Examiner les pull requests PyTorch en se concentrant sur ce que CI ne peut pas vérifier : la qualité du code, l'adéquation de la couverture de tests, les vulnérabilités de sécurité et la compatibilité rétroactive.

Modes d'utilisation

Aucun argument

Si l'utilisateur invoque /pr-review sans arguments, ne pas effectuer de review. À la place, demander à l'utilisateur ce qu'il souhaite examiner :

Qu'aimeriez-vous que j'examine ?

Un numéro de PR ou une URL (p. ex. /pr-review 12345)

Une branche locale (p. ex. /pr-review branch)

Mode CLI local

L'utilisateur fournit un numéro de PR ou une URL :

/pr-review 12345
/pr-review https://github.com/pytorch/pytorch/pull/12345

Pour une review détaillée avec des commentaires spécifiques ligne par ligne :

/pr-review 12345 detailed

Utiliser gh CLI pour récupérer les données de la PR :

# Obtenir les détails de la PR
gh pr view <PR_NUMBER> --json title,body,author,baseRefName,headRefName,files,additions,deletions,commits

# Obtenir le diff
gh pr diff <PR_NUMBER>

# Obtenir les commentaires de la PR
gh pr view <PR_NUMBER> --json comments,reviews

Mode branche locale

Examiner les modifications dans la branche actuelle qui ne sont pas dans main :

/pr-review branch
/pr-review branch detailed

Utiliser les commandes git pour obtenir les modifications de la branche :

# Obtenir le nom de la branche actuelle
git branch --show-current

# Obtenir la liste des fichiers modifiés par rapport à main
git diff --name-only main...HEAD

# Obtenir le diff complet par rapport à main
git diff main...HEAD

# Obtenir l'historique des commits de la branche
git log main..HEAD --oneline

# Obtenir les statistiques de diff (fichiers modifiés, insertions, suppressions)
git diff --stat main...HEAD

Pour les reviews de branche locale :

Le « Summary » doit décrire ce que les modifications de la branche accomplissent en fonction des messages de commit et du diff
Utiliser le nom de la branche actuelle dans l'en-tête de la review au lieu d'un numéro de PR
Tous les autres critères de review s'appliquent de la même façon que pour les reviews de PR

Mode GitHub Actions

Lorsqu'il est invoqué via @claude /pr-review sur une PR GitHub, l'action pré-récupère les métadonnées de la PR et les injecte dans le prompt. Détecter ce mode par la présence de balises <formatted_context>, <pr_or_issue_body> et <comments> dans le prompt.

Le prompt contient déjà :

Les métadonnées de la PR (titre, auteur, noms des branches, additions/suppressions, nombre de fichiers)
Le corps/la description de la PR
Tous les commentaires et commentaires de review (avec références fichier/ligne)
Liste des fichiers modifiés avec chemins et types de modifications

Utiliser les commandes git pour obtenir le diff et l'historique des commits. Le nom de la branche de base se trouve dans le contexte du prompt (chercher PR Branch: <head> -> <base> ou le champ baseBranch).

# Obtenir le diff complet par rapport à la branche de base
git diff origin/<baseBranch>...HEAD

# Obtenir les statistiques de diff
git diff --stat origin/<baseBranch>...HEAD

# Obtenir l'historique des commits pour cette PR
git log origin/<baseBranch>..HEAD --oneline

# Si la référence de la branche de base n'est pas disponible, la récupérer d'abord
git fetch origin <baseBranch> --depth=1

NE PAS utiliser les commandes gh CLI dans ce mode -- seules les commandes git sont disponibles. Toutes les métadonnées de la PR, les commentaires et les reviews sont déjà dans le contexte du prompt ; seul le diff et l'historique des commits doivent être récupérés via git.

Philosophie de review

Une seule ligne de code peut avoir des implications profondes transversales : un guard de device manquant provoque une corruption silencieuse des données en multi-GPU, une clé de dispatch Composite manquante casse tous les backends out-of-tree, une vérification manuelle de dtype au lieu de TensorIterator saute silencieusement la promotion de type. Traiter chaque ligne comme potentiellement porteuse de charge.

Signaler uniquement les problèmes — La sortie de la review doit contenir uniquement les problèmes, préoccupations et suggestions exploitables. NE PAS mentionner les choses qui sont faites correctement, NE PAS féliciter les bonnes décisions, NE PAS expliquer pourquoi quelque chose va bien. Si une section n'a pas de problèmes, l'omettre entièrement. Le temps du lecteur est précieux — chaque phrase doit pointer vers quelque chose qui doit être corrigé ou discuté.
Investiguer, ne pas deviner — En cas d'incertitude sur l'applicabilité d'un point de la checklist, lancer un sous-agent pour lire le code pertinent. Un reviewer qui se trompe fournit une valeur négative.
Examiner la conception, pas seulement l'implémentation — Une PR peut avoir une implémentation parfaitement correcte d'une mauvaise conception. Remettre en question les communications de side-channel, les drapeaux privés on/off, et exiger une documentation d'interface concrète pour les nouveaux contrats entre composants.
Se concentrer sur ce que CI ne peut pas vérifier — Ne pas commenter le formatage, le linting, les erreurs de type ou les échecs de CI. Se concentrer sur la qualité de la conception, la correction de l'interface, la sécurité des threads, les implications de BC, l'adéquation des tests et le respect des modèles.
Tout est un must-fix — Il n'y a pas de « nits ». Si c'est worth mentionner, c'est worth corriger. Chaque incohérence dégrade la base de code au fil du temps.
Être spécifique et exploitable — Référencer les chemins de fichiers et les numéros de ligne. Nommer la fonction/classe/fichier que l'auteur doit utiliser.
Correspondre au contexte immédiat — Lire comment des fonctionnalités similaires sont déjà implémentées dans le même fichier. Les non-correspondances de modèles dans un fichier sont toujours incorrectes.
Supposer la compétence — L'auteur connaît PyTorch ; expliquer uniquement le contexte non évident.
Pas de répétition — Chaque observation apparaît dans exactement une section de la sortie de la review.

Utiliser des sous-agents

La checklist de review est grande. On ne peut pas garder en tête le contexte complet de chaque système d'infrastructure. Lancer des sous-agents pour investiguer si les points de la checklist s'appliquent : lire le code environnant, l'infrastructure que la PR devrait utiliser, ou les tests qui devraient exister. Les lancer en parallèle pour les zones indépendantes. Une PR typique de taille moyenne devrait lancer 3-8 sous-agents.

Flux de work de la review

Étape 1 : Comprendre le contexte

Avant de faire la review, construire une compréhension de ce que la PR touche et pourquoi :

Identifier l'objectif de la modification à partir du titre/description/issue
Grouper les modifications par type (nouveau code, tests, config, docs)
Noter la portée des modifications (fichiers affectés, lignes modifiées)
Lancer des sous-agents pour lire le code inchangé entourant chaque fichier significativement modifié afin de comprendre les modèles et l'infrastructure existants

Étape 2 : Review approfondie

Passer en revue chaque ligne modifiée du diff et l'évaluer par rapport à la checklist de review dans review-checklist.md.

Étape 3 : Vérifier la compatibilité rétroactive

Évaluer les implications de BC selon bc-guidelines.md. Pour les questions de BC non triviales, lancer un sous-agent pour rechercher les appelants existants de l'API modifiée.

Étape 4 : Formuler la review

Structurer votre review avec des retours exploitables organisés par catégorie. Chaque finding doit être traçable jusqu'à une ligne spécifique du diff.

Étape 5 : Vérifier les faits

Après avoir rédigé la review, lancer un sous-agent par problème rapporté (en parallèle) pour vérifier indépendamment la réclamation en relisant le code pertinent et le contexte environnant. Chaque sous-agent retourne valid, invalid, ou needs rewording. Supprimer les problèmes invalides, reformuler le reste. Si incertain, laisser le problème avec un commentaire pour l'auteur indiquant que cette confiance est faible.

Format de sortie

Structurer votre review comme suit. Omettre les sections où vous n'avez pas de problèmes à signaler — la plupart des reviews ne devraient avoir que quelques sections. Ne pas écrire « No concerns », « Looks good », ou tout commentaire affirmatif. Chaque phrase de la review doit identifier un problème ou demander une modification.

La section Summary est l'exception : elle doit brièvement décrire ce que la PR fait (1 phrase) puis énoncer les problèmes trouvés, ou explicitement dire qu'aucun problème n'a été trouvé.

## PR Review: #<number>
<!-- Ou pour les reviews de branche locale : -->
## Branch Review: <branch-name> (vs main)

### Summary
Ce que la PR fait (1 phrase), puis le verdict global.

### Code Quality
[Problèmes uniquement]

### Infrastructure
[Problèmes uniquement — signaler les points de la checklist qui sont violés]

### Testing
[Problèmes uniquement — tests manquants, mauvais modèles, couverture inadéquate]

### API Design
[Problèmes uniquement]

### Security
[Problèmes uniquement]

### Thread Safety
[Problèmes uniquement]

### Backward Compatibility
[Problèmes uniquement]

### Performance
[Problèmes uniquement]

### Recommendation
**Approve** / **Request Changes** / **Needs Discussion**

Les tests manquants (nouvelle fonctionnalité sans tests, corrections de bugs sans tests de régression) signifient toujours **Request Changes**.

[Justification brève — se concentrer sur ce qui bloque l'approbation, le cas échéant]

Commentaires spécifiques (Review détaillée uniquement)

Inclure cette section uniquement si l'utilisateur demande une review « detailed » ou « in depth ».

Ne pas répéter les observations déjà faites dans d'autres sections. Cette section concerne les retours spécifiques au fichier qui ne rentrent pas dans les sections catégorisées ci-dessus.

Lorsque demandé, ajouter des retours spécifiques au fichier avec références de ligne :

### Specific Comments
- `src/module.py:42` - Considérer l'extraction de cette logique dans une fonction nommée pour plus de clarté
- `test/test_feature.py:100-105` - Test manquant pour le cas d'erreur quand l'entrée est None
- `torch/nn/modules/linear.py:78` - Cette allocation pourrait être déplacée en dehors de la boucle

Fichiers à référencer

Lors de la review, consulter ces fichiers du projet pour le contexte — les lire plutôt que de se fier à la mémoire, car ils changent fréquemment :

CLAUDE.md - Philosophie de style de codage et modèles de test
CONTRIBUTING.md - Exigences de PR et processus de review
torch/testing/_internal/common_utils.py - Modèles et utilitaires de test
torch/testing/_internal/opinfo/core.py - Framework de test OpInfo
aten/src/ATen/native/native_functions.yaml - Déclarations d'opérateurs (pour vérifier les tags, les clés de dispatch, les kernels structurés)
tools/autograd/derivatives.yaml - Formules rétroactives (pour vérifier si une op doit s'enregistrer ici)
aten/src/ATen/native/tags.yaml - Tags sémantiques d'opérateur