pr-followup-commit-stranded-after-squashlisted

Diagnose and recover follow-up commits that were pushed to an open PR's branch but never reached `main` because the user squash-merged the PR between pushes. Use when: (1) you pushed commit 1, opened a PR, then iteratively pushed commits 2, 3, ... in response to user feedback, (2) you go to merge / verify and find the PR is already MERGED, (3) the squash commit on main has insertion counts / file content matching ONLY commit 1 — your follow-up commits are stranded on the now-closed branch. Root cause: GitHub squash captures the commits that were on the branch *at merge time*, not what you push afterward. The mental model "squash collapses everything that ever lived on the branch" is wrong. Fix: branch off current main, cherry-pick the stranded commits, open a follow-up PR.
wan-huiyan/agent-traffic-control · ★ 2 · Code & Development · score 79

Install: claude install-skill wan-huiyan/agent-traffic-control

# Follow-up commits stranded after PR squash-merge ## Problem You've been iterating on a PR: pushed commit 1, opened the PR, then pushed commits 2 / 3 / ... in response to user feedback or new information. At some point the user merges the PR — possibly during one of your iterations, possibly before you finished pushing. The squash on `main` only contains commit 1's content. Your follow-up commits sit on the closed branch, never reaching `main`. If you ask `gh pr view N --json state` you see `MERGED`, but the merged content is missing your iterations. This is a silent failure. Nothing errors. The PR appears successfully shipped. But main is incomplete. ## Context / Trigger Conditions All of: 1. You pushed multiple commits asynchronously to a single PR's branch (not all at once before opening the PR). 2. You believed those commits would all land in the squash because they were on the branch at merge time. 3. `gh pr view N --json state` returns `MERGED`. 4. `git show <merge-commit> --stat` shows insertion counts matching only your *first* (or first few) commits — not all of them. 5. `git log --oneline <stranded-branch>..origin/main` returns empty (the branch's later commits never reached main). 6. The closed feature branch still exists locally / on GitHub, holding the stranded commits. ## Why squash captures less than you think GitHub's squash-merge captures the state of the branch at the moment of merge. If the user clicks "Squash and merge" on the GitHub UI when only c