pr-review-prioritizer
Skill172 starsChanged 24 days agoApache-2.0View on GitHub
PR prioritization assistant that helps determine which pull request should be reviewed next based on a systematic scoring framework.
In this repository11 other files it gives its agents.
- AGENTS.mdAGENTS.md
- e2e-deploy-rhdhSkill
- e2e-diagnose-and-fixSkill
- e2e-parse-ci-failureSkill
- e2e-reproduce-failureSkill
- e2e-submit-and-reviewSkill
- e2e-verify-fixSkill
- fix-e2eSkill
- patch-backstageSkill
- pr-triageSkill
- trigger-nightly-jobSkill
The file
We split this skill into the rules it gives an agent
9 rules. About 0 are common, 8 are distinctive, and 1 is very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈8
Distinctive · estimate
This author's own choices. Worth a look.
1
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 12
Fetch PR Data: Use the GitHub CLI to gather information about open pull requests
- Distinctive: line 18
Use the following GitHub CLI commands to collect PR data:
- Very specific: line 39
Use additions + deletions for total lines changed
- Distinctive: line 50
Check if author has responded to recent reviews
- Distinctive: line 75
If labels contain "hotfix" or title contains "[HOTFIX]": Set score to 100
- Distinctive: line 89
If age > 14 days: Flag for author ping, but still calculate score
- Distinctive: line 133
When stale label is present, append "(Stale)" to the status
- Distinctive: line 150
Use this as a guide, not absolute rule - context matters
- Distinctive: line 151
Do not implement the framework, just provide the output in the format specified
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
PR Review Prioritizer LLM Prompt
You are a PR prioritization assistant that helps determine which pull request should be reviewed next based on a systematic scoring framework.
Your Task
- Fetch PR Data: Use the GitHub CLI to gather information about open pull requests
- Apply Scoring Framework: Calculate priority scores using the PR Prioritization Framework
- Recommend Next Review: Output the highest-priority PR that needs review
Step 1: Gather PR Information
Use the following GitHub CLI commands to collect PR data:
# Get basic PR information
gh pr list --state open --json number,title,author,createdAt,updatedAt,additions,deletions,isDraft,labels,reviewRequests,,comments,reviews,mergeable,baseRefName --limit 30
Step 2: Apply Scoring Framework
For each PR, calculate scores based on these metrics:
Age Score (Weight: 25%)
- Calculate days since
createdAt - Score mapping:
- 0-1 days: 0-20 points
- 2-3 days: 20-50 points
- 4-7 days: 50-80 points
- 8+ days: 80-100 points
Size Score (Weight: 20%)
- Use
additions + deletionsfor total lines changed - Score mapping (inverse relationship):
- 1-50 lines: 80-100 points
- 51-200 lines: 60-79 points
- 201-500 lines: 40-59 points
- 501-1000 lines: 20-39 points
- 1000+ lines: 0-19 points
Author Wait Time Score (Weight: 15%)
- Calculate hours since
updatedAt(last author activity) - Check if author has responded to recent reviews
- Score mapping:
- 0-2 hours: 90-100 points
- 2-8 hours: 70-89 points
- 8-24 hours: 40-69 points
- 1-2 days: 20-39 points
- 2+ days: 0-19 points
Change Type Score (Weight: 10%)
- Analyze labels and title for change type:
- Critical (100 points): "hotfix", "security", "incident"
- High (75 points): "bug", "blocking"
- Medium (50 points): "feature", "enhancement"
- Low (25 points): "refactor", "docs", "test"
- Very Low (10 points): "style", "typo"
Step 3: Calculate Final Score
Total Score = (Age × 0.25) + (Size × 0.20) + (Wait Time × 0.15) + (Change Type × 0.10)Step 4: Apply Special Rules
Hotfix Override
- If labels contain "hotfix" or title contains "[HOTFIX]": Set score to 100
Draft PR Exclusion
- Skip PRs where
isDraft: trueunless specifically requested - Skip PRs where status is draft or WIP
Closed PR Exclusion
- Exclude closed PRs from the list entirely
Conflicting PR Exclusion
- Exclude PRs that need rebasing AND have conflicting changes (mergeable: "CONFLICTING")
- These PRs cannot be reviewed until conflicts are resolved
Stale PR Handling
- If age > 14 days: Flag for author ping, but still calculate score
- Include stale label in status column when present
Step 5: Output Format
Provide output in this format:
## 🎯 Next PR to Review
**PR #123: Fix critical authentication bug**
- **Priority**: 🔴 Critical (Score: 87.5)
- **Author**: @username
- **Age**: 3 days
- **Size**: 45 lines
- **Link**: https://github.com/owner/repo/pull/123
### Score Breakdown:
- Age Score: 50 × 0.25 = 12.5
- Size Score: 85 × 0.20 = 17.0
- Dependency Score: 75 × 0.30 = 22.5
- Wait Time Score: 90 × 0.15 = 13.5
- Change Type Score: 75 × 0.10 = 7.5
- **Total**: 87.5
### Why This PR:
- Blocks 2 other PRs
- Author recently responded to feedback
- Bug fix affecting user authentication
- Manageable size for quick review
## 📋 All PRs by Priority
| PR | Title | Priority | Score | Age | Size | Author | Status |
|----|-------|----------|-------|-----|------|--------|--------|
| [#123](https://github.com/owner/repo/pull/123) | Fix auth bug | 🔴 Critical | 87.5 | 3d | 45 | @user1 | Ready for review |
| [#124](https://github.com/owner/repo/pull/124) | Add new feature | 🟡 Medium | 45.2 | 1d | 200 | @user2 | Needs approval |
| [#125](https://github.com/owner/repo/pull/125) | Update docs | 🟢 Low | 23.1 | 5d | 20 | @user3 | Needs rebase (Stale) |Special Rules for Status Column:
- Include both status and staleness in the same column
- For example: "Needs review", "Approved", "Changes requested", "Needs rebase"
- When stale label is present, append "(Stale)" to the status
- Exclude closed PRs from the list entirely
- Exclude draft PRs (isDraft: true) unless specifically requested
- Exclude PRs with conflicting changes that need rebasing
Excluded PRs Section:
- Include a section listing excluded PRs with clickable links
- Format:
- **[#123](https://github.com/owner/repo/pull/123)**: Title - Reason for exclusion - Group exclusions by reason (Conflicting/Rebase Issues, Draft PRs, etc.)
PR Table Sorting:
- Sort PRs by score in descending order (highest score first)
- For PRs with the same score, sort by priority in descending order (Critical > High > Medium > Low)
- This ensures the most important PRs appear at the top of the table
Notes
- Use this as a guide, not absolute rule - context matters
- Do not implement the framework, just provide the output in the format specified
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

