What problem does it solve? When you push iterative commits to an open PR and the user squash-merges it mid-iteration, GitHub only captures the commits present at merge time — your later commits silently never reach main. The PR shows MERGED, nothing errors, but main is missing your work. ## Core Features & Use Cases - Diagnosis checklist: Confirms the failure mode using gh pr view --json state, git show --stat insertion counts, and git log range comparisons between the closed branch and main. - Recovery recipe: Branch off current main, cherry-pick the stranded commits in order, and open a follow-up PR with a pre-filled body template explaining what was missed. - Prevention protocol: Verify PR state with gh pr view <num> --json state before every push to an open-PR branch, plus guidance on rebase-merge vs squash-merge tradeoffs. - Rebase hazard warning: Documents why git rebase --onto across a squash-merged boundary can silently drop commits, and mandates the branch-fresh-plus-cherry-pick pattern instead. - Use Case: You pushed commit 1, opened a PR, then pushed commits 2 and 3 responding to feedback — only to discover the PR was already squash-merged with just commit 1. This Skill walks you through recovering commits 2 and 3 onto main via a follow-up PR. ## Quick Start Check whether my follow-up commits on the closed PR branch made it into main after the squash-merge, and if not, help me cherry-pick them into a new follow-up PR.
