Examen interactif des PR — NVIDIA-NeMo/RL

Examinez une pull request ou une branche locale de manière interactive, en appliquant les directives de codage du projet.

Analyser les arguments

• Si $ARGUMENTS contient un nombre → mode PR avec ce numéro de PR
• Si $ARGUMENTS est vide ou ne contient aucun nombre → mode LOCAL (examiner la branche actuelle par rapport à main)
• Si $ARGUMENTS contient update → mode UPDATE (mode PR uniquement)
• Si $ARGUMENTS contient --deep → utiliser des sous-agents parallèles pour un examen plus approfondi

Repo : NVIDIA-NeMo/RL

Exemples :

• /review-pr 123 — examiner la PR #123, agent unique
• /review-pr 123 --deep — examiner la PR #123 avec des sous-agents parallèles
• /review-pr 123 update — relancer les discussions existantes pour la PR #123
• /review-pr — examiner la branche actuelle par rapport à main, sortie terminal uniquement

Phase 1 : Configuration

Mode PR

git fetch origin pull/$PRNUM/head:pr-$PRNUM-review
git checkout pr-$PRNUM-review

Mode LOCAL

Vous êtes déjà sur la bonne branche. Déterminez la base de fusion :

git merge-base main HEAD

Phase 2 : Rassembler le contexte

Mode PR — récupérations MCP parallèles

Tous avec owner=NVIDIA-NeMo, repo=RL, pullNumber=$PRNUM :

1. mcp__github__pull_request_read méthode=get → titre de PR, description, auteur, branche de base, labels, SHA de head
2. mcp__github__pull_request_read méthode=get_diff → diff complet
3. mcp__github__pull_request_read méthode=get_files → liste des fichiers modifiés
4. mcp__github__pull_request_read méthode=get_review_comments → discussions d'examen existantes
5. mcp__github__pull_request_read méthode=get_reviews → examens existants
6. mcp__github__pull_request_read méthode=get_comments → commentaires généraux sur la PR

Mode LOCAL — git diff

git diff $(git merge-base main HEAD)..HEAD
git diff $(git merge-base main HEAD)..HEAD --name-only

Aucun appel MCP nécessaire.

Les deux modes — lectures locales

