关于 merge-pr-check
用于按合并标准审查 Gitee Pull Request 并给出合并建议的技能。它检查 PR 状态、评审反馈和变更文件,并要求用户明确确认后才执行合并。
主要功能
- 01检查 PR 状态与分支
- 02审阅评论和未解决讨论
- 03核对变更文件与 PR 范围
- 04生成合并评估报告
- 05确认后执行合并
适用场景
- 01评估 Gitee PR 是否可合并
- 02查找未解决的评审反馈
- 03确认后合并已批准的 PR
MCP 相关
通过 Gitee MCP Server 的 get_pull_detail、list_comments、get_diff_files 和 merge_pull 工具检查及合并 Pull Request。
安装
复制下面的命令,在终端中运行。
$
npx skills add https:/ / github.com/ oschina/ gitee-agent-skills --skill merge-pr-check安装后在 Claude Code 中输入/merge-pr-check确认已加载。
详细介绍
注意:如果你在本地安装了
mcporter,应使用mcporter调用 MCP 工具,而不是直接调用 MCP 工具。mcporterCLI 提供了更便捷的接口和更完善的错误处理。
通过 Gitee MCP 检查 PR 是否可合并
检查 Pull Request 是否符合合并条件,并在确认后执行合并。
前提条件
- 已配置 Gitee MCP 服务(工具:
get_pull_detail、list_comments(resource_type: pull)、get_diff_files、merge_pull) - 用户必须提供:仓库所有者、仓库名称、PR 编号
步骤
步骤 1:获取 PR 状态
使用 get_pull_detail 获取 PR 详情并检查:
基本状态
- PR 是否处于开启状态(如果已关闭或已合并,则停止)
- PR 是否为 Draft — 如果是,告知用户必须先将其转换为常规 PR
- 源分支和目标分支是否正确
合并前检查清单
- PR 是否有说明变更目的的描述
- 是否已指定审阅者
步骤 2:分析评论和审阅反馈
使用 list_comments(resource_type: pull)获取所有评论并检查:
- 是否有审阅者明确反对合并(例如“拒绝”“需要修改”“不要合并”)
- 是否存在尚未解决的讨论(提出问题但无人回复)
- 是否有 LGTM 或 Approved 回复
步骤 3:快速检查差异
使用 get_diff_files 检查变更文件:
- 是否存在明显遗漏(例如代码已更改,但相关配置未更新)
- 是否包含意外文件(调试代码、临时文件)
- 变更范围是否与 PR 描述一致
步骤 4:提供合并建议
根据上述检查,输出合并评估报告:
## PR Merge Check Report
**PR**: #[number] [title]
**Status**: [Open/Draft/Closed]
### Checklist
✅ PR is in Open state
✅ Has a change description
⚠️ No reviewer approval yet
✅ Diff scope is reasonable
### Conclusion
[Ready to merge / Recommend waiting for review / Not recommended to merge]
Reason: [Specific explanation]
步骤 5:执行合并(需要用户确认)
如果检查通过,请求用户确认合并。
确认后,使用 merge_pull 并提供以下参数:
merge_method:合并策略 —merge(创建合并提交)、squash(压缩提交),或rebase- 默认建议:
merge;如果 PR 包含许多杂乱的提交,则建议使用squash
- 默认建议:
commit_message:合并提交信息(可选,默认为 PR 标题)
成功合并后,输出结果,并询问用户是否要删除源分支。
备注
- 合并不可逆 — 执行前务必等待用户明确确认
- 如果存在冲突,Gitee API 将返回错误 — 提示用户先解决冲突
- 建议在合并前确认 CI 已通过(检查 PR 的状态检查)
评论
支持 Markdown