/pr-review

Examen par lots des PRs RTK — du plus simple au plus complexe, une par une, avec validation utilisateur avant chaque merge.

Quand utiliser

• Après un /rtk-triage pour agir sur les résultats
• Régulièrement pour dégraisser le backlog
• Avant une release pour vider la file quick wins

Workflow

Phase 0 — Préconditions

git rev-parse --is-inside-work-tree
gh auth status
date +%Y-%m-%d

Si l'argument triage est passé, exécuter /rtk-triage d'abord et utiliser sa liste de quick wins comme séquence. Sinon, construire la liste soi-même.

Phase 1 — Construire la liste de PRs (si pas de triage)

gh pr list --state open --limit 200 \
  --json number,title,author,additions,deletions,changedFiles,mergeable,mergeStateStatus,isDraft,statusCheckRollup,reviewDecision,body \
  | jq 'sort_by(.additions + .deletions)'

Classement par taille :

Filtrer d'emblée :

• Exclure les PRs draft
• Exclure les PRs de nous (les nôtres ont une review flow différente)
• Si from:<num> passé en argument : commencer à ce numéro

Phase 2 — Pour chaque PR (une par une, dans l'ordre)

Étape A — Vérification état (AVANT de lire le diff)

# 1. État mergeable + CLA
gh pr view <num> --json mergeable,mergeStateStatus,statusCheckRollup,reviewDecision

# 2. Reviews existantes (CHANGES_REQUESTED ?)
gh api repos/rtk-ai/rtk/pulls/<num>/reviews \
  --jq '.[] | {author: .user.login, state: .state, body: .body}'

# 3. Commentaires inline (si CHANGES_REQUESTED)
gh api repos/rtk-ai/rtk/pulls/<num>/comments \
  --jq '.[] | {author: .user.login, body: .body, path: .path, line: .line}'

Décision rapide selon état :

Étape B — Lire le diff complet

gh pr diff <num>

Si le diff touche une logique complexe (filter functions, regex, routing) → lire le fichier source en contexte avec Read pour comprendre l'impact réel.

Étape C — Présenter à l'utilisateur

Format de présentation obligatoire pour chaque PR :

**PR #<num>** — https://github.com/rtk-ai/rtk/pull/<num>

**Author**: <login> | **Size**: <XS/S/M/L> (+<add> -<del>, <N> fichiers) | **CLA**: <ok/non signé> | **Mergeable**: <clean/conflit>

**Ce que ça fait** — [description en 2-4 phrases : le problème résolu, les fichiers touchés, la logique modifiée, les tests ajoutés]

**Qualité du diff** : [analyse honnête : propre/à vérifier/problème détecté]

Merge #<num> ?

Règles de présentation :

• Toujours inclure le lien GitHub cliquable
• Toujours mentionner si des tests couvrent le changement
• Si une fonction complexe est touchée, expliquer l'impact
• Ne pas embellir — si le diff est moyen, le dire
• Langue : français pour l'analyse (comme ici)

Étape D — Attendre la validation

NE JAMAIS MERGER SANS RÉPONSE EXPLICITE. Les réponses attendues :

Étape E — Merger (si validé)

gh pr merge <num> --merge --squash

Confirmer immédiatement : Merged #<num>. ✓

Puis vérifier que la PR suivante n'est pas passée en CONFLICTING à cause du merge (surtout si les deux touchent rules.rs, registry.rs, main.rs, ou CHANGELOG.md).

Phase 3 — PRs bloquées : commentaire boldguy-adapt

Pour les PRs avec conflit, CLA manquant, ou besoin de rebase, poster un commentaire en anglais, ton boldguy-adapt.

Règles du commentaire :

• Anglais uniquement (GitHub)
• Remercier la contribution en ouverture (sincèrement, pas de manière générique)
• Dire clairement ce qui bloque (1-2 points max)
• Donner les étapes exactes pour débloquer
• Pas d'em dash (—), pas de staccato, longueurs de phrases variées
• Ne pas sonner comme un bot

Template conflit + CLA :

Hey @<author>, thanks for the contribution! [mention spécifique de ce que la PR apporte]

Two things before we can merge:

1. The branch needs a rebase on `develop` — there's a conflict on [fichier]. A `git rebase origin/develop` should do it.

2. The CLA hasn't been signed yet. The CLAassistant bot left instructions in the PR — just follow the link, takes about a minute.

Once both are sorted, this will move quickly.

Template conflit seul :

Hey @<author>, good fix on [description spécifique]. One thing to address before merge: the branch has a conflict on [fichier] after recent changes to develop. A `git rebase origin/develop` should resolve it cleanly.

Template CLA seul :

Hey @<author>, thanks for [description spécifique]. The only thing blocking merge is the CLA signature — the CLAassistant bot left the link in the PR. Once that's done, we're good to go.

Phase 4 — Récap de session

Après avoir traité toutes les PRs (ou à la demande) :

## Session recap — YYYY-MM-DD

| PR | Titre | Action | Raison |
|----|-------|--------|--------|
| #N | titre | Mergé ✓ | — |
| #N | titre | Skip | CHANGES_REQUESTED (KuSh) |
| #N | titre | Commenté | Conflit + CLA |
| #N | titre | Fermé | Doublon avec #M |

Mergées : N | Skippées : N | Commentées : N

Règles

• Une PR à la fois — ne jamais présenter plusieurs PRs en attente de validation
• Jamais merger sans "ok" explicite — "ça a l'air bien" n'est pas un ok
• Ne pas overrider un CHANGES_REQUESTED d'un maintainer sans instructions explicites de l'utilisateur
• Vérifier les conflits post-merge sur la PR suivante si les deux touchent les mêmes fichiers
• Langue : analyse en français, commentaires GitHub en anglais
• Ton boldguy : factuel, direct, bienveillant, pas de marqueurs AI (em dash, staccato, punchline finale parfaite)

Fichiers fréquemment en conflit (surveiller)

• CHANGELOG.md — toutes les PRs y touchent
• src/discover/rules.rs — ajouts fréquents de règles
• src/discover/registry.rs — tests de classify/rewrite
• src/main.rs — routing des commandes
• src/hooks/rewrite_cmd.rs — rewrites hooks