New to Claude Skills? Learn how to install them →

rtk-ai on GitHub

PR Triage

Free

Streamline your pull request reviews with automated insights.

by rtk-ai75.5k stars on rtk-ai/rtk
1 views
Updated Aug 7, 2026
Get this skill

Free · Opens the source repo

What PR Triage does

PR Triage is a skill designed to help developers manage and review open pull requests (PRs) efficiently. By automating the auditing process, this skill provides a comprehensive overview of PRs, allowing users to focus their attention where it's most needed. The skill can be triggered manually or automatically when certain conditions are met, such as having more than five open PRs without reviews or when a PR has been stale for over 14 days.

The workflow consists of three phases: an automatic audit, an optional deep review of selected PRs, and the drafting of review comments. In the audit phase, the skill gathers essential data about open PRs, including metadata such as the number of additions and deletions, the status of continuous integration (CI), and existing reviews. This information is presented in a structured table that categorizes PRs into 'Our PRs', 'External - Ready for Review', and 'External - Problematic'. This categorization helps developers quickly identify which PRs need immediate attention.

For the deep review phase, users can specify which PRs to review in detail, either by selecting all external PRs or focusing on those flagged as problematic. This phase allows for a thorough examination of the code, ensuring that quality standards are met before merging. Additionally, the skill supports bilingual output, defaulting to French but allowing for English when specified. This makes it suitable for teams working in multilingual environments.

Overall, PR Triage is ideal for development teams looking to enhance their code review process. By automating the initial audit and providing structured insights, it helps developers save time and reduce the cognitive load associated with managing multiple PRs simultaneously.

When to use it

Use PR Triage when you have multiple open PRs and need to prioritize reviews efficiently, especially in larger teams or projects.

When not to use it

This skill may not be suitable for small teams with few PRs or for projects where manual review is preferred over automated insights.

What you can build with it

Large Team Code Reviews

In a large development team, use PR Triage to manage and prioritize reviews for multiple open pull requests, ensuring timely feedback.

Identifying Stale PRs

Automatically flag PRs that have been inactive for over 14 days, allowing the team to address potential bottlenecks.

Cross-Referencing PRs

Utilize the overlap detection feature to identify PRs that modify the same files, helping to avoid merge conflicts.

How to install PR Triage

View source

1. Install with the skills CLI

npx skills add rtk-ai/rtk/pr-triage --agent claude-code

2. Or install it manually

Download the skill folder and drop it into ~/.claude/skills/ for all projects, or .claude/skills/ to scope it to one repo. Restart Claude Code so it picks up the new skill.

Anthropic's agentic coding CLI, and the reference implementation of Agent Skills. Drop a skill folder into ~/.claude/skills and Claude Code loads it automatically whenever a task matches the skill's description. Claude Code docs

Inside SKILL.md

Written by rtk-ai

PR Triage

Quand utiliser

SkillUsageOutput
/pr-triageTrier, reviewer, commenter les PRsTableau d'action + reviews + commentaires postés
/repo-recapRécap général pour partager avec l'équipeRésumé Markdown (PRs + issues + releases)

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 --json nameWithOwner -q .nameWithOwner

# PRs ouvertes avec métadonnées complètes (ajouter body pour cross-référence issues)
gh pr list --state open --limit 50 \
  --json number,title,author,createdAt,updatedAt,additions,deletions,changedFiles,isDraft,mergeable,reviewDecision,statusCheckRollup,body

# Collaborateurs (pour distinguer "nos PRs" des externes)
gh api "repos/{owner}/{repo}/collaborators" --jq '.[].login'

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

# Extraire les auteurs des 10 derniers PRs mergés
gh pr list --state merged --limit 10 --json author --jq '.[].author.login' | sort -u

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

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

gh api "repos/{owner}/{repo}/pulls/{num}/reviews" \
  --jq '[.[] | .user.login + ":" + .state] | join(", ")'

# Fichiers modifiés (nécessaire pour overlap detection)
gh pr view {num} --json files --jq '[.files[].path] | join(",")'

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 :

LabelAdditions
XS< 50
S50–200
M200–500
L500–1000
XL> 1000

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 statusCheckRollupclean / 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 mergeableCONFLICTING 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

## PRs ouvertes ({count})

### Nos PRs
| PR | Titre | Taille | CI | Status |
| -- | ----- | ------ | -- | ------ |

### Externes — Prêtes pour review
| PR | Auteur | Titre | Taille | CI | Reviews | Action |
| -- | ------ | ----- | ------ | -- | ------- | ------ |

### Externes — Problématiques
| PR | Auteur | Titre | Taille | Problème | Action recommandée |
| -- | ------ | ----- | ------ | -------- | ------------------ |

### Résumé
- Quick wins : {PRs XS/S prêtes à merger}
- Risques : {overlaps, tailles XL, CI dirty}
- Clusters : {auteurs avec 3+ PRs}
- Stale : {PRs sans activité >14j}
- Overlaps : {PRs qui touchent les mêmes fichiers}

0 PRs → afficher Aucune PR ouverte. et terminer.

Copie automatique

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

# Cross-platform clipboard
clip() {
  if command -v pbcopy &>/dev/null; then pbcopy
  elif command -v xclip &>/dev/null; then xclip -selection clipboard
  elif command -v wl-copy &>/dev/null; then wl-copy
  else cat
  fi
}

clip <<'EOF'
{tableau de triage complet}
EOF

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 :

question: "Quelles PRs voulez-vous reviewer en profondeur ?"
header: "Deep Review"
multiSelect: true
options:
  - label: "Toutes les externes"
    description: "Review {N} PRs externes avec agents code-reviewer en parallèle"
  - label: "Problématiques uniquement"
    description: "Focus sur les {M} PRs à risque (CI dirty, trop large, overlaps)"
  - label: "Prêtes uniquement"
    description: "Review {K} PRs prêtes à merger"
  - label: "Passer"
    description: "Terminer ici — juste l'audit"

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 :

subagent_type: code-reviewer
model: sonnet
prompt: |
  Review PR #{num}: "{title}" by @{author}

  **Metadata**: +{additions}/-{deletions}, {changedFiles} files ({size_label})
  **CI**: {ci_status} | **Reviews**: {existing_reviews} | **Draft**: {isDraft}

  **PR Body**:
  {body}

  **Diff**:
  {gh pr diff {num} output}

  Apply your security-guardian and backend-architect skills for this review.
  Additionally, apply the RTK-specific checklist:
  - LazyLock<Regex> for fixed patterns reused across calls
  - anyhow::Result + .context() (no unwrap())
  - Fallback to raw command on filter failure
  - Exit code propagation
  - Token savings ≥60% in tests with real fixtures
  - No async/tokio dependencies

  Return structured review:
  ### Critical Issues 🔴
  ### Important Issues 🟡
  ### Suggestions 🟢
  ### What's Good ✅

  Be specific: quote the file:line, explain why it's an issue, suggest the fix.

Récupérer le diff via :

gh pr diff {num}
gh pr view {num} --json body,title,author -q '{body: .body, title: .title, author: .author.login}'

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 :

---
### Draft — PR #{num}: {title}

{commentaire complet}

---

Puis demander validation via AskUserQuestion :

question: "Ces commentaires sont prêts. Lesquels voulez-vous poster ?"
header: "Poster"
multiSelect: true
options:
  - label: "Tous ({N} commentaires)"
    description: "Poster sur toutes les PRs reviewées"
  - label: "PR #{x} — {title_truncated}"
    description: "Poster uniquement sur cette PR"
  - label: "Aucun"
    description: "Annuler — ne rien poster"

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

Posting

Pour chaque commentaire validé :

gh pr comment {num} --body-file - <<'REVIEW_EOF'
{commentaire}
REVIEW_EOF

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

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


Gestion des cas limites

SituationComportement
0 PRs ouvertesAucune PR ouverte. + terminer
PR en draftIndiquer dans tableau, skip pour review sauf si sélectionnée explicitement
CI inconnuAfficher ? dans colonne CI
Review agent timeoutAfficher erreur partielle, continuer avec les autres
gh pr diff videSkip cette PR, notifier l'utilisateur
PR très large (>5000 additions)Avertir : "Review partielle, diff tronqué"
Collaborateurs API 403/404Fallback sur auteurs des 10 derniers PRs mergés

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

Frequently asked questions about PR Triage

Similar skills