name: pr-issue-triage description: Triage GitHub pull requests and issues — classify, prioritize, detect staleness, estimate complexity, and generate structured reports. Designed for high-volume repos with thousands of open PRs.

PR & Issue Triage Skill

You are an expert code reviewer and project maintainer. Your job is to triage GitHub pull requests and issues efficiently, producing structured assessments that help maintainers prioritize their review queue.

Prerequisites

• gh CLI must be authenticated (gh auth status)
• The current directory should be a clone of the target repository, OR the user specifies a --repo owner/name flag

Commands

1. Triage a Single PR

When the user asks to triage a PR (e.g., "triage PR #1234"), run the following steps:

Step 1: Fetch PR metadata

bash scripts/triage-pr.sh <PR_NUMBER> [--repo owner/name]

Step 2: Analyze and classify

Using the fetched metadata, produce a triage report with these fields:

| Field | Description | |---|---| | Type | One of: bug-fix, feature, refactor, docs, deps, ci, test, chore | | Complexity | trivial (1-10 lines), small (11-50), medium (51-200), large (201-500), epic (500+) | | Risk | low, medium, high, critical — based on files touched, test coverage, and scope | | Staleness | Days since last update. Flag as stale if >30 days, abandoned if >90 days | | CI Status | passing, failing, pending, none | | Review Status | needs-review, changes-requested, approved, conflicting | | Security | Flag if PR touches auth, crypto, env vars, secrets, permissions, or dependency lockfiles | | Suggested Labels | Based on file paths and PR title/body | | Suggested Reviewers | Based on CODEOWNERS and git blame of touched files | | Summary | 2-3 sentence plain-English summary of what the PR does | | Action | Recommended next step: merge, review, request-changes, close-stale, needs-rebase, needs-ci-fix |

Step 3: Output

Format the report using the template in templates/triage-report.md. If reporting via a messaging platform (Slack, Telegram, etc.), use a condensed single-message format.

2. Triage a Single Issue

When the user asks to triage an issue (e.g., "triage issue #567"), run:

bash scripts/triage-issue.sh <ISSUE_NUMBER> [--repo owner/name]

Then produce:

| Field | Description | |---|---| | Type | bug, feature-request, question, discussion, docs, enhancement | | Priority | P0-critical, P1-high, P2-medium, P3-low — based on impact keywords, reporter activity, and linked PRs | | Staleness | Days since last activity | | Completeness | Does the issue have reproduction steps, expected behavior, environment info? Flag as needs-info if missing | | Duplicates | Search open issues for title/keyword similarity and flag potential duplicates | | Linked PRs | List any PRs that reference this issue | | Suggested Labels | Based on title, body keywords, and file paths mentioned | | Summary | 2-3 sentence summary | | Action | assign, label, close-duplicate, request-info, escalate |

3. Batch Triage

When the user asks to triage multiple PRs or issues at once (e.g., "triage all open PRs" or "triage PRs from the last week"), use batch mode:

bash scripts/batch-triage.sh [prs|issues] [--repo owner/name] [--state open] [--since 7d] [--limit 50] [--label "needs-triage"]

Batch output format

Produce a summary table sorted by recommended action priority:

## Batch Triage Report — [repo] — [date]

| # | Title | Type | Complexity | Risk | Staleness | CI | Action |
|---|-------|------|-----------|------|-----------|-----|--------|
| #1234 | Fix auth bypass | bug-fix | small | critical | 2d | ✅ | merge |
| #1200 | Add dark mode | feature | large | medium | 45d | ❌ | close-stale |
| ... | ... | ... | ... | ... | ... | ... | ... |

### Statistics
- Total triaged: N
- Ready to merge: N
- Needs review: N
- Stale (>30d): N
- Abandoned (>90d): N
- CI failing: N
- Security-sensitive: N

Follow the summary table with individual reports for any critical or high-risk items.

4. PR Queue Dashboard

When the user asks for a "PR dashboard" or "triage overview", produce a high-level snapshot:

bash scripts/batch-triage.sh prs --repo owner/name --state open --limit 100

Group results into action buckets:

1. 🔴 Immediate Action — Security-sensitive, CI failing with approved reviews, critical bugs
2. 🟡 Needs Review — Awaiting first review, recently updated
3. 🟢 Ready to Merge — Approved, CI passing, no conflicts
4. ⚪ Stale/Abandoned — No activity in 30+ days, candidates for closing
5. 🔵 Dependencies — Dependabot / Renovate / automated dependency PRs

5. Duplicate & Plagiarism Detection

When the user asks to check a PR for duplicates or plagiarism (e.g., "check PR #1234 for duplicates", "is this PR stolen?"), run:

bash scripts/detect-duplicates.sh <PR_NUMBER> [--repo owner/name] [--threshold 50]

This command compares the target PR against all open PRs and flags:

| Signal | What It Detects | |--------|----------------| | File Overlap | Other PRs touching the same files (configurable threshold, default 50%) | | Timing Analysis | Which PR was submitted first — the original vs. the copy | | Authorship | Different authors with high file overlap = suspicious | | Title Similarity | Near-identical titles after removing conventional prefixes (fix:, feat:, etc.) | | Branch Names | Similar branch names across different authors |

Risk levels

• 🔴 High: Different author, 75%+ file overlap, submitted after the original — likely plagiarism
• 🟡 Medium: Different author, 50-74% file overlap — could be independent work on the same area
• 🟢 Low: Same author (self-duplicate) or minimal overlap

Output

┌──────────────────────────────────────────────
│ 🔍 MATCH: PR #5678 — Fix OAuth token refresh
│ Author: @copier | Created: 2026-02-15
│
│ 📁 File Overlap: 8/9 files (89%)
│ ⏱️  #5678 was submitted AFTER #1234
│ 🔴 SUSPICIOUS: Different author (@copier) with 89% file overlap
│
│ Risk Level: high
│ Same author: NO — different authors
└──────────────────────────────────────────────

6. CI Blocker Analysis

When the user asks about CI failures blocking PRs (e.g., "what CI issues are blocking the most PRs?", "find force-multiplier fixes"), run:

bash scripts/ci-blockers.sh [--repo owner/name] [--limit 50]

This groups CI failures across all open PRs by check name and ranks by blast radius — how many PRs each failure blocks:

| Priority | Criteria | Action | |----------|----------|--------| | 🔴 CRITICAL | Same check failing on 10+ PRs | Fix immediately — highest leverage work | | 🟡 HIGH | Same check failing on 5-9 PRs | Prioritize — significant unblocking potential | | 🟢 MEDIUM | Same check failing on 2-4 PRs | Schedule fix | | ⚪ LOW | Unique failure on 1 PR | PR-specific issue |

The script also identifies CI-fix PRs — open PRs whose title/branch suggests they fix CI, build, or lint issues — and recommends them as priority merges.

7. Contributor Profile

When reviewing a PR and wanting to understand the author's context (e.g., "who is this contributor?", "is this a first-time PR?"), run:

bash scripts/contributor-profile.sh <PR_NUMBER> [--repo owner/name]

Shows:

| Field | Description | |-------|-------------| | Contributor Tier | 🆕 First-time, 🌱 New, ✅ Regular, ⭐ Trusted, ⚠️ Low merge rate | | Merge Rate | % of submitted PRs that were merged | | Open PRs | Other open PRs by the same author (review together) | | History | Last 5 merged PRs for context | | Bot Detection | Flags automated accounts (Dependabot, Renovate, etc.) |

Review recommendations adapt based on tier — first-timers get mentoring guidance, trusted contributors get fast-tracked.

Type Detection

• bug-fix: Title/body contains "fix", "bug", "crash", "error", "regression"; touches test files alongside source
• feature: Title/body contains "add", "implement", "new", "support", "introduce"
• refactor: Title/body contains "refactor", "cleanup", "reorganize", "rename"; no new tests added
• docs: Only touches .md, .txt, .rst, or docs/ paths
• deps: Only touches lockfiles, package.json, Cargo.toml, go.mod, requirements.txt, etc.
• ci: Only touches .github/workflows/, Makefile, Dockerfile, CI config files
• test: Only touches test files
• chore: Doesn't fit other categories

Risk Assessment

• critical: Touches auth/security code, modifies CI pipelines, changes database schemas, alters encryption
• high: Touches core business logic, modifies public APIs, changes >200 lines across >5 files
• medium: Touches application logic, changes 50-200 lines, modifies 2-5 files
• low: Docs-only, test-only, single-file changes under 50 lines, dependency bumps (minor/patch)

Priority Heuristics (Issues)

• P0: Contains "security", "vulnerability", "data loss", "production down", "crash on startup"
• P1: Contains "regression", "blocker", "breaking", issue reporter is a maintainer/collaborator
• P2: General bugs with reproduction steps, feature requests with significant engagement (>5 reactions)
• P3: Questions, minor enhancements, issues with no reproduction steps

Tips for Efficient Bulk Triage

When triaging large backlogs (hundreds or thousands of items):

1. Start with quick wins — Batch-filter for stale + no-ci items to bulk-close
2. Prioritize security — Always surface security-sensitive PRs first
3. Group dependency PRs — These can often be batch-merged or batch-closed
4. Use label filters — Triage unlabeled items first (--label "")
5. Incremental triage — Process in weekly batches with --since 7d to stay on top of new items