stacked-pr-base-branch-deletion-auto-closes-dependent

Recover stacked GitHub PRs auto-closed by base-branch deletion after squash merge.

3|Updated May 8, 2026
One-click install
npx skills add https://github.com/wan-huiyan/agent-traffic-control --skill stacked-pr-base-branch-deletion-auto-closes-dependent-wan-huiyan
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: stacked-pr-base-branch-deletion-auto-closes-dependent
Source: https://github.com/wan-huiyan/agent-traffic-control/tree/main/plugins/agent-traffic-control/skills/stacked-pr-base-branch-deletion-auto-closes-dependent
Command: npx skills add https://github.com/wan-huiyan/agent-traffic-control --skill stacked-pr-base-branch-deletion-auto-closes-dependent-wan-huiyan

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Deleting a merged PR's branch via the GitHub CLI or Git Refs API silently auto-closes any dependent stacked PR, and that closed PR can neither be reopened nor retargeted to main, leaving your work stranded on a dead pull request. ## Core Features & Use Cases - Diagnosis of the auto-close trap: Identifies when a stacked PR was closed because its base branch was deleted via gh pr merge --delete-branch or gh api -X DELETE refs/heads/<branch>, and explains why gh pr reopen and gh pr edit --base both fail. - Recovery procedure: Walks through opening a fresh PR from the same head branch with base=main, preserving the original body and linking the dead PR's review threads. - Recoverable single-PR variant: Covers the case where a never-merged PR's head branch was deleted mid-merge, recoverable via git push plus gh pr reopen. - Prevention patterns: Provides two workflows (merge both PRs before cleanup, or retarget the dependent PR before deleting the base branch) so the trap never fires. - Use Case: You squash-merge PR1 of a two-PR stack with --delete-branch, and PR2 instantly flips to CLOSED with no way to reopen it; this Skill gets you to a merged replacement PR in minutes. ## Quick Start Ask the assistant to recover a stacked PR that was auto-closed after its base branch was deleted following a squash merge.

Frequently Asked Questions about stacked-pr-base-branch-deletion-auto-closes-dependent

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

FAQPage Schema
Why did my stacked PR close after I merged the base PR?▼

Deleting the base PR's branch via gh pr merge --delete-branch or gh api -X DELETE refs/heads/<branch> auto-closes any open PR whose base field pointed at that branch. Only the GitHub web UI delete-branch button auto-retargets dependents instead.

How do I recover a stacked PR that GitHub auto-closed?▼

The closed PR cannot be reopened or retargeted, so open a fresh PR from the same head branch with gh pr create --base main. Reuse the original body and link the dead PR's review threads so the audit trail stays connected.

Why does gh pr reopen fail with Could not open the pull request?▼

GitHub validates that the base ref exists at reopen time, and the deleted base branch fails that check. Retargeting is also blocked because a closed PR's base cannot be changed, leaving the PR permanently dead.

Can I recover a PR if its head branch was deleted before merging?▼

Yes, if the PR was never merged and has no dependents. Re-push the branch with git push origin <branch>, then run gh pr reopen <N>; the full history of commits, comments, and reviews survives the close-and-reopen cycle.

How do I prevent stacked PRs from being auto-closed?▼

Either merge all PRs in the stack before deleting any branch, or retarget the dependent PR to main with gh pr edit --base main before deleting the base branch. Never delete a branch until gh pr view shows state MERGED.

Does gh pr merge --delete-branch avoid the stacked PR auto-close?▼

No. The CLI merge-and-cleanup flow routes through the same Git Refs API deletion and triggers the close cascade on dependent PRs. Only the GitHub web UI delete-branch button auto-retargets dependents before deleting.