Skillppx logo

Merge Check

基于技术、流程与社交因素分析 GitHub Pull Request 的合并可能性。

已扫描
适合谁
开源项目维护者、希望提升 PR 通过率的开发者
不适合谁
无需参与代码审查的普通用户、不使用 GitHub 的团队
国内可用性
需网络配置。可能需要网络配置或第三方服务可访问。
安装难度
新手友好（★☆☆）。基于终端操作、依赖、API Key 和本地环境要求的初步判断。

安装与下载

openclaw skills install @tag-assistant/merge-check
下载官方 ZIP

Skill 说明

命令、参数、文件名以原文为准

合并检查

通过分析 PR 与全面的拒绝向量分类法的匹配情况，预测一个 GitHub PR 是否会被合并。这不是通用代码质量工具——它回答的核心问题是：“维护者是否会合并这个 PR？”

快速开始

  1. 运行数据收集脚本：
   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
  1. 解析 JSON 输出结果
  2. 根据以下维度进行分析
  3. 生成合并可行性报告

分析维度

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

1. 技术信号（自动化门禁）

  • CI 状态：所有检查是否均通过？是否存在失败或待定状态？
  • 构建状态：代码能否正常编译/构建？
  • 覆盖率：是否有覆盖率下降的情况？

2. PR 规范性

  • 变更规模（最具预测力的单一因素）：

- 🟢 <400 行代码变更 —— 理想状态，易于审查

- 🟡 400–1000 行代码变更 —— 风险较高，易引发审查疲劳

- 🔴 >1000 行代码变更 —— 危险区域，极可能停滞或被拒绝

  • 文件分布：变更集中在单一目录，还是分散在多个目录中？
  • 单一关注点：是否只解决一个问题？还是像“万能筐”一样包含多种改动？
  • 标题与描述：是否清晰、具体？还是模糊或空缺？
  • 关联问题：是否引用了相关 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. 合并可行性评分：🟢/🟡/🔴 及百分比估算
  2. 风险因素：按严重性排序的具体担忧列表
  3. 优势点：对 PR 有利的因素
  4. 建议措施：可操作的改进建议（若非🟢状态）
  5. 结论：一句话总结

示例输出

## PR 合并可行性报告：owner/repo#123

**评分：🟡 中等 (~55%)**

### 风险因素
- ⚠️ 共变更 847 行代码 —— 接近审查疲劳阈值
- ⚠️ @maintainer 提出的修改意见尚未回应
- ⚠️ 涉及 12 个文件，分布在 6 个目录中 —— 范围分散
- ℹ️ 未关联任何 issue

### 优势点
- ✅ 所有 14 项 CI 检查均通过
- ✅ 标题清晰，描述详尽
- ✅ 作者在本仓库的合并率为 73%（11 次中成功合并 8 次）
- ✅ 交流活跃 —— 最近一次更新为 2 小时前

### 建议措施
1. 在请求重新审查前，先处理 @maintainer 的反馈意见
2. 考虑拆分为更小的 PR（例如配置变更与逻辑变更分离）
3. 添加相关 issue 以增强可追溯性

### 结论
这是一个具备良好 CI 状态和活跃作者的优质 PR，但因未回应审查反馈而陷入停滞——解决这些评论是促成合并的关键路径。

脚本参考

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

键内容
prPR 完整元数据（标题、正文、作者、状态、草稿、标签、审查人）
files变更文件列表及其补丁统计信息
diff_stats总增加行数、删除行数、变更文件总数
checks头提交的 CI/检查运行结果
reviews所有审查记录（批准、请求修改、评论）
review_comments内联审查评论
issue_commentsPR 会话中的评论
commits提交列表及其消息
repo仓库元数据（语言、大小、默认设置）
author_history作者近期关闭的 PR 及合并率
has_codeowners布尔值，表示是否存在 CODEOWNERS 配置
has_contributing布尔值，表示是否存在 CONTRIBUTING 文件

错误处理

当个别 API 调用失败时（如速率限制、404 错误），脚本会输出 "error" 字段。分析可用数据，并在报告中注明缺失信息。

TA
@tag-assistant

已收录 1 个 Skill

相关推荐