Cleanup

Post-merge cleanup for an issue branch

CLAUDE.md establishes the project's branch flow: every change starts as a GitHub issue, gets a branch named <issue-number>-<short-slug> from dev, and PRs back to dev. Once the PR is merged, four loose ends remain:

1. The GitHub issue is still open (PRs merged to dev don't trigger GitHub's Closes #N auto-close — that only fires on the default branch master).
2. The local feature branch still exists.
3. The remote feature branch still exists (deleteBranchOnMerge is false on this repo).
4. Local dev is behind the merged PR.

This skill handles all four in one pass and leaves the workspace on a fresh dev ready for the next issue.

When to invoke this skill

Yes:

• The user says "cleanup", "cleanup issue N", "wrap up", or similar after confirming a PR merged.
• The user is on a feature branch whose PR is already merged.

No:

• The PR has not merged yet — the skill refuses by design (step 3 below).
• The current branch is dev, master, or a release branch — pass the feature branch name as an argument instead.
• The branch is a release-prep, dev→master sync, or other non-issue branch. The skill keys on the <issue-number>-<slug> naming pattern; branches that don't match need manual cleanup.

Invocation

Two forms:

/cleanup            # infer the target from the current branch
/cleanup 110        # by issue number
/cleanup 110-sphinx-cdecl-warnings  # by branch name

When no argument is given, git branch --show-current is the target. The issue number is the leading integer of the branch name, matched as ^(\d+)-. If the current branch doesn't match the pattern, bail with a message telling the user to pass an explicit argument.

Procedure

1. Resolve target

• If an argument was given:
  • All digits → treat as issue number; resolve the branch via git branch --list "<n>-*" (local) or gh pr list --search "<n> in:title" --json headRefName (remote, if local already gone).
  • Otherwise → treat as the branch name; extract issue number with the ^(\d+)- regex.
• If no argument: use git branch --show-current; extract issue number the same way.
• Refuse if current branch is dev or master and no argument was given — there's nothing to infer.

2. Pre-flight checks

All four must hold or the skill bails with a clear error:

• git status --porcelain is empty (clean working tree). Otherwise switching branches would silently carry changes across or refuse.
• gh pr list --head <branch> --state merged --json number,mergedAt returns at least one merged PR. Capture the PR number for the close comment. If zero results, surface: "No merged PR found for <branch>; did you mean to wait until after merge?"
• gh issue view <n> --json state succeeds. If the issue is already closed, skip step 4 silently and continue.
• The feature branch is not currently dev or master.

3. Verify branch is no longer needed

git log dev..<branch> --oneline — if non-empty, the local branch carries commits that aren't on dev. That usually means the PR was squash- or rebase-merged and the local branch's commit SHAs differ from what landed. This is normal and expected for squash merges. Note it; do not refuse. Step 6's git branch -d will refuse on unsafe deletes anyway.

4. Close the issue

If the issue is open:

gh issue close <n> --comment "Resolved by #<pr> (merged to dev)."

Use --reason completed. Skip if already closed.

5. Switch to dev and pull

git checkout dev
git pull --ff-only origin dev

--ff-only prevents the skill from creating a merge commit if dev has diverged locally (which would itself be a flag that something is off — surface and stop).

6. Delete the local feature branch

git branch -d <branch>

Use -d, not -D. If git refuses because the branch isn't fully merged (common with squash merges), surface the actual git error and ask the user whether to force-delete:

Local branch <branch> has commits not on dev (likely a squash merge — the change is on dev under a different SHA). Force-delete with git branch -D <branch>?

Wait for the user's reply before running -D. Don't quietly upgrade.