merge-check

分析 GitHub 拉取请求的可合并性 - 根据技术、架构、流程、社交和合规性因素预测它是否会被合并。当要求审查 PR、检查 PR 是否将被合并、评估 PR 质量或预测 PR 接受时使用。通过“owner/repo#number”或 URL 与任何 GitHub PR 配合使用。

# 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
   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
3. Analyze against the dimensions below
4. 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
2. **Risk Factors**: Bullet list of specific concerns, ordered by severity
3. **Strengths**: What's working in the PR's favor
4. **Recommendations**: Actionable steps to improve mergeability (if not already 🟢)
5. **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.

---

## 中文说明

# Merge Check

通过对照一套全面的拒绝向量分类法进行分析，预测某个 GitHub PR 是否会被合并。这不是通用的代码质量工具，它回答的是：**“维护者会合并这个 PR 吗？”**

## 快速开始

1. 运行数据收集脚本：
   ```bash
   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. 解析 JSON 输出
3. 对照下面的各个维度进行分析
4. 生成可合并性报告

## 分析维度

收集数据后，从以下所有维度进行分析。加载 `skills/merge-check/references/rejection-taxonomy.md` 以获取详细的拒绝向量框架。

### 1. 技术信号（自动化关卡）
- **CI 状态**：所有检查是否都通过？是否有失败或待处理的？
- **构建状态**：能否编译/构建？
- **覆盖率**：是否出现覆盖率回退？

### 2. PR 卫生
- **规模**（最具预测力的单一因素）：
  - 🟢 <400 LOC 改动 — 理想，易于审查
  - 🟡 400–1000 LOC — 有风险，审查者疲劳
  - 🔴 >1000 LOC — 危险区，很可能停滞或被拒绝
- **文件分布**：集中在一个区域，还是分散在多个目录？
- **单一关注点**：它只做一件事，还是一个大杂烩式 PR？
- **标题与描述**：清晰、有描述性？还是含糊/空白？
- **关联 issue**：是否引用了某个 issue？（体现意图性）
- **提交卫生**：提交信息是否干净？数量是否合理？是否适合 squash？

### 3. 架构契合度
- **模式一致性**：是否遵循仓库约定？（语言、目录结构、命名）
- **依赖**：是否引入了新依赖？（高摩擦信号）
- **范围蔓延**：是否触及其声明目的之外的内容？
- **文件类型**：是否与仓库的技术栈一致？

### 4. 审查状态
- **批准**：是否已有批准？需要多少个？
- **请求修改**：是否有未处理且未解决的？（强烈的拒绝信号）
- **审查者指派**：是否已指派必需的审查者？
- **审查评论情绪**：正面、中立还是对立？
- **CODEOWNERS**：PR 是否触及有代码负责人的文件？他们在审查吗？

### 5. 流程合规
- **草稿状态**：草稿 PR 不会被合并
- **阻断性标签**：WIP、do-not-merge、needs-work 等
- **PR 模板**：是否被遵循？（空模板 = 危险信号）
- **CLA/DCO**：如果仓库要求，是否已签署？

### 6. 社交/元信号
- **作者合并历史**：该作者在此仓库最近的 PR 中有多大比例被合并？
- **陈旧度**：已开启多久？（>2 周 = 需关注，>30 天 = 很可能已被弃置）
- **活跃度**：近期是否有评论/更新，还是杳无音讯？
- **首次贡献者**：新人的拒绝率更高

## 输出格式

生成一份结构化报告：

### 可合并性评分
- 🟢 **高**（>80% 可能合并）— 无阻断项，审查正面，CI 通过
- 🟡 **中**（40–80%）— 存在一些可解决的顾虑
- 🔴 **低**（<40%）— 存在重大阻断项

### 报告章节
1. **可合并性评分**：🟢/🟡/🔴 并附百分比估计
2. **风险因素**：具体顾虑的项目符号列表，按严重程度排序
3. **优势**：PR 有利的方面
4. **建议**：提升可合并性的可执行步骤（如果尚未达到 🟢）
5. **结论**：一句话总结

### 示例输出
```
## 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.
```

## 脚本参考

该脚本（`scripts/merge-check.sh`）通过 `gh` CLI 收集所有数据，并输出一个包含以下键的 JSON 对象：

| 键 | 内容 |
|-----|----------|
| `pr` | 完整的 PR 元数据（标题、正文、作者、状态、草稿、标签、审查者） |
| `files` | 改动