branch-cleanuplisted

Install GitHub Actions workflows that delete stale git branches safely — the closed-without-merging path plus a scheduled orphan sweep — and enable the native delete_branch_on_merge setting that handles merged PRs. Host-agnostic: no Vercel, Neon or any external service required, works in any GitHub repo. Never deletes a branch that open PRs target as their BASE (that would CLOSE those PRs and destroy a stack). Use when asked to clean up / delete stale, merged, abandoned or orphaned branches, stop branches piling up, auto-delete branches after merge, enable delete_branch_on_merge across an org, add a branch retention or sweep workflow, or safely prune branches in a repo that uses stacked PRs — GitHub's native stacks (gh stack), Graphite, ghstack or spr.
stealth-factory/skills · ★ 3 · AI & Automation · score 72

Install: claude install-skill stealth-factory/skills

# Branch cleanup Authors GitHub Actions workflows that delete stale branches. **This skill installs workflows; it never deletes anything itself.** At runtime there is no agent and no model call — deterministic bash + `gh` only. Verified GitHub behaviour (the `delete` event, ruleset errors, `gh` footguns, base-branch semantics) lives in [`reference/github-facts.md`](./reference/github-facts.md). Read it before changing any deletion logic. ## The one rule that must never be relaxed **Before deleting ANY branch, check for open PRs that target it as base:** ```bash gh pr list --base <branch> --state open --json number --limit 1000 ``` GitHub documents it plainly: *"If the branch is associated with at least one open pull request, deleting the branch closes the pull requests."* That is often **unrecoverable** — you cannot retarget a closed PR, nor reopen it while its base is missing. Two traps that make this worse than it looks: - **`gh pr list --limit` defaults to 30.** A stack deeper than 30 silently under-reports and the guard passes when it shouldn't. Always pass an explicit high limit. - **Auto-retargeting will not save you.** It only applies to a *head* branch whose PR is *already merged*, and it appears to live in the **web** deletion path — community reports (one confirmed by GitHub staff as a bug) say deleting a ref via API or `git push --delete` **closes** dependent PRs instead. A bot must assume the close path. All of this runs **inside `delete_branch()`