跳到正文
cccskills
免费在 GitHub 公开

pr-triage

Sort open GitHub pull requests by change size, automated check results, conflicts, and inactivity. Review selected changes in detail, draft constructive feedback, and post comments after the user approves them.

中文简介正在准备中。当前显示英语简介。

原文查看原文说明

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.

集成工具GitHub
查看安装方法

适用场景

  • Prioritizing a backlog of open pull requests
  • Finding overlapping changes and failing checks
  • Reviewing selected pull requests in detail
  • Approving review comments before posting

包含的文件(2)

  • SKILL.md9.9 KB
  • templates/review-comment.md2.2 KB

SKILL.md(原文)

安装前可以查看交给 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 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

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

评价

还没有评价。欢迎分享你的使用感受。

评论

无需登录即可发表。欢迎分享使用感受、提问,或说明在哪些环境下无法运行。

还没有评论。来写第一条吧。

提交后会立即公开。请勿填写邮箱、电话等个人信息。URL 最多 2 个。

0 / 1000 字

此表单受 reCAPTCHA 保护,适用 Google 的隐私权政策和服务条款。

同一仓库的技能

Simplify Rust code in RTK by replacing verbose loops, unnecessary copies, and excessive abstractions with common Rust patterns. Preserve behavior and project requirements, including error context, fallback handling, exit codes, and existing test modules.

中文简介正在准备中。当前显示英语简介。

  • Simplifying verbose loops and string construction
  • Removing unnecessary string copies
  • Reducing nested conditional and error handling code
rtk-ai/rtk8.4万2026年10月19日 更新

Choose Rust design patterns for RTK modules that process command output. Use concrete examples to structure configuration, prevent type mixups, manage parser states, and select abstractions suited to the task without adding unnecessary architectural complexity.

中文简介正在准备中。当前显示英语简介。

  • Planning the structure of a new command output filter
  • Preventing mixups between values with the same underlying type
  • Organizing configuration with many optional fields
rtk-ai/rtk8.4万2026年10月19日 更新

Organize open GitHub issues by category, risk, linked pull requests, duplicate candidates, and inactivity. Optionally analyze selected issues in depth, draft responses, and apply approved comments, labels, or closures to keep the backlog actionable.

中文简介正在准备中。当前显示英语简介。

  • Sorting a growing backlog of open issues
  • Checking whether suspected duplicate issues are truly duplicates
  • Prioritizing security risks and breaking changes
rtk-ai/rtk8.4万2026年10月19日 更新

rtk-tdd

免费

Guide Rust development through test-driven development: write a failing test, implement enough code to pass, then refactor. Includes practical test patterns and final checks for formatting, static analysis, and test results.

中文简介正在准备中。当前显示英语简介。

  • Adding Rust features with tests first
  • Reproducing bugs with failing tests before fixing them
  • Testing invalid inputs and error paths
rtk-ai/rtk8.4万2026年10月19日 更新

Review GitHub issues and pull requests together to find duplicate work, security findings without fixes, and critical bugs without linked changes. Produce action tables and a dated report to support backlog reviews and sprint planning.

中文简介正在准备中。当前显示英语简介。

  • Reviewing issues and pull requests before a sprint
  • Finding pull requests that duplicate the same work
  • Identifying security findings without proposed fixes
rtk-ai/rtk8.4万2026年10月19日 更新

tdd-rust

免费

Develop Rust filters for RTK through tests written before implementation. Use real command output as test inputs, check output snapshots and unexpected inputs, verify a minimum reduction target, and complete formatting, linting, and test checks before finishing.

中文简介正在准备中。当前显示英语简介。

  • Adding a new RTK command filter
  • Checking filtered output against saved snapshots
  • Testing empty, malformed, or ANSI-colored input
rtk-ai/rtk8.4万2026年10月19日 更新

查看 rtk-ai 的全部技能

报告此技能的问题