/pr-review

Batch review 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

bash
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)

bash
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 :

| Taille | Critère | Traitement | |--------|---------|------------| | XS | < 30 lignes, 1 fichier | En premier | | S | 30-100 lignes, 1-3 fichiers | Ensuite | | M | 100-200 lignes, logique non triviale | Après | | L | > 200 lignes | Dernier ou skip | | XL | > 500 lignes | Skip (session dédiée) |

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)

bash
# 1. Etat 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 :

| État | Action | |------|--------| | MERGEABLE + CLA ok + pas de CHANGES_REQUESTED | → lire le diff | | CONFLICTING | → préparer commentaire rebase, skip diff | | CLA non signé | → préparer commentaire CLA, skip diff | | CHANGES_REQUESTED par un maintainer | → skip (ne pas override), noter | | Draft | → skip silencieusement |

Étape B — Lire le diff complet

bash
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 :

| Réponse | Action | |---------|--------| | "ok" / "go" / "merge" | Merger avec gh pr merge --merge | | "skip" / "next" | Passer à la PR suivante sans merger | | "comment" | Poster un commentaire (demander le texte si pas fourni) | | "close" | Fermer la PR | | Retour avec instructions | Appliquer puis redemander confirmation |

Étape E — Merger (si validé)

bash
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