The Branch That Never Lands: Why Finishing Is a Skill You Have to Learn Separately

I have a folder of branches I'm not proud of.

Branches named feat/user-auth-v2 and refactor/query-cleanup and fix/edge-case-handling. Some of them are six months old. All of them have tests that were passing when I last touched them. None of them have gone anywhere.

The work is done. The work just isn't done.

The Invisible Phase

There's a phase of software development that gets very little attention compared to the phases before it.

We have rituals for starting. We have skills for writing plans, brainstorming architecture, setting up test harnesses. We have rituals for implementation — TDD, code review, pair programming. But finishing — the specific act of taking completed work and deciding what to do with it — gets treated as administrative overhead. A few git commands. A PR title. Not worth thinking about carefully.

The finishing-a-development-branch skill from obra/superpowers disagrees. It treats finishing as a distinct phase with its own protocol, and the more I've used it, the more that feels obviously right.

What Finishing Actually Requires

The skill starts with a verification step that sounds trivially obvious until you've shipped enough branches without it.

Run your tests. Before anything else. Not because you don't trust your own work, but because the act of "implementation complete" in your head and the state of the test suite are often subtly different things. The last push might have introduced a regression. The environment might have drifted. The tests might be testing slightly different behavior than you remember.

If tests fail, the skill stops. It doesn't ask you which of the four completion paths you want to take. It shows you the failures and says: this comes first.

That constraint matters more than it looks. Without it, the natural tendency is to push anyway, open the PR, and plan to fix the tests in a follow-up. Which is how "implementation complete" becomes "mostly complete" becomes a branch that drifts for six months.

Four Paths, Not One

Once tests pass, the skill presents four explicit options: merge locally, push and create a PR, keep the branch for later, or discard the work.

The fact that there are four options is itself the point.

Most developers default to one path — usually "push and create PR" — regardless of what the work actually calls for. A small cleanup to an internal utility probably doesn't need a PR. An experimental branch that didn't pan out deserves an explicit decision to discard, not an implicit one made by walking away from it.

Making the choice explicit, at the moment of completion, when the context is fresh and the options are clear, produces better outcomes than the default. The work either lands correctly or gets consciously set aside.

The discard path has deliberate friction. You have to type "discard" to confirm. This isn't busywork — it's a safeguard against the ambiguity of a branch that got abandoned without a decision. The skill forces a yes or a no. Stale branches accumulate when neither happens.

Worktree Cleanup as Closing the Loop

The skill pairs with using-git-worktrees and handles cleanup based on which path you chose. Merge locally or discard — clean up the worktree. Create a PR — keep it until the PR merges. Keep the branch — don't touch anything.

This matters if you work with worktrees regularly, but it also matters as a metaphor. Finishing means cleaning up after yourself, not just shipping. The branch is integrated, the worktree is removed, the local state matches the intended state. The work is complete in a way that doesn't leave residue.

The Mindset the Skill Is Building

What I find most useful about this protocol isn't any individual step. It's that it treats finishing as something that requires deliberate attention, not just the natural end of implementation.

Most engineers feel done when the tests are green and the logic is sound. The skill argues that done means integrated, cleaned up, and consciously decided upon. Those are different states, and the distance between them is where abandoned branches live.

I now think of finishing a development branch as its own cognitive mode. Not the same as implementation. A separate set of decisions with its own criteria for success.

Green tests mean the work is ready. Finishing means the work is actually done.

Part of the Superpowers series — 14 specialist skills from obra/superpowers.