pr-triage

PR Triage

Quand utiliser

Déclencheurs :

• Manuellement : /pr-triage ou /pr-triage all ou /pr-triage 42 57
• Proactivement : quand >5 PRs ouvertes sans review, ou PR stale >14j détectée

Langue

• Vérifier l'argument passé au skill
• Si en ou english → tableaux et résumé en anglais
• Si fr, french, ou pas d'argument → français (défaut)
• Note : les commentaires GitHub (Phase 3) restent TOUJOURS en anglais (audience internationale)

Workflow en 3 phases : audit automatique → deep review opt-in → commentaires avec validation obligatoire.

Préconditions

git rev-parse --is-inside-work-tree
gh auth status

Si l'un échoue, stop et expliquer ce qui manque.

Phase 1 — Audit (toujours exécutée)

Data Gathering (commandes en parallèle)

# Identité du repo
gh repo view

Fallback collaborateurs : si gh api .../collaborators échoue (403/404) :

Si toujours ambigu, demander à l'utilisateur via AskUserQuestion.

Pour chaque PR, récupérer reviews existantes ET fichiers modifiés :

Note rate-limiting : la récupération des fichiers est N appels API (1 par PR). Pour repos avec 20+ PRs, prioriser les PRs candidates à l'overlap (même domaine fonctionnel, même auteur).

Note : author est un objet {login: "..."} — toujours extraire .author.login.

Analyse

Classification taille :

Format taille : +{additions}/-{deletions}, {files} files ({label})

Détections :

• Overlaps : comparer les listes de fichiers entre PRs — si >50% de fichiers en commun → cross-reference
• Clusters : auteur avec 3+ PRs ouvertes → suggérer ordre de review (plus petite en premier)
• Staleness : aucune activité depuis >14j → flag "stale"
• CI status : via statusCheckRollup → clean / unstable / dirty
• Reviews : approved / changes_requested / aucune

Liens PR ↔ Issues :

• Scanner le body de chaque PR pour fixes #N, closes #N, resolves #N (case-insensitive)
• Si trouvé, afficher dans le tableau : Fixes #42 dans la colonne Action/Status

Catégorisation :

Nos PRs : auteur dans la liste des collaborateurs

Externes — Prêtes : additions ≤ 1000 ET files ≤ 10 ET mergeable ≠ CONFLICTING ET CI clean/unstable

Externes — Problématiques : un des critères suivants :

• additions > 1000 OU files > 10
• OU mergeable == CONFLICTING (conflit de merge)
• OU CI dirty (statusCheckRollup contient des échecs)
• OU overlap avec une autre PR ouverte (>50% fichiers communs)

Output — Tableau de triage

0 PRs → afficher Aucune PR ouverte. et terminer.

Copie automatique

Après affichage du tableau de triage, copier dans le presse-papier :

Confirmer : Tableau copié dans le presse-papier. (FR) / Triage table copied to clipboard. (EN)

Phase 2 — Deep Review (opt-in)

Sélection des PRs

Si argument passé :

• "all" → toutes les PRs externes
• Numéros ("42 57") → uniquement ces PRs
• Pas d'argument → proposer via AskUserQuestion

Si pas d'argument, afficher :

Note sur les drafts :

• Les PRs en draft sont EXCLUES des options "Toutes les externes" et "Prêtes uniquement"
• Les PRs en draft sont INCLUSES dans "Problématiques uniquement" (car elles nécessitent attention)
• Pour reviewer un draft : taper son numéro explicitement (ex: 42)

Si "Passer" → fin du workflow.

Exécution des Reviews

Pour chaque PR sélectionnée, lancer un agent code-reviewer via Task tool en parallèle :

Récupérer le diff via :

Agréger tous les rapports. Afficher un résumé après toutes les reviews.

Phase 3 — Commentaires (validation obligatoire)

Génération des drafts

Pour chaque PR reviewée, générer un commentaire GitHub en utilisant le template templates/review-comment.md.

Règles :

• Langue : anglais (audience internationale)
• Ton : professionnel, constructif, factuel
• Toujours inclure au moins 1 point positif
• Citer les lignes de code quand pertinent (format file.rs:42)

Affichage et validation

Afficher TOUS les commentaires draftés au format :

Puis demander validation via AskUserQuestion :

(Générer une option par PR + "Tous" + "Aucun")

Posting

Pour chaque commentaire validé :

Confirmer chaque post : ✅ Commentaire posté sur PR #{num}: {title}

Si "Aucun" → Aucun commentaire posté. Workflow terminé.

Gestion des cas limites

Notes

• Toujours dériver owner/repo via gh repo view, jamais hardcoder
• Utiliser gh CLI (pas curl GitHub API) sauf pour la liste des collaborateurs
• statusCheckRollup peut être null → traiter comme ?
• mergeable peut être MERGEABLE, CONFLICTING, ou UNKNOWN → traiter UNKNOWN comme ?
• Ne jamais poster sans validation explicite de l'utilisateur dans le chat
• Les commentaires draftés doivent être visibles AVANT tout gh pr comment