PR Triage
4-phase workflow for maintainers: automated audit of all open PRs, opt-in deep review via parallel agents, validated comment posting, and optional worktree setup for local review.
When to Use This Skill
| Skill | Usage | Output | |-------|-------|--------| | `/pr-triage` | Sort, review, and comment on a PR backlog | Triage table + reviews + posted comments | | `/review-pr` | Review a single PR in depth | Inline PR review |
**Triggers**:
- Manually: `/pr-triage` or `/pr-triage all` or `/pr-triage 42 57`
- Proactively: when >5 PRs open without review, or stale PR >14 days detected
---
Language
- Check the argument passed to the skill
- If `en` or `english` → tables and summary in English
- If `fr`, `french`, or no argument → French (default)
- Note: GitHub comments (Phase 3) are ALWAYS in English (international audience)
---
Configuration
Thresholds used throughout the workflow. Edit to match your project:
| Parameter | Default | Description | |-----------|---------|-------------| | `staleness_days` | 14 | Days without activity before flagging as stale | | `overlap_threshold` | 50% | Shared files % to flag as overlapping | | `cluster_min_prs` | 3 | Author PR count to trigger cluster suggestion | | `xl_cutoff_additions` | 1000 | Additions above which a PR is classified XL | | `xl_cutoff_files` | 10 | Changed files above which a PR is "too large" |
---
Preconditions
git rev-parse --is-inside-work-tree
gh auth statusIf either fails, stop and explain what is missing.
---
Phase 1 — Audit (always executed)
Data Gathering (parallel commands)
gh repo view --json nameWithOwner -q .nameWithOwner
gh pr list --state open --limit 50 \
--json number,title,author,createdAt,updatedAt,additions,deletions,changedFiles,isDraft,mergeable,reviewDecision,statusCheckRollup,body
gh api "repos/{owner}/{repo}/collaborators" --jq '.[].login'**Collaborators fallback**: if `gh api .../collaborators` returns 403/404:
gh pr list --state merged --limit 10 --json author --jq '.[].author.login' | sort -uIf still ambiguous, ask via `AskUserQuestion`.
For each PR, fetch reviews and changed files:
gh api "repos/{owner}/{repo}/pulls/{num}/reviews" \
--jq '[.[] | .user.login + ":" + .state] | join(", ")'
gh pr view {num} --json files --jq '[.files[].path] | join(",")'**Notes**: Fetching files requires 1 API call per PR — for 20+ PRs, prioritize overlap candidates. The `author` field is an object; always extract `.author.login`.
Analysis
**Size classification**: | Label | Additions | |-------|-----------| | XS | < 50 | | S | 50–200 | | M | 200–500 | | L | 500–1000 | | XL | > 1000 |
Size format: `+{additions}/-{deletions}, {files} files ({label})`
**Detections**:
- **Overlaps**: compare file lists across PRs — if >50% files in common → cross-reference
- **Clusters**: author with 3+ open PRs → suggest review order (smallest first)
- **Staleness**: no activity for >14 days → flag "stale"
- **CI status**: via `statusCheckRollup` → `clean` / `unstable` / `dirty`
- **Reviews**: approved / changes_requested / none
**PR ↔ Issue linking**:
- Scan each PR `body` for `fixes #N`, `closes #N`, `resolves #N` (case-insensitive)
- If found, display in the table: `Fixes #42` in the Action/Status column
**Categorization**:
_Internal PRs_: author in collaborators list
_External — Ready_: additions ≤ 1000 AND files ≤ 10 AND `mergeable` ≠ `CONFLICTING` AND CI clean/unstable
_External — Problematic_: any of:
- additions > 1000 OR
<!-- truncated -->