delete-merged-branch

name	Delete Merged Branch
description	After merging a PR in this repo, clean up the head branch unless it's protected. Use whenever a `gh pr merge` succeeds.

Delete Merged Branch

After merging a PR (gh pr merge), delete its head branch on origin — unless it's protected. Stale merged branches accumulate fast in this repo (56 got swept in one pass on 2026-08-15), and nobody references a feature/fix branch by name once its work has landed on the target branch.

Protected — leave these alone

• master (and main, if ever renamed)
• A bare version-number branch: ^v?[0-9]+(\.[0-9]+)*$ — e.g. 4.6.1, 4.6.0, 3.4. These are permanent release-history branches, not work-in-progress.
• Anything the user names as an exception for this merge. Example from 2026-08-15: 4.6.1-beta1 had to stay because an external OSS-Fuzz build config (project.yaml) still pointed its fuzzing job at that branch name. If unsure whether such a pin still applies, ask rather than assume it's gone.

Not protected — delete these, even if they look version-ish

A version number with a suffix (4.6.0-alpha, 4.5.0-beta3, v4.5.3-beta2) is not a permanent branch — it's leftover from a pre-release cycle that's over. Default to deleting it. The same goes for anything descriptive (fix-*, Bug_*, credit-*, PR-author feature branches, etc.). When genuinely unsure whether a branch name is "version-like enough" to protect, treat it as not protected — the cost of a mistaken delete is low (commits stay reachable via the target branch's history for anything that was actually merged; git reflog/GitHub's branch-restore banner covers the rest for a while), and the point of this skill is to stop clutter from piling up.

How

gh pr merge <number> --merge --delete-branch

--delete-branch handles both the merge and cleanup in one call. If you already merged without it, delete separately:

git push origin --delete <branch>

Either way, confirm and mention the branch is gone (or why it was kept) — don't do this silently.