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
- 1. 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
- 2. 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
- 1. 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
CODEBLOCK1
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 |
|---|
| INLINECODE3 | Full PR metadata (title, body, author, state, draft, labels, reviewers) |
| INLINECODE4 |
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.
技能名称: merge-check
详细描述:
合并检查
通过针对全面的拒绝向量分类法进行分析，预测一个 GitHub PR 是否会被合并。这不是一个通用的代码质量工具——它回答的是：这个 PR 会被维护者合并吗？
快速开始
- 1. 运行数据收集脚本：
bash
bash skills/merge-check/scripts/merge-check.sh owner/repo#123
# 或
bash skills/merge-check/scripts/merge-check.sh https://github.com/owner/repo/pull/123
- 2. 解析 JSON 输出
- 根据以下维度进行分析
- 生成可合并性报告
分析维度
收集数据后，对以下所有维度进行分析。加载 skills/merge-check/references/rejection-taxonomy.md 以获取详细的拒绝向量框架。
1. 技术信号（自动化关卡）
- - CI 状态：所有检查是否通过？是否有失败或待处理？
- 构建状态：能否编译/构建？
- 覆盖率：是否显示有覆盖率回归？
2. PR 卫生状况
- 🟢 <400 行代码变更——理想，易于审查
- 🟡 400–1000 行代码——有风险，审查者疲劳
- 🔴 >1000 行代码——危险区域，可能停滞或被拒绝
- - 文件分布：集中在某个区域还是分散在多个目录？
- 单一关注点：它只做一件事，还是一个大杂烩PR？
- 标题与描述：清晰、有描述性？还是模糊/空白？
- 关联问题：是否引用了某个 issue？（表明有意图性）
- 提交卫生：提交信息清晰吗？数量合理吗？是否可压缩合并？
3. 架构适配性
- - 模式一致性：是否遵循仓库惯例？（语言、目录结构、命名）
- 依赖项：是否引入了新的依赖项？（高摩擦信号）
- 范围蔓延：是否触及了其声明目的之外的内容？
- 文件类型：是否与仓库的技术栈一致？
4. 审查状态
- - 批准：是否已有批准？需要多少？
- 请求变更：是否有未解决的变更请求？（强烈的拒绝信号）
- 审查者分配：是否分配了所需的审查者？
- 审查评论情绪：积极、中立还是对抗性？
- CODEOWNERS：PR 是否触及了有代码所有者的文件？他们是否在审查？
5. 流程合规性
- - 草稿状态：草稿 PR 不会被合并
- 阻塞标签：WIP、do-not-merge、needs-work 等
- PR 模板：是否遵循了模板？（空模板 = 危险信号）
- CLA/DCO：如果仓库要求，是否已签署？
6. 社交/元信号
- - 作者合并历史：该作者最近在该仓库的 PR 中，合并的百分比是多少？
- 陈旧度：PR 已打开多久？（>2 周 = 值得关注，>30 天 = 可能已放弃）
- 活跃度：最近有评论/更新，还是完全沉寂？
- 首次贡献者：新人的拒绝率更高
输出格式
生成结构化报告：
可合并性评分
- - 🟢 高（>80% 可能合并）——无阻塞项，审查积极，CI 通过
- 🟡 中（40–80%）——存在一些问题但可解决
- 🔴 低（<40%）——存在重大阻塞项
报告章节
- 1. 可合并性评分：🟢/🟡/🔴 并附百分比估计
- 风险因素：按严重程度排序的具体问题列表
- 优势：PR 中有利的因素
- 建议：提高可合并性的可行步骤（如果尚未达到 🟢）
- 结论：一句话总结
示例输出
PR 可合并性报告：owner/repo#123
评分：🟡 中（约55%）
风险因素
- - ⚠️ 变更了 847 行代码——接近审查者疲劳阈值
- ⚠️ @maintainer 请求的变更尚未处理
- ⚠️ 触及了 6 个目录中的 12 个文件——范围分散
- ℹ️ 未关联 issue
优势
- - ✅ 所有 14 项 CI 检查均通过
- ✅ 标题清晰，描述详细
- ✅ 作者在该仓库的合并率为 73%（最近 11 个 PR 中合并了 8 个）
- ✅ 讨论活跃——上次更新在 2 小时前
建议
- 1. 在请求重新审查之前，先处理 @maintainer 的审查意见
- 考虑拆分为更小的 PR（配置变更 vs 逻辑变更）
- 关联相关 issue 以便追溯
结论
CI 通过且作者活跃，是一个扎实的 PR，但因未处理的审查反馈而停滞——解决这些评论是合并的关键路径。
脚本参考
脚本（scripts/merge-check.sh）通过 gh CLI 收集所有数据，并输出一个包含以下键的 JSON 对象：
| 键 | 内容 |
|---|
| pr | 完整的 PR 元数据（标题、正文、作者、状态、草稿、标签、审查者） |
| files |
变更文件列表及补丁统计信息 |
| diff_stats | 总添加行数、删除行数、变更文件数 |
| checks | 头部提交的 CI/检查运行结果 |
| reviews | 所有审查（已批准、请求变更、已评论） |
| review_comments | 内联审查评论 |
| issue_comments | PR 对话评论 |
| commits | 提交列表及提交信息 |
| repo | 仓库元数据（语言、大小、默认设置） |
| author_history | 作者最近的已关闭 PR 及合并率 |
| has_codeowners | 布尔值 |
| has_contributing | 布尔值 |
错误处理
当个别 API 调用失败时（例如速率限制、404），脚本会输出 error 字段。分析可用的数据，并在报告中注明任何缺失的数据。
