re-land-orphaned-pr

Recover merged pull request changes that never reached the default branch.

5|1|Updated Aug 18, 2023
One-click install
npx skills add https://github.com/thpoll83/PolyKybdHost --skill re-land-orphaned-pr-thpoll83
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: re-land-orphaned-pr
Source: https://github.com/thpoll83/PolyKybdHost/tree/main/.claude/skills/re-land-orphaned-pr
Command: npx skills add https://github.com/thpoll83/PolyKybdHost --skill re-land-orphaned-pr-thpoll83

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? A PR can show a "merged" badge while its changes never actually reach the default branch — stacked PRs merged before GitHub retargets them, pushes onto already-merged branches, or merges against stale bases. This Skill detects those orphaned merges and re-lands the lost work on a fresh branch cut from the current default branch. ## Core Features & Use Cases - Orphan Detection: Verify with git merge-base --is-ancestor and content checks (git cat-file, git show) whether a merged PR's head and files actually exist on main. - Damage Assessment: Measure staleness with git log and git diff --stat to determine whether merging the old branch would revert newer work. - Faithful Re-landing: Reconstruct the PR's exact diff with git diff <base> <head> | git apply --3way onto a branch cut from current main, then verify fidelity against the original head and run the test suite. - Use Case: You merged a stacked PR one minute after its base, both show "merged", but a fresh clone lacks the feature. This Skill confirms the orphan, re-lands the diff on a new branch, and opens a replacement PR with the evidence reviewers need. ## Quick Start Ask the assistant to check whether PR #245's changes actually landed on main and re-land them if they are missing.

Frequently Asked Questions about re-land-orphaned-pr

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I check if a merged PR actually landed on main?

Run git merge-base --is-ancestor <pr-head-sha> origin/main after fetching; a non-zero exit means the head is not on main. Confirm by content with git cat-file -e origin/main:<file> to check whether files the PR added are actually present.

Why does my PR show merged but the code is missing from main?

This happens when a stacked PR merges before GitHub retargets it to the default branch, so its commits land on the base PR's already-merged branch. It also occurs when commits are pushed onto a branch whose PR already closed.

How do I recover commits from an orphaned merged branch?

Cut a new branch from current origin/main, then run git diff <pr-base-head> <pr-head> | git apply --3way to replay the PR's exact diff. The three-way apply preserves work main gained meanwhile, unlike merging the stale branch.

Can I just merge the old branch to fix a missing PR?

No. The orphaned branch is stale by construction, and merging it would revert work that landed on main in between. Re-landing the PR's own diff onto a fresh branch from current main is the safe fix.

How do I prevent stacked PRs from being orphaned on GitHub?

Merge the base PR first, then wait for GitHub to retarget the stacked PR to the default branch (its base.ref changes) before merging it. Merging both within the same minute is what causes the orphan.