Merge Check
Predicts whether a GitHub PR will get merged by analyzing it against a comprehensive rejection vector taxonomy. Not a generic code quality tool — this answers: "Will this PR get merged by the maintainer?"
Quick Start
- Run the data gathering script:
bash skills/merge-check/scripts/merge-check.sh owner/repo#123
# or
bash skills/merge-check/scripts/merge-check.sh https://github.com/owner/repo/pull/123
- Parse the JSON output
- Analyze against the dimensions below
- Produce the mergeability report
Analysis Dimensions
After gathering data, analyze across ALL of these dimensions. Load skills/merge-check/references/rejection-taxonomy.md for the detailed rejection vector framework.
1. Technical Signals (Automated Gates)
- CI status: Are all checks passing? Any failed or pending?
- Build status: Does it compile/build?
- Coverage: Any coverage regression indicated?
2. PR Hygiene
- Size (most predictive single factor):
- 🟢 <400 LOC changed — ideal, easy to review
- 🟡 400–1000 LOC — risky, reviewer fatigue
- 🔴 >1000 LOC — danger zone, likely to stall or get rejected
- File spread: Concentrated in one area or scattered across directories?
- Single concern: Does it do one thing, or is it a kitchen-sink PR?
- Title & description: Clear, descriptive? Or vague/empty?
- Linked issue: Does it reference an issue? (Signals intentionality)
- Commit hygiene: Clean messages? Reasonable count? Squash-ready?
3. Architectural Fit
- Pattern consistency: Does it follow repo conventions? (language, directory structure, naming)
- Dependencies: New dependencies introduced? (High friction signal)
- Scope creep: Does it touch things outside its stated purpose?
- File types: Consistent with repo's tech stack?
4. Review Status
- Approvals: Any already? How many required?
- Changes requested: Outstanding and unaddressed? (Strong rejection signal)
- Reviewer assignment: Are required reviewers assigned?
- Review comment sentiment: Positive, neutral, or adversarial?
- CODEOWNERS: Does the PR touch files with code owners? Are they reviewing?
5. Process Compliance
- Draft status: Draft PRs won't merge
- Blocking labels: WIP, do-not-merge, needs-work, etc.
- PR template: Was it followed? (Empty template = red flag)
- CLA/DCO: If repo requires it, is it signed?
6. Social/Meta Signals
- Author merge history: What % of this author's recent PRs were merged in this repo?
- Staleness: How long has it been open? (>2 weeks = concern, >30 days = likely abandoned)
- Activity level: Recent comments/updates, or radio silence?
- First-time contributor: Higher rejection rate for newcomers
Output Format
Produce a structured report:
Mergeability Score
- 🟢 High (>80% likely to merge) — No blockers, reviews positive, CI green
- 🟡 Medium (40–80%) — Some concerns but addressable
- 🔴 Low (<40%) — Significant blockers present
Report Sections
- Mergeability Score: 🟢/🟡/🔴 with percentage estimate
- Risk Factors: Bullet list of specific concerns, ordered by severity
- Strengths: What's working in the PR's favor
- Recommendations: Actionable steps to improve mergeability (if not already 🟢)
- Verdict: One-sentence summary
Example Output
## PR Mergeability Report: owner/repo#123
**Score: 🟡 Medium (~55%)**
### Risk Factors
- ⚠️ 847 lines changed — approaching reviewer fatigue threshold
- ⚠️ Changes requested by @maintainer not yet addressed
- ⚠️ Touches 12 files across 6 directories — scattered scope
- ℹ️ No linked issue
### Strengths
- ✅ All 14 CI checks passing
- ✅ Clear title and detailed description
- ✅ Author has 73% merge rate in this repo (8/11 recent PRs)
- ✅ Active discussion — last update 2 hours ago
### Recommendations
1. Address @maintainer's review comments before requesting re-review
2. Consider splitting into smaller PRs (config changes vs logic changes)
3. Link the relevant issue for traceability
### Verdict
Solid PR with passing CI and an active author, but stalled on unaddressed review feedback — resolving those comments is the critical path to merge.
Script Reference
The script (scripts/merge-check.sh) gathers all data via gh CLI and outputs a single JSON object with these keys:
| Key |
Contents |
pr |
Full PR metadata (title, body, author, state, draft, labels, reviewers) |
files |
List of changed files with patch stats |
diff_stats |
Total additions, deletions, changed files count |
checks |
CI/check run results for the head commit |
reviews |
All reviews (approved, changes_requested, commented) |
review_comments |
Inline review comments |
issue_comments |
PR conversation comments |
commits |
Commit list with messages |
repo |
Repository metadata (language, size, defaults) |
author_history |
Author's recent closed PRs and merge rate |
has_codeowners |
Boolean |
has_contributing |
Boolean |
Error Handling
The script outputs "error" fields when individual API calls fail (e.g., rate limits, 404s). Analyze what's available and note any missing data in the report.
1---2name: merge-check3description: Analyze a GitHub pull request for mergeability — predict whether it will get merged based on technical, architectural, process, social, and compliance factors. Use when asked to review a PR, check if a PR will be merged, assess PR quality, or predict PR acceptance. Works with any GitHub PR via `owner/repo#number` or URL.4---56# Merge Check78Predicts whether a GitHub PR will get merged by analyzing it against a comprehensive rejection vector taxonomy. Not a generic code quality tool — this answers: **"Will this PR get merged by the maintainer?"**910## Quick Start11121. Run the data gathering script:13 ```bash14 bash skills/merge-check/scripts/merge-check.sh owner/repo#12315 # or16 bash skills/merge-check/scripts/merge-check.sh https://github.com/owner/repo/pull/12317 ```182. Parse the JSON output193. Analyze against the dimensions below204. Produce the mergeability report2122## Analysis Dimensions2324After gathering data, analyze across ALL of these dimensions. Load `skills/merge-check/references/rejection-taxonomy.md` for the detailed rejection vector framework.2526### 1. Technical Signals (Automated Gates)27- **CI status**: Are all checks passing? Any failed or pending?28- **Build status**: Does it compile/build?29- **Coverage**: Any coverage regression indicated?3031### 2. PR Hygiene32- **Size** (most predictive single factor):33 - 🟢 <400 LOC changed — ideal, easy to review34 - 🟡 400–1000 LOC — risky, reviewer fatigue35 - 🔴 >1000 LOC — danger zone, likely to stall or get rejected36- **File spread**: Concentrated in one area or scattered across directories?37- **Single concern**: Does it do one thing, or is it a kitchen-sink PR?38- **Title & description**: Clear, descriptive? Or vague/empty?39- **Linked issue**: Does it reference an issue? (Signals intentionality)40- **Commit hygiene**: Clean messages? Reasonable count? Squash-ready?4142### 3. Architectural Fit43- **Pattern consistency**: Does it follow repo conventions? (language, directory structure, naming)44- **Dependencies**: New dependencies introduced? (High friction signal)45- **Scope creep**: Does it touch things outside its stated purpose?46- **File types**: Consistent with repo's tech stack?4748### 4. Review Status49- **Approvals**: Any already? How many required?50- **Changes requested**: Outstanding and unaddressed? (Strong rejection signal)51- **Reviewer assignment**: Are required reviewers assigned?52- **Review comment sentiment**: Positive, neutral, or adversarial?53- **CODEOWNERS**: Does the PR touch files with code owners? Are they reviewing?5455### 5. Process Compliance56- **Draft status**: Draft PRs won't merge57- **Blocking labels**: WIP, do-not-merge, needs-work, etc.58- **PR template**: Was it followed? (Empty template = red flag)59- **CLA/DCO**: If repo requires it, is it signed?6061### 6. Social/Meta Signals62- **Author merge history**: What % of this author's recent PRs were merged in this repo?63- **Staleness**: How long has it been open? (>2 weeks = concern, >30 days = likely abandoned)64- **Activity level**: Recent comments/updates, or radio silence?65- **First-time contributor**: Higher rejection rate for newcomers6667## Output Format6869Produce a structured report:7071### Mergeability Score72- 🟢 **High** (>80% likely to merge) — No blockers, reviews positive, CI green73- 🟡 **Medium** (40–80%) — Some concerns but addressable74- 🔴 **Low** (<40%) — Significant blockers present7576### Report Sections771. **Mergeability Score**: 🟢/🟡/🔴 with percentage estimate782. **Risk Factors**: Bullet list of specific concerns, ordered by severity793. **Strengths**: What's working in the PR's favor804. **Recommendations**: Actionable steps to improve mergeability (if not already 🟢)815. **Verdict**: One-sentence summary8283### Example Output84```85## PR Mergeability Report: owner/repo#1238687**Score: 🟡 Medium (~55%)**8889### Risk Factors90- ⚠️ 847 lines changed — approaching reviewer fatigue threshold91- ⚠️ Changes requested by @maintainer not yet addressed92- ⚠️ Touches 12 files across 6 directories — scattered scope93- ℹ️ No linked issue9495### Strengths96- ✅ All 14 CI checks passing97- ✅ Clear title and detailed description98- ✅ Author has 73% merge rate in this repo (8/11 recent PRs)99- ✅ Active discussion — last update 2 hours ago100101### Recommendations1021. Address @maintainer's review comments before requesting re-review1032. Consider splitting into smaller PRs (config changes vs logic changes)1043. Link the relevant issue for traceability105106### Verdict107Solid PR with passing CI and an active author, but stalled on unaddressed review feedback — resolving those comments is the critical path to merge.108```109110## Script Reference111112The script (`scripts/merge-check.sh`) gathers all data via `gh` CLI and outputs a single JSON object with these keys:113114| Key | Contents |115|-----|----------|116| `pr` | Full PR metadata (title, body, author, state, draft, labels, reviewers) |117| `files` | List of changed files with patch stats |118| `diff_stats` | Total additions, deletions, changed files count |119| `checks` | CI/check run results for the head commit |120| `reviews` | All reviews (approved, changes_requested, commented) |121| `review_comments` | Inline review comments |122| `issue_comments` | PR conversation comments |123| `commits` | Commit list with messages |124| `repo` | Repository metadata (language, size, defaults) |125| `author_history` | Author's recent closed PRs and merge rate |126| `has_codeowners` | Boolean |127| `has_contributing` | Boolean |128129## Error Handling130131The script outputs `"error"` fields when individual API calls fail (e.g., rate limits, 404s). Analyze what's available and note any missing data in the report.
dvcrn