Skip to main content

pr-triage

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.

Source facts

Repository
FlorianBruniaux/claude-code-ultimate-guide
Last source activity
September 30, 2026 at 13:41
Detected SKILL.md language
English
Stars
6,360
Forks
826

Install options

The review-first prompt is selected by default. You can switch to a direct command or download a local copy.

Review the source files

Read SKILL.md and any companion files shown by SkillsMP before deciding whether to install.

File Explorer
2 files

Showing SKILL.md

SKILL.md
Source instructions · Read-only preview
name
pr-triage
description
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.
allowed-tools
Bash Read
effort
medium
# 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 ```bash 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) ```bash 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: ```bash 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: ```bash 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 files > 10 - OR `mergeable` == `CONFLICTING` (merge conflict) - OR CI dirty (statusCheckRollup contains failures) - OR overlap with another open PR (>50% shared files) ### Output: Triage table ``` ## Open PRs ({count}) ### Internal PRs | PR | Title | Size | CI | Status | | -- | ----- | ---- | -- | ------ | ### External: Ready for Review | PR | Author | Title | Size | CI | Reviews | Action | | -- | ------ | ----- | ---- | -- | ------- | ------ | ### External: Problematic | PR | Author | Title | Size | Problem | Recommended Action | | -- | ------ | ----- | ---- | ------- | ------------------ | ### Summary - Quick wins: {XS/S PRs ready to merge} - Risks: {overlaps, XL sizes, CI dirty} - Clusters: {authors with 3+ PRs} - Stale: {PRs with no activity >14d} - Overlaps: {PRs touching the same files} ``` 0 PRs → display `No open PRs.` and stop. ### Navigation post-phase 1 After displaying the triage table, ask via `AskUserQuestion`: ``` question: "What would you like to do next?" header: "Next Step" options: - label: "Phase 2: Deep review" description: "Analyze selected PRs with code-reviewer agents and generate comment drafts" - label: "Phase 4: Create worktrees" description: "Set up local worktrees for hands-on review (skips comment generation)" - label: "Done" description: "End the workflow here" ``` Note: Phase 3 (posting comments) is NOT offered here, as it requires the drafts generated in Phase 2. If the user picks "Phase 4", Phase 2 → Phase 3 remains accessible afterward. ### Automatic copy After displaying the triage table, copy to clipboard using platform-appropriate command: ```bash UNAME=$(uname -s) if [ "$UNAME" = "Darwin" ]; then pbcopy <<'EOF' {full triage table} EOF elif command -v xclip &>/dev/null; then echo "{full triage table}" | xclip -selection clipboard elif command -v wl-copy &>/dev/null; then echo "{full triage table}" | wl-copy elif command -v clip.exe &>/dev/null; then echo "{full triage table}" | clip.exe fi ``` Confirm: `Triage table copied to clipboard.` (EN) / `Tableau copié dans le presse-papier.` (FR) --- ## Phase 2: Deep Review (opt-in) ### PR selection **If argument passed**: - `"all"` → all external PRs - Numbers (`"42 57"`) → only those PRs - No argument → propose via `AskUserQuestion` **If no argument**, display: ``` question: "Which PRs do you want to review in depth?" header: "Deep Review" multiSelect: true options: - label: "All external" description: "Review {N} external PRs with parallel code-reviewer agents" - label: "Problematic only" description: "Focus on {M} risky PRs (CI dirty, too large, overlaps)" - label: "Ready only" description: "Review {K} PRs ready to merge" - label: "Skip" description: "Stop here, audit only" ``` **Draft PR behavior**: - Draft PRs are EXCLUDED from "All external" and "Ready only" - Draft PRs are INCLUDED in "Problematic only" (they need attention) - To review a draft: type its number explicitly (e.g. `42`) If "Skip" → end workflow. ### Executing reviews For each selected PR, launch a `code-reviewer` agent via **Task tool in parallel**: ``` 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 and architecture expertise. Use the project-specific checklist from the SKILL.md Configuration section if available. Return structured review: ### Critical Issues ### Important Issues ### Suggestions ### What's Good Be specific: quote file:line, explain the issue, suggest the fix. ``` **Fallback if parallel agents unavailable**: run reviews sequentially, one PR at a time. Notify user: `Running sequential review (parallel agents not available).` Fetch diff via: ```bash gh pr diff {num} gh pr view {num} --json body,title,author -q '{body: .body, title: .title, author: .author.login}' ``` Aggregate all reports. Display a summary after all reviews complete. --- ## Phase 3: Comments (mandatory validation) ### Draft generation For each reviewed PR, generate a GitHub comment using the template `templates/review-comment.md`. **Rules**: - Language: **English** (international audience) - Tone: professional, constructive, factual - Always include at least 1 positive point - Quote code lines when relevant (format `file:42`) ### Display and validation **Display ALL drafted comments** in format: ``` --- ### Draft: PR #{num}: {title} {full comment} --- ``` Then request validation via `AskUserQuestion`: ``` question: "These comments are ready. Which ones do you want to post?" header: "Post Comments" multiSelect: true options: - label: "All ({N} comments)" description: "Post on all reviewed PRs" - label: "PR #{x}: {title_truncated}" description: "Post only on this PR" - label: "None" description: "Cancel, post nothing" ``` (Generate one option per PR + "All" + "None") ### Posting For each validated comment: ```bash gh pr comment {num} --body-file - <<'REVIEW_EOF' {comment} REVIEW_EOF ``` Confirm each post: `Comment posted on PR #{num}: {title}` If "None" → `No comments posted. Workflow complete.` --- ## Project-specific checklist Add your stack's checklist to the agent prompt in Phase 2. Examples by stack: **Node.js / TypeScript**: - No `any` type without explicit justification - `async/await` error handling (try/catch or `.catch()`) - No unhandled promise rejections - Input validation at API boundaries **Python**: - Type hints on all public functions - Exception specificity (no bare `except:`) - Resource cleanup (`with` statements, context managers) - No mutable default arguments **Rust**: - `Result<T, E>` with `.context()` for error chain (no `.unwrap()` in production code) - No `clone()` on hot paths without justification - `lazy_static!` or `once_cell` for static regex - Lifetime annotations where ownership is non-obvious **Go**: - Explicit error handling (no `_` discard without comment) - `defer` for resource cleanup - Context propagation in concurrent code - No goroutine leaks **Generic** (stack-agnostic): - No secrets or hardcoded credentials - New public functions have tests - Breaking changes documented in PR body - Dependencies added have clear justification --- --- ## Phase 4: Worktree Setup (opt-in) Creates local git worktrees for each selected PR so you can run, test, or review code without switching branches. **Never triggered automatically.** Only via Phase 1 navigation or explicit user request. ### Step 4.1: Cache check + PR list **Cache check**: before using data from Phase 1, verify it is less than 30 minutes old: ```bash CACHE_FILE="/tmp/pr-triage-prs.json" CACHE_AGE=$(( $(date +%s) - $(stat -f %m "$CACHE_FILE" 2>/dev/null || echo 0) )) if [ "$CACHE_AGE" -gt 1800 ]; then echo "STALE_CACHE" fi ``` If `STALE_CACHE` → re-run the Phase 1 data gathering before continuing. **Filter**: exclude Draft PRs and bot PRs (Dependabot, renovate, etc.): ```bash python3 -c " import json
View on GitHub
This SKILL.md is very large, so SkillsMP previews the first section here. View on GitHub