stacked-prslisted

Manage a stack of dependent pull requests (a chain where each PR's base is the branch below it, up to main) using git + gh. Use when working with stacked or dependent PRs, merging the bottom of a stack, retargeting a PR's base to main, propagating main or a review fix up a chain of branches, resolving conflicts across a PR stack, or recovering a stacked PR that was auto-closed when its base branch was deleted.
magnusrodseth/dotfiles · ★ 2 · AI & Automation · score 65

Install: claude install-skill magnusrodseth/dotfiles

# Stacked PRs A **stack** is a chain of PRs where each PR's base branch is the **head** branch of the one below it, down to a PR whose base is `main`: ``` main ← A (branch a) ← B (branch b) ← C (branch c) PR #A PR #B PR #C base: main base: a base: b ``` Each PR's diff shows only **its own layer** because it is compared against the branch below. The bottom is closest to main; the top is furthest. **Map a stack before touching it:** ```bash gh pr list --repo <owner/repo> --state open \ --json number,title,headRefName,baseRefName,mergeable,reviewDecision ``` Chain them by `baseRefName == headRefName` down to the PR whose base is `main`. That order is the stack, bottom→top. Anything whose base is `main` is a bottom. ## The cardinal rule (read before merging anything in a stack) > **GitHub closes — it does NOT reliably retarget — a PR whose base branch is deleted.** With `delete_branch_on_merge` enabled (common), merging the bottom PR deletes its branch, which silently **closes** the PR sitting on it. > > **So retarget the next PR up to `main` BEFORE you merge/delete the branch it sits on:** > ```bash > gh pr edit <next-up-PR> --repo <owner/repo> --base main > ``` Retarget-before-merge makes the auto-close impossible — the dependent now sits on `main`, which never gets deleted. Do not rely on GitHub's documented auto-retarget; it does not fire when the branch is auto-deleted on merge (verified). Check the repo's