Summary

4-phase PR backlog management with audit, deep code review, validated comments, and optional worktree setup. Use when triaging pull requests, catching up on pending code reviews, or managing a backlog of open PRs. Args: 'all' to review all, PR numbers to focus (e.g. '42 57'), 'en'/'fr' for language, no arg = audit only.

SKILL.md

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 status

If 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 -u

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

View raw file