Finishing a Development Branch
Verifies tests pass, then walks you through a fixed merge/PR/keep/discard menu and cleans up worktrees by strict ownership rules
The skill provides a concrete completion workflow for finished development branches, covering test verification, environment detection, base-branch selection, merge, PR creation, retention, discard, and cleanup. Structured choices and explicit worktree ownership boundaries are useful. Its boundaries are less clear for non-Git projects, complex release processes, or organizations requiring additional human approvals.
The sequence is clear and includes stopping on failed tests, retesting after a merge, removing a worktree before deleting its branch, and ownership-based cleanup. Reliability is limited because the test commands are placeholders with no method for discovering the project's actual command, and there is no complete recovery procedure for failures in git pull, merge, push, PR creation, branch state checks, uncommitted changes, or merge conflicts.
The skill includes meaningful safeguards: exact discard confirmation, no force-push without an explicit request, cleanup only after successful merge or confirmed discard, and avoidance of harness-owned worktrees. However, it still directs external or destructive actions including push, pull, merge, branch deletion, force deletion, and worktree prune. It lacks a general change summary, remote-state confirmation, backup, or rollback procedure, and does not fully address uncommitted work, unpushed commits, or conflicts.
The skill supplies specific steps, commands, menus, and mistake guidance, which supports a coherent static assessment. Evidence gaps include the absence of skill-specific behavioral tests, test results, execution records, or independent corroboration. The supplied repository tests primarily cover other components and do not establish this skill's behavior. Reliability and safety judgments therefore remain based on document design rather than execution.
Inputs, options, and expected cleanup behavior are fairly explicit, with separate menus for normal repositories, named worktrees, and detached HEAD. Usability is constrained by missing compatibility and troubleshooting details: required Git versions, remote authentication, PR tooling, test-command configuration, and systematic handling of conflicts, permissions, network failures, and exit conditions are not documented.
The repository provides an MIT license, version 6.1.1, contribution guidance, issue channels, and update information, and the skill has a stable name and description. Maintenance evidence remains limited: the selected skill has no skill-level version, changelog, named maintainer, or dedicated response commitment. The publisher is not verified by the FollowSkills enterprise registry, so no additional governance credit is assigned from publisher identity.
- Before merge, push, branch deletion, or worktree cleanup, show the current branch, uncommitted changes, unpushed commits, and target-branch state, then confirm intent.
- The test command is a placeholder; do not assume npm test, cargo test, pytest, or go test ./... is the project's actual test entry point.
- Discard has an exact confirmation step but no backup or rollback mechanism; pause for human confirmation when uncommitted changes or important commits are present.
- This is a low-confidence static review. The skill was not executed and no skill-specific test evidence was supplied.
What it does & when to use it
Turns the "the work's done, now what" step — the part that's easy to hand-wave — into an enforced sequence: verify tests actually pass first, detect whether the workspace is a normal repo, a named-branch worktree, or a detached HEAD, present the matching fixed menu, execute the chosen action, then clean up the worktree only under strict ownership rules so it never deletes a workspace some other tool is managing.
Step 1 runs the test suite and hard-stops if anything fails — no menu until tests pass. Step 2 compares GIT_DIR and GIT_COMMON to detect whether you're in a worktree and whether it's a detached HEAD. Step 3 determines the base branch to merge against. Step 4 shows a fixed set of options (merge locally / push and open a PR / keep as-is / discard — one fewer option on detached HEAD). Step 5 executes the choice: merging re-runs tests on the merged result before the source branch can be deleted, and discarding requires typing the literal word "discard" as a second confirmation. Step 6 only cleans up the worktree for the merge and discard paths, and only removes worktrees whose path sits under .worktrees/ or worktrees/ and were confirmed as created by this skill — anything the harness manages itself is left alone.
- Feature work is done and tests are green — decide between merging locally, opening a PR, keeping the branch, or discarding the change
- Finished work in an isolated branch created via `git worktree` and need to clean it up safely without leaving phantom state
- Guard against accidents: merging before tests actually pass, or deleting the worktree of a PR branch someone else is still iterating on
Pros & cons
- Hard-codes the order "verify tests, then decide next step" — prevents rushing into a merge or PR before tests actually pass
- Very cautious about worktree cleanup ownership — only removes worktrees under the conventional path and confirmed as self-created, cutting down on accidental deletion
- The discard action requires typing the exact word `discard`, a stronger guard than a generic "are you sure? (y/n)"
- Only reliably self-enforcing on harnesses that actually read and follow SKILL.md instructions (Claude Code, Codex CLI, etc.) — in a plain chat interface it's just a document a human has to apply by hand.
- Involves real git operations (merging, force-deleting branches, removing worktrees) — running it directly on a main branch without prior branch/worktree isolation raises the risk noticeably; pair it with using-git-worktrees
- The four options and test-verification requirement are hard-coded — teams with their own merge conventions (mandatory squash, mandatory CI gate) should check for conflicts with this flow first
How to install
Installed as part of the obra/superpowers plugin — individual skills can't be installed standalone:
- Claude Code: official marketplace
/plugin install superpowers@claude-plugins-official; or register the community marketplace with/plugin marketplace add obra/superpowers-marketplacethen/plugin install superpowers@superpowers-marketplace - Also supports Antigravity, Codex App/CLI, Cursor, Factory Droid, GitHub Copilot CLI, Kimi Code, OpenCode, and Pi — see the repo README for the exact command per harness
Once installed, this skill activates alongside the other 13 Superpowers skills, auto-triggered by using-superpowers based on context — there's no separate invocation step.
How to use
Automatically invoked once executing-plans or subagent-driven-development finishes all tasks. Can also be triggered manually when you decide a branch's work is done and want Claude to run the wrap-up.
Compared to similar skills
Compared to letting Claude judge "merge or not" on its own, this skill turns "which menu to show" into a deterministic check based on workspace state (normal repo / worktree / detached HEAD) instead of the model guessing the environment. Compared to running git commands by hand, it adds two hard gates: tests must be verified before merge, and ownership must be confirmed before cleanup.