Merge Pr Check

v1.0.0

Use this skill when the user asks to merge a PR, check if a PR is ready to merge, "merge PR", "can this PR be merged", "merge-pr-check". Requires Gitee MCP S...

0· 251·1 current·1 all-time
by开源中国@oschina
Security Scan
VirusTotalVirusTotal
Benign
View report →
OpenClawOpenClaw
Benign
high confidence
Purpose & Capability
Name/description ask to check and merge PRs on Gitee; the SKILL.md explicitly requires a Gitee MCP Server and references MCP operations (get_pull_detail, list_pull_comments, get_diff_files, merge_pull) relevant to that purpose. There are no unrelated env vars, binaries, or config paths requested.
Instruction Scope
Instructions are scoped to fetching PR details, comments, diffs, producing a checklist, and (with explicit user confirmation) calling merge_pull. They do not direct reading local files, arbitrary environment variables, or sending data to unexpected external endpoints. The note to prefer mcporter (if present) is advisory and not risky by itself.
Install Mechanism
No install spec and no code files — instruction-only. Nothing is downloaded or written to disk by the skill itself.
Credentials
No environment variables or credentials declared by the skill. The only external dependency is the configured Gitee MCP Server; any credentials/access are expected to be part of that server configuration, which is proportional to the task.
Persistence & Privilege
always:false (default) and normal model invocation allowed. The skill does not request permanent presence or claim to modify other skills or system-wide settings.
Assessment
This skill appears coherent and limited to Gitee PR merge workflows. Before installing or enabling it: (1) verify the Gitee MCP Server it will call is correct and trusted (endpoint, owner, and access tokens) and that those credentials have least privilege (only the repos/actions needed). (2) Ensure you explicitly confirm merges — the skill correctly requests user confirmation before calling merge_pull. (3) Confirm CI/status checks are available in your PR metadata or otherwise validate CI before merging. (4) Because this is instruction-only, the skill itself does not embed code to inspect, so the runtime behavior depends on the MCP integration — audit that integration and its logs if you need an audit trail. If you do not want autonomous merges, keep autonomous invocation disabled or require an explicit human confirmation step in your agent policy.

Like a lobster shell, security has layers — review code before you run it.

latestvk979q5836n2xxyp8de4tfzkffx82jdek
251downloads
0stars
1versions
Updated 1mo ago
v1.0.0
MIT-0

Note: If you have mcporter installed locally, you should use mcporter to invoke the MCP tool instead of directly calling the MCP tool. The mcporter CLI provides a more convenient interface and better error handling.

Merge PR Check via Gitee MCP

Check whether a Pull Request meets the criteria for merging, then execute the merge after confirmation.

Prerequisites

  • Gitee MCP Server configured (tools: get_pull_detail, list_pull_comments, get_diff_files, merge_pull)
  • User must provide: repository owner, repository name, PR number

Steps

Step 1: Fetch PR Status

Use get_pull_detail to retrieve PR details and check:

Basic status

  • Whether the PR is open (stop if already closed/merged)
  • Whether it is a Draft — if so, inform the user it must be converted to a regular PR first
  • Whether source and target branches are correct

Pre-merge checklist

  • Whether the PR has a description explaining the purpose of the changes
  • Whether a reviewer has been assigned

Step 2: Analyze Comments and Review Feedback

Use list_pull_comments to retrieve all comments and check:

  • Whether any reviewer has explicitly objected to merging (e.g., "NACK", "needs changes", "do not merge")
  • Whether there are unresolved discussions (questions raised but not replied to)
  • Whether there are any LGTM or Approved responses

Step 3: Quick Diff Check

Use get_diff_files to inspect changed files:

  • Whether there are obvious omissions (e.g., code changed but related config not updated)
  • Whether unexpected files are included (debug code, temp files)
  • Whether the scope of changes matches the PR description

Step 4: Provide Merge Recommendation

Based on the checks above, output a merge assessment report:

## 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]

Step 5: Execute Merge (requires user confirmation)

If the checks pass, ask the user to confirm the merge.

After confirmation, use merge_pull with these parameters:

  • merge_method: merge strategy — merge (creates a merge commit), squash (squashes commits), or rebase
    • Default recommendation: merge; suggest squash if the PR has many messy commits
  • commit_message: merge commit message (optional, defaults to PR title)

After a successful merge, output the result and ask whether the user wants to delete the source branch.

Notes

  • Merging is irreversible — always wait for explicit user confirmation before proceeding
  • If there are conflicts, the Gitee API will return an error — prompt the user to resolve conflicts first
  • It is recommended to confirm that CI has passed before merging (check the PR's status checks)

Comments

Loading comments...