MCP.Market

pr-triage skill

by rtk-ai·rtk-ai/rtk·87k stars·Apache-2.0

PR triage: audit open PRs, deep review selected ones, draft and post review comments. Args: "all" to review all, PR numbers to focus (e.g. "42 57"), "en"/"fr" for language, no arg = audit only in French.

A100/100content scan

Is the pr-triage skill safe?

Clean: nothing in its files matched our rules. We read 2 files in the folder on 2026-11-10.

No findings.

Install the pr-triage skill

A skill is a folder. Copy it into your agent's skills folder and the agent loads it when the task matches its description.

git clone --depth 1 https://github.com/rtk-ai/rtk.git /tmp/rtk
mkdir -p ~/.claude/skills
cp -r /tmp/rtk/.claude/skills/pr-triage ~/.claude/skills/pr-triage
available in every project

In the Claude apps, zip the folder and upload it from the Skills settings. The folder on GitHub

The instructions your agent would load

SKILL.md as published, without the frontmatter. Read it on GitHub

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

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

## 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 ≥20% 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

More skills from rtk-ai/rtk

  • Acode-simplifierReview RTK Rust code for idiomatic simplification. Detects over-engineering, unnecessary allocations, verbose patterns. Applies Rust idioms without changing behavior.
  • Adesign-patternsRust design patterns for RTK. Newtype, Builder, RAII, Trait Objects, State Machine. Applied to CLI filter modules. Use when designing new modules or refactoring existing ones.
  • Aissue-triageIssue triage: audit open issues, categorize, detect duplicates, cross-ref PRs, risk assessment, post comments. Args: "all" for deep analysis of all, issue numbers to focus (e.g. "42 57"), "en"/"fr" for language, no arg = audit only in French.
  • AperformanceCLI performance optimization - startup time, memory usage, token savings benchmarking
  • Apr-reviewBatch 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.
  • Arepo-recapGenerate a comprehensive repo recap (PRs, issues, releases) for sharing with team. Pass "en" or "fr" as argument for language (default fr).
  • Drtk-tddEnforces TDD (Red-Green-Refactor) for Rust development. Auto-triggers on implementation, testing, refactoring, and bug fixing tasks. Provides Rust-idiomatic testing patterns with anyhow/thiserror, cfg(test), and Arrange-Act-Assert workflow.
  • Artk-triageTriage complet RTK : exécute issue-triage + pr-triage en parallèle, puis croise les données pour détecter doubles couvertures, trous sécurité, P0 sans PR, et conflits internes. Sauvegarde dans claudedocs/RTK-YYYY-MM-DD.md. Args: "en"/"fr" pour la langue (défaut: fr), "save" pour forcer la sauvegarde.
  • Fsecurity-guardianCLI security expert for RTK - command injection, shell escaping, hook security
  • AshipBuild, commit, push & version bump workflow - automates the complete release cycle
  • Atdd-rustTDD workflow for RTK filter development. Red-Green-Refactor with Rust idioms. Real fixtures, token savings assertions, snapshot tests with insta. Auto-triggers on new filter implementation.

All agent skills → · MCP servers