7. Lire @CLAUDE.md à la racine du repo pour la philosophie d'examen
8. Lire tous les fichiers .claude/skills/*/SKILL.md (sauf review-pr) pour les règles de directives
9. Glob .claude/review-memory/*.md — s'il y en a, les lire pour les modèles appris

Phase 3 : Analyser

Mode agent unique (par défaut)

Analysez tous les changements vous-même. Retournez une liste de problèmes candidats — chacun avec fichier, ligne, catégorie et description. Ne les notez PAS encore ; la notation se fait à l'étape de validation (Phase 3b).

Mode deep (--deep) — sous-agents parallèles

Lancez 3 sous-agents opus en parallèle à l'aide de l'outil Agent. Fournissez à chacun le diff, la description de PR (si mode PR), et le contenu des skills de directives. Chacun retourne une liste de problèmes candidats (fichier, ligne, catégorie, description). Ne leur demandez PAS de noter — la notation se fait en Phase 3b.

Sous-agent 1 — Conformité aux directives : Examinez le diff par rapport à tous les skills de directives (code-style, config-conventions, error-handling, testing, copyright, docs). Pour chaque violation, retournez le fichier, la ligne, la description et quel skill elle viole.

Sous-agent 2 — Scan de bugs (diff uniquement) : Scannez pour les bugs évidents dans le diff sans lire le contexte environnant. Signalez les erreurs de syntaxe, les erreurs de type, les erreurs de logique claires, les imports manquants, les références non résolues.

Sous-agent 3 — Scan de bugs contextuel : Lisez le code environnant et l'historique git pour chaque fichier modifié. Cherchez les bugs qui ne deviennent apparents qu'avec le contexte : utilisation incorrecte d'API (notamment megatron-bridge, megatron-lm, automodel, gym), conditions de course, hypothèses brisées.

Après que tous les sous-agents retournent : fusionnez les résultats et dédupliquez (même fichier+ligne+problème = une découverte). Puis passez à la Phase 3b.

Règles d'analyse (tous les modes)

Mode NEW

• Analysez le diff par rapport à tous les skills de directives
• Pour chaque fichier modifié, lisez le contexte environnant localement en utilisant Read et Grep pour comprendre le changement en contexte
• Croisez les commentaires d'examen existants (mode PR uniquement, à partir de l'étape 4) pour éviter de dupliquer les points déjà soulevés par d'autres examinateurs
• Appliquez aussi les modèles issus des fichiers de mémoire d'examen
• Catégorisez les découvertes :
  • [BUG] — Erreurs de logique, références nulles, conditions de course, erreurs de syntaxe
  • [TEST] — Couverture de test manquante ou insuffisante
  • [GUIDELINE] — Violations des directives de codage des skills
  • [DOC] — Documentation obsolète ou manquante

Mode UPDATE (mode PR uniquement)

• Examinez tous les discussions d'examen non résolues sur la PR
• Pour chaque discussion, déterminez si une action est nécessaire :
  1. Nous ne sommes pas d'accord avec la réponse → rédigez un commentaire comme « Nous pouvons résoudre cette discussion parce que XYZ »
  2. L'auteur a posé une question ou fait un commentaire qui nécessite une réponse → rédigez une réponse
• POUVEZ aussi créer de nouveaux commentaires si vous remarquez quelque chose de justifié lors de l'examen des discussions
• Ignorez les discussions qui sont résolues ou où aucune réponse n'est nécessaire

Phase 3b : Valider et noter

Pour chaque problème candidat de la Phase 3, lancez un sous-agent opus de validation séparé à l'aide de l'outil Agent. Lancez-les en parallèle (regroupez tous à la fois).

Chaque sous-agent de validation reçoit :

• Le problème candidat (fichier, ligne, catégorie, description)
• Le contexte de code pertinent (le chunk diff + lignes environnantes)
• Le titre et la description de PR (si mode PR)
• Le contenu du skill de directive spécifique (s'il s'agit d'une violation de directive)

Le travail du sous-agent de validation :

1. Vérifier indépendamment que le problème est réel en examinant le code réel — par exemple, si le problème dit « la variable n'est pas définie », vérifiez qu'elle est réellement indéfinie ; si elle dit qu'une règle CLAUDE.md/skill est violée, confirmez que la règle s'applique à ce fichier
2. Attribuer un score de confiance (0-100) :

3. Retourner : validé (oui/non), score de confiance, et optionnellement une description affinée

Filtre : éliminez tout problème notant moins de 80. Ce sont les faux positifs que nous voulons éviter.

Phase 4 : Aperçu et confirmation

Affichez les découvertes à l'utilisateur avec les scores de confiance :

Mode PR

PR #<number>: <title> (par <author>)
Fichiers modifiés : <count>

--- Découvertes (notées ≥80) ---
[BUG 95] path/to/file.py:42 — <brief description>
  Suggéré : « <le texte du commentaire> »

[GUIDELINE 85] path/to/other.py:15 — <brief description>
  Suggéré : « <le texte du commentaire> »

--- Filtrées (notées <80) ---
N problèmes de faible confiance omis

--- Ignorées (déjà couvertes par d'autres examinateurs) ---
- <brief list>

--- Réponses aux discussions (<count>) --- (mode UPDATE uniquement)
Discussion sur file.py:10 (par <author>) — <planned action>
  Réponse suggérée : « <le texte de la réponse> »

Puis utilisez AskUserQuestion :

• Options : (1) Publier tout — tout poster comme indiqué, (2) Discuter individuellement — passer en revue chaque élément un par un, (3) Annuler — ne rien faire
• Si l'utilisateur choisit « Discuter individuellement » : itérez à travers les éléments. Pour chacun, demandez s'il souhaite approuver, modifier le texte ou ignorer.

Mode LOCAL

Branche : <branch-name> (par rapport à main)
Fichiers modifiés : <count>

--- Découvertes (notées ≥80) ---
[BUG 95] path/to/file.py:42 — <brief description>
[GUIDELINE 85] path/to/other.py:15 — <brief description>

--- Filtrées (notées <80) ---
N problèmes de faible confiance omis

Pas d'étape de publication — sortie terminal uniquement. Demandez si l'utilisateur souhaite discuter de découvertes.

Phase 5 : Publier l'examen (mode PR uniquement)

Nouveaux commentaires (modes NEW et UPDATE)

1. Créer un examen en attente : mcp__github__pull_request_review_write avec method=create, commitID=<head_sha> (aucun event — crée un examen en attente)
2. Pour chaque commentaire approuvé : mcp__github__add_comment_to_pending_review avec :
   • path : chemin de fichier relatif
   • line : numéro de ligne sur le côté DROIT du diff
   • side : RIGHT
   • subjectType : LINE (ou FILE si le commentaire est au niveau du fichier)
   • body : le texte du commentaire
3. Soumettre l'examen : mcp__github__pull_request_review_write avec method=submit_pending, event=COMMENT, body=<one-line summary of findings>

Si un numéro de ligne ne peut pas être mappé à partir du diff, recourez à subjectType: FILE.

Réponses aux discussions (mode UPDATE)

Pour chaque réponse à un discussion : mcp__github__add_reply_to_pull_request_comment avec :

• commentId : l'ID du commentaire auquel on répond
• body : le texte de la réponse

Phase 6 : Mettre à jour la mémoire d'examen

Après l'examen (modes PR et LOCAL), pour chaque commentaire/découverte que l'utilisateur a approuvé ou discuté :

1. Glob .claude/review-memory/*.md pour les modèles existants
2. Vérifiez si un fichier couvre déjà ce modèle (en lisant les titres)
3. Si un fichier de mémoire correspondant existe :
   • Ajoutez la nouvelle occurrence à la section ## Occurrences
   • Demandez à l'utilisateur : « Le modèle « <name> » s'est déjà produit. Promouvoir au skill <skill-name> ? (oui/non) »
   • Si oui → ajoutez comme nouvelle sous-section dans le SKILL.md du skill approprié, puis supprimez le fichier de mémoire
   • Si non → gardez en mémoire
4. Si aucun fichier de mémoire correspondant n'existe :
   • Créez un nouveau fichier plat dans .claude/review-memory/ avec ce format :

# <Pattern Name>

**Do:** <what to do instead>
**Don't:** <the anti-pattern>

## Occurrences
- PR #<number>: <file>:<line> (<date>)

Créez le répertoire .claude/review-memory/ s'il n'existe pas (mkdir -p).