pr-merge
This skill should be used when the user asks to "merge a PR", "review and merge pull requests", "integrate external contributions", "handle PR conflicts", "cherry-pick from a PR", or needs to merge GitHub PRs while maximizing contributor attribution.
pinned to #9b2efd7updated 2 weeks ago
Ask your AI client: “install skills/pr-merge”.
Requires the metahub MCP server installed in your client. Set up MCP.
mh install skills/pr-mergemetahub onboarded this repo on the author's behalf.
If you own github.com/HKUDS/OpenHarness on GitHub, claim the listing to take over publishing. Your claim preserves the existing eval history and badges; only the curator label is replaced with verified-publisher on your next publish.
Stars
14,702
Last commit
2 weeks ago
Latest release
published
About this skill
Pulled from SKILL.md at publish time.
Merge external pull requests while maximizing original author attribution. Core principle: **merge first, resolve conflicts after** — never rewrite a contributor's work from scratch.
Evaluation report
WarningsAutomated checks the publisher passed at publish time — structure, docs, safety, and whether the artifact behaves as claimed.9b2efd7· 2 weeks ago
Documentation
41Description quality
38 words · 250 chars — "This skill should be used when the user asks to "merge a PR", "review and merge …"
README is present and substantial
32,388 chars · 15 sections · 34 code blocks
Tags / topics declaredwarn
No manifest tags and no GitHub repo topics
Add tags to the manifest (or GitHub topics on the repo) so the registry's search and category filters surface this artifact.
README has usage / example sections
no labeled section but 34 code blocks document usage
Homepage / docs URL declared
no homepage declared (registry will use the repo URL) — info-only, not blocking
Release history
1- releasecurrent9b2efd7warn2 weeks ago
Contents
Merge external pull requests while maximizing original author attribution. Core principle: merge first, resolve conflicts after — never rewrite a contributor's work from scratch.
Core Principles
- Preserve authorship — use
gh pr merge --squashfor clean PRs. For manual merges, use--author="Name <email>". - Merge first, fix after — accept the PR's approach even if it differs from local style. Fix conflicts in a separate commit.
- Selective merge is OK — exclude files with
--excludewhen a PR contains features already implemented locally. Document what was excluded. - Never
git apply+ self-commit — this loses author attribution entirely.
Workflow
1. Triage Open PRs
gh pr list --repo OWNER/REPO --state open \
--json number,title,author,additions,deletions,mergeable
Classify each PR: merge directly, merge with conflict resolution, selective merge, or close.
2. Merge Clean PRs via GitHub
Prefer gh pr merge — preserves author automatically:
gh pr merge NUMBER --repo OWNER/REPO --squash \
--subject "feat: description (#NUMBER)"
3. Handle Conflicting PRs Locally
git fetch origin pull/NUMBER/head:pr-NUMBER
git merge pr-NUMBER --no-edit
# Resolve conflicts keeping both sides where possible
git add -A && git commit --no-edit
4. Selective Merge (Skip Some Files)
When a PR contains features already implemented locally:
gh pr diff NUMBER --repo OWNER/REPO | \
git apply --exclude='path/to/skip.py' --exclude='CHANGELOG.md'
git commit --author="Author Name <author@email>" \
-m "feat: description (#NUMBER)
Cherry-picked from PR #NUMBER. Excluded: file.py (already implemented)."
5. Close Duplicate/Superseded PRs
gh pr close NUMBER --repo OWNER/REPO \
--comment "Fixed via PR #OTHER. Thank you for the contribution!"
6. Post-Merge Verification
python -m ruff check src/ tests/ # lint
python -m pytest tests/ -q # unit tests
git push origin main # push
Then run harness-eval for end-to-end verification on an unfamiliar codebase.
Attribution Checklist
Before pushing a merged PR:
- Original author appears in
git log(via--authoror GitHub squash merge) - Commit message references PR number (
#NUMBER) - If selectively merged, commit body explains exclusions
- Closed PRs have a comment thanking the contributor
- Duplicate PRs acknowledge the contributor's investigation
Common Pitfalls
git apply+ self-commit loses author- Rewriting from scratch instead of merging — merge their code, fix style after
- Force-pushing main after merge — may remove contributor commits
- Forgetting CHANGELOG conflicts — always exclude and handle manually
- Not testing after merge — clean merge doesn't mean working code
Additional Resources
Reference Files
references/merge-scenarios.md— Detailed examples for each merge scenario (clean, conflicting, selective, duplicate)
Reviews
No reviews yet. Be the first.
Related
CLI Anything
"CLI-Anything: Making ALL Software Agent-Native" -- CLI-Hub: https://clianything.cc/
Verification Before Completion
Evidence before assertions, always
Writing Plans
Turn specs into phased implementation plans
mh install skills/pr-merge