← ClaudeAtlas

finishing-a-development-branchlisted

Use when verified work needs branch integration or cleanup. Triggers on "work is done", "ship this", "merge or PR", or "wrap up the branch". Code review usually comes first.
lawzava/megapowers · ★ 4 · AI & Automation · score 73
Install: claude install-skill lawzava/megapowers
# Finishing a Development Branch ## Overview The work is done and needs a destination. Verify tests, detect the workspace state, present a fixed menu, execute the choice, and clean up only what this process owns. ## Before offering options Run the project's test suite and read the output. If tests fail, report the failures and stop; no menu until they pass. Detect the workspace state, because it decides both the menu and the cleanup. Compare `git rev-parse --git-dir` with `git rev-parse --git-common-dir`, both resolved to physical paths: - Equal: a normal repo. Standard menu, nothing to remove afterward. - Unequal, on a named branch: a worktree. Standard menu, provenance based cleanup. - Unequal, detached HEAD: an externally managed workspace. Reduced menu, no cleanup. Identify the base branch (merge-base against main or master, or ask) so the merge and PR targets are correct. ## The menu If the user already stated the destination, validate the relevant gates and execute that choice directly. Do not show the menu. Explicit destructive confirmation still applies to discard. Show the menu only when the destination is unclear. Normal repo and named branch worktree, exactly these 4 options, no added commentary: ``` Implementation complete. What would you like to do? 1. Merge back to <base-branch> locally 2. Push and create a Pull Request 3. Keep the branch as-is (I'll handle it later) 4. Discard this work Which option? ``` Detached HEAD, exactly these 3 (no local me