/pr-review

description: >
  Batch review des PRs RTK par ordre de complexité croissante (XS → S → M → L).
  Pour chaque PR : vérifie l'état (conflits, CLA, reviews), lit le diff complet,
  analyse le code en contexte, présente un résumé avec lien + taille + recommandation.
  Attend validation explicite avant tout merge. Poste des commentaires boldguy-adapt
  sur les PRs bloquées (conflit, CLA, CHANGES_REQUESTED).
  Args: "triage" pour lancer un triage complet avant la review. "from:<num>" pour
  reprendre à partir d'un numéro de PR spécifique.
allowed-tools:
  - Bash
  - Read
  - Grep
  - Glob
  - Write
  - AskUserQuestion

/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

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

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

# 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

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

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 @<auth