New: 98,000+ skills indexed from GitHub repos with 100+ stars · every skill safety-checkedBrowse top skillsTop skills
Esc to closeBrowse all skills
Submit a skillBrowse skills
Submit a skillBrowse skills

Agent skill

Finishing a Development Branch

by obra in obra/superpowers

Walks the last step of a branch: confirm tests pass, detect the git environment, ask how to integrate, carry out your choice and clean up the worktree.

MITAuto-check passedDevelopment

Install Finishing a Development Branch

skills CLI
$ npx skills add obra/superpowers --skill finishing-a-development-branch -a claude-code

Project install by default; add -g for ~/.claude/skills/.

GitHub CLI
$ gh skill install obra/superpowers finishing-a-development-branch --agent claude-code

Project scope by default; add --scope user for a personal install. Needs GitHub CLI 2.90.0 or later (public preview).

Manual copy
$ git clone --depth 1 https://github.com/obra/superpowers.git skills-src && mkdir -p .claude/skills && cp -r skills-src/skills/finishing-a-development-branch .claude/skills/finishing-a-development-branch && rm -rf skills-src

Use ~/.claude/skills/ instead of .claude/skills for a personal install. The folder must contain SKILL.md.

Claude Code skills documentation · loads skills from .claude/skills/

Facts

Skill name
finishing-a-development-branch
GitHub stars
297k
Used in
5 other repos
Token cost
~1.9k tokens
SKILL.md length
821 words
Files
1
Skills in repo
4
Repo updated
First seen
Licence
MIT

At a glance

Walks the last step of a branch: confirm tests pass, detect the git environment, ask how to integrate, carry out your choice and clean up the worktree.

  • Works in 6 steps: Verify Tests → Detect Environment → Determine Base Branch → …
  • Implementation is finished and tests pass, and you need to decide how to integrate
  • SKILL.md covers Overview, Step 1: Verify Tests, Step 2: Detect Environment and Step 3: Determine Base Branch, plus 5 more sections
  • Calls git, npm and cargo

What it does

The sequence is verify tests, detect the environment, present options, execute the choice and clean up. The agent runs the project's full test suite (`npm test`, `cargo test`, `pytest` or `go test`) and stops with the failures if anything is red, so the options menu appears only after a green run. Git directory checks then tell whether this is a normal repository, a worktree on a named branch, or a worktree on a detached HEAD.

Normal repositories and named-branch worktrees get a standard three-option menu, while a detached HEAD gets a reduced two-option menu without a merge, since the workspace is managed elsewhere. The base branch is confirmed before any merge, because merging into the wrong one is costly to undo, and discarding work happens only when you explicitly ask for it. Worktree cleanup depends on where the worktree came from.

When your agent uses it

  • Implementation is finished and tests pass, and you need to decide how to integrate
  • Merging a feature branch back or pushing it for a pull request
  • Cleaning up a git worktree after the work is merged or abandoned

Example prompts

  • “The feature is done and green; help me wrap up this branch.”
  • “Merge this worktree back into main locally and clean it up afterwards.”
  • “I am on a detached HEAD in a managed workspace, so push it as a new branch and open a PR.”

Requirements

  • Git
  • A project test suite the agent can run

Workflow steps

6 steps, taken from the step headings in SKILL.md.

  1. Verify Tests
  2. Detect Environment
  3. Determine Base Branch
  4. Present Options
  5. Execute Choice
  6. Cleanup Workspace

What it can do on your machine

Read from SKILL.md and the folder at commit bb92a77. It shows what the files ask for, not the result of running them.

  • Tool permissions

    Pre-approves nothing: there is no allowed-tools line, so your agent's usual permission prompts apply.

    From allowed-tools in the SKILL.md frontmatter.

  • Runs code

    Shell commands in SKILL.md call:

    • git
    • npm
    • cargo
    • go

    From the folder's file list and the shell code blocks in SKILL.md.

  • Network

    No URLs in SKILL.md. Its commands use git and npm, which can reach the network depending on how they are called.

    From URLs in SKILL.md, links to its own repository left out.

  • Credentials

    Names no API keys, tokens, secrets or passwords.

    From names ending in _API_KEY, _TOKEN, _SECRET, _KEY or _PASSWORD in SKILL.md.

Context cost

Finishing a Development Branch loads about 1.9k tokens when it runs. Until then it costs about 33 tokens; SKILL.md has 821 words of instructions outside code blocks.

Always · name and description, kept in context so the agent knows when to use it
~33
When it runs · the whole SKILL.md, loaded when a task matches
~1.9k

Estimates: characters ÷ 4, the usual rule of thumb; real counts depend on the model's tokenizer. Scripts and assets cost tokens only if the agent reads them.

Safety

Auto-check passed

The automated check found no risky patterns in SKILL.md.

Automated static check — not a guarantee. Review scripts before installing. It scans the text of SKILL.md for risky patterns (piping downloads into a shell, reading credential files, hidden Unicode, destructive commands); files beside SKILL.md are not scanned.

SKILL.md

The full file from obra/superpowers at commit bb92a77, republished under its MIT licence (© obra). 821 words, ~1,933 tokens.

Download SKILL.mdSave it as .claude/skills/finishing-a-development-branch/SKILL.md (or your agent's skills folder).
name
finishing-a-development-branch
description
Use when implementation is complete, all tests pass, and you need to decide how to integrate the work

Finishing a Development Branch

Overview

Core principle: Verify tests → Detect environment → Present options → Execute choice → Clean up.

Announce at start: "I'm using the finishing-a-development-branch skill to complete this work."

Step 1: Verify Tests

Run the project's full test suite (npm test / cargo test / pytest / go test ./...).

If tests fail, report the failures and stop — the menu comes after a green suite:

Tests failing (<N> failures). Must fix before completing:

[Show failures]

If tests pass: continue to Step 2.

Step 2: Detect Environment

bash
GIT_DIR=$(cd "$(git rev-parse --git-dir)" 2>/dev/null && pwd -P)
GIT_COMMON=$(cd "$(git rev-parse --git-common-dir)" 2>/dev/null && pwd -P)
# Capture now, while still inside the workspace — Step 5 changes directory
# before cleanup (Step 6) needs this value
WORKTREE_PATH=$(git rev-parse --show-toplevel)

This determines which menu to show and how cleanup works:

StateMenuCleanup
GIT_DIR == GIT_COMMON (normal repo)Standard 3 optionsNo worktree to clean up
GIT_DIR != GIT_COMMON, named branchStandard 3 optionsProvenance-based (see Step 6)
GIT_DIR != GIT_COMMON, detached HEADReduced 2 options (no merge)Externally managed — leave in place

Step 3: Determine Base Branch

The base branch is whatever this work forked from — usually named in the plan, the conversation, or the branch's upstream. If it is not already known, ask: "This branch split from <your best guess> - is that correct?" Confirm before merging: merging into the wrong base is expensive to undo.

Step 4: Present Options

Normal repo and named-branch worktree — present exactly these 3 options:

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)

Which option?

Detached HEAD — present exactly these 2 options:

Implementation complete. You're on a detached HEAD (externally managed workspace).

1. Push as new branch and create a Pull Request
2. Keep as-is (I'll handle it later)

Which option?

Present the menu exactly as written — concise, with every option coming from the list above. Discarding the work happens only in response to your human partner explicitly asking for it (see "If your human partner asks to discard the work" below). Wait for their answer; the integration decision is theirs.

Step 5: Execute Choice

Option 1: Merge Locally
bash
# Get main repo root for CWD safety
MAIN_ROOT=$(git -C "$(git rev-parse --git-common-dir)/.." rev-parse --show-toplevel)
cd "$MAIN_ROOT"

# Merge first — verify success before removing anything
git checkout <base-branch>
git pull
git merge <feature-branch>

# Verify tests on merged result
<test command>

If tests fail on the merged result: stop, leave the worktree and branch in place, and investigate — nothing has been pushed, so the merge is local and recoverable.

Once the merged result is green: clean up the worktree (Step 6), then delete the branch:

bash
git branch -d <feature-branch>
Option 2: Push and Create PR
bash
git push -u origin <feature-branch>
# From a detached HEAD, name the new branch on the remote:
# git push origin HEAD:refs/heads/<new-branch>

Then create the pull/merge request against <base-branch> with the forge's tooling — its CLI if one is available, or the creation URL most forges print when you push — following the repo's PR template and conventions if present, and report the URL to your human partner.

Keep the worktree — your human partner iterates on PR feedback there.

Option 3: Keep As-Is

Report: "Keeping branch <name>. Worktree preserved at <path>."

If your human partner asks to discard the work

This path exists only as a response to an explicit request to throw the work away. Confirm first:

This will permanently delete:
- Branch <name>
- All commits: <commit-list>
- Worktree at <path>

Type 'discard' to confirm.

Wait for that exact confirmation. When it arrives:

bash
MAIN_ROOT=$(git -C "$(git rev-parse --git-common-dir)/.." rev-parse --show-toplevel)
cd "$MAIN_ROOT"

Then clean up the worktree (Step 6) and force-delete the branch:

bash
git branch -D <feature-branch>

Step 6: Cleanup Workspace

Runs for Option 1 and confirmed discards. Options 2 and 3 always preserve the worktree. Both callers have already changed directory to the main repo root — worktree removal must run from outside the worktree — and use the GIT_DIR/GIT_COMMON/WORKTREE_PATH values captured in Step 2, from before that directory change.

If GIT_DIR == GIT_COMMON: Normal repo, no worktree to clean up. Done.

If WORKTREE_PATH is under .worktrees/ or worktrees/: Superpowers created this worktree — we own cleanup:

bash
git worktree remove "$WORKTREE_PATH"
git worktree prune  # Self-healing: clean up any stale registrations

If removal is refused (contains modified or untracked files): the worktree holds files that exist nowhere else — uncommitted plans, notes, or scratch work. Never --force on your own initiative. Show your human partner what is at stake and ask:

bash
git -C "$WORKTREE_PATH" status --porcelain -uall
Worktree removal refused — these files were never committed:

<file list>

1. Commit them to <branch> before cleanup
2. Move them into <main repo root>
3. Delete them (unrecoverable)

Which?

Carry out the choice, then remove the worktree.

Otherwise: The host environment owns this workspace — leave it in place. If your platform provides a workspace-exit tool, use it.

Show full SKILL.md (259 more words)Show less

Quick Reference

OptionMergePushKeep WorktreeCleanup Branch
1. Merge locallyyes--yes
2. Create PR-yesyes-
3. Keep as-is--yes-
Discard (explicit request only)---yes (force)

Common Rationalizations

ExcuseReality
"Tests passed earlier this session"Run the suite on the tree you are about to integrate. A green run only proves the tree it ran on.
"They obviously want it merged"Integration is your human partner's decision. Present the menu and wait.
"They seem done with this feature — I'll offer to discard it"The menu is complete as written. Discard happens only when your human partner asks for it in so many words.
"'Yeah, get rid of it' counts as confirmation"Only the typed word discard authorizes deletion.
"The PR is up, so the worktree is clutter now"PR feedback gets fixed in that worktree. It stays until the work lands.
"This other worktree looks stale — I'll clean it too"Clean up only worktrees under .worktrees/ or worktrees/. Everything else belongs to the host.
"Removal refused — --force is just finishing the cleanup"The refusal means files exist only in that worktree. --force destroys them permanently. Show your human partner and ask.
"The merged-result failure is probably flaky"A failing merged result stops everything. Branch and worktree stay put while you investigate.
"The base branch is obviously main"Confirm the fork point or ask. Merging into the wrong base is expensive to undo.
"The push was rejected — force-push will fix it"A rejected push means the remote moved. Investigate; force-push only on your human partner's explicit request.

© obra, MIT. Rendered from Markdown: HTML in the file is shown as text, images as links, and headings moved down two levels. Raw file

Files

Just SKILL.md in skills/finishing-a-development-branch of obra/superpowers.

Open the folder on GitHubat commit bb92a77

Used in 5 other repositories

We found 6 copies of this SKILL.md (exact, near-identical or edited) in other folders, from 5 other GitHub owners. This page covers the copy in obra/superpowers, which our catalogue first saw on October 7, 2026.

Compare with similar skills

Finishing a Development Branch next to the 5 skills that share the most tags, products or categories with it. Stars are the repository's; “used in” counts other GitHub owners with a copy.

Finishing a Development Branch compared with similar skills
SkillStarsUsed inTokensAuto-checkLicenceRepo updated
Finishing a Development Branch this skillobra/superpowers297k5 repos~1.9kAutomated safety check: PassMIT
Clean Complete Branchesjtenniswood/espcontrol1.1k—~820Automated safety check: PassCustom licence
Squad Git Branching Workflowmicrosoft/waza1.4k4 repos~1.5kAutomated safety check: PassMIT
Git WorkflowEliasOulkadi/shokunin114—~2.4kAutomated safety check: NotesMIT
Contributor-First PR MergeHKUDS/OpenHarness16k1 repos~847Automated safety check: PassMIT
Create Pull Requestcline/cline70k1 repos~1.6kAutomated safety check: PassApache-2.0

Similar skills

  • Clean Complete Branches

    jtenniswood/espcontrol

    Clean up completed Git branches and worktrees for this repository both locally and on GitHub.

    1.1k GitHub stars~820 tokensUpdated yesterday
    DevelopmentAuto-check passed

  • Squad Git Branching Workflow

    microsoft/waza

    Official

    Dev-first branching model for the Squad project: feature work branches from dev, issue branches follow a naming rule and parallel issues use git worktrees.

    1.4k GitHub starsUsed in 4 repos~1.5k tokens
    DevelopmentAuto-check passed

  • Git Workflow

    EliasOulkadi/shokunin

    Automate the complete Git development workflow — create feature branches with conventional naming, atomic commits with conventional commit messages, interactive rebase, squash merges, PR body…

    114 GitHub stars~2.4k tokensUpdated 5 days ago
    DevelopmentAuto-check: notes

  • Contributor-First PR Merge

    HKUDS/OpenHarness

    Merges external GitHub pull requests while keeping the original author credited, and fixes conflicts after the merge instead of rewriting the contribution.

    16k GitHub starsUsed in 1 repo~847 tokens
    DevelopmentAuto-check passed

  • Create Pull Request

    cline/cline

    Opens a GitHub pull request from your current branch with the gh CLI, after reviewing the commits and diff and gathering the details the PR needs.

    70k GitHub starsUsed in 1 repo~1.6k tokens
    DevelopmentAuto-check passed

  • Git Branch Naming

    makeplane/plane

    Names a new Git branch with a type prefix, the lowercased work item ID and a short kebab-case description, so the ID can be extracted later from the branch name.

    61k GitHub stars~594 tokensUpdated yesterday
    DevelopmentAuto-check passed

More from obra/superpowers

  • Executing Plans Inline

    obra/superpowers

    Has the agent carry out an implementation plan itself, task by task in the current session, keeping a ledger, proving each step with a test and ending with one whole-branch review.

    297k GitHub starsUsed in 2 repos~5.1k tokens
    Auto-check passed

  • Diagnosing Superpowers Sessions

    obra/superpowers

    Investigates a session where Superpowers went wrong, reads the transcripts on disk and produces an evidence-cited report, optionally prepared as a bug report for the maintainers.

    297k GitHub starsUsed in 3 repos~1.7k tokens
    Auto-check passed

  • Brainstorming

    obra/superpowers

    Makes the agent clarify intent and agree on a design with you before writing any code, scaling the process from a quick spike to a written spec.

    297k GitHub starsUsed in 1 repo~2.5k tokens
    Auto-check passed

Works with

Categories

Questions about Finishing a Development Branch

What does Finishing a Development Branch do?

Walks the last step of a branch: confirm tests pass, detect the git environment, ask how to integrate, carry out your choice and clean up the worktree. The sequence is verify tests, detect the environment, present options, execute the choice and clean up. The agent runs the project's full test suite (`npm test`, `cargo test`, `pytest` or `go test`) and stops with the failures if anything is red, so the options menu appears only after a green run.

When should I use Finishing a Development Branch?

Finishing a Development Branch fits situations like: implementation is finished and tests pass, and you need to decide how to integrate; merging a feature branch back or pushing it for a pull request; cleaning up a git worktree after the work is merged or abandoned.

How do I install Finishing a Development Branch in Claude Code?

Run `npx skills add obra/superpowers --skill finishing-a-development-branch -a claude-code`. Or copy the skill folder (skills/finishing-a-development-branch in obra/superpowers) into .claude/skills/finishing-a-development-branch in your project. Claude Code loads it when a task matches its description.

How do I install Finishing a Development Branch in Codex?

Run `npx skills add obra/superpowers --skill finishing-a-development-branch -a codex`. Or copy the skill folder (skills/finishing-a-development-branch in obra/superpowers) into .agents/skills/finishing-a-development-branch in your project. Codex loads it when a task matches its description.

Can I use Finishing a Development Branch in Cursor, Gemini CLI or GitHub Copilot?

Cursor, Gemini CLI, GitHub Copilot and OpenCode also load SKILL.md folders. With the skills CLI, run `npx skills add obra/superpowers --skill finishing-a-development-branch -a cursor` (or -a gemini-cli, github-copilot or opencode for the others). To copy it by hand, put the folder in .cursor/skills/finishing-a-development-branch, .gemini/skills/finishing-a-development-branch, .github/skills/finishing-a-development-branch and .opencode/skills/finishing-a-development-branch in your project.

What does Finishing a Development Branch need to run?

Going by SKILL.md and its folder, Finishing a Development Branch needs the command-line tools its instructions call (git, npm, cargo and go). Our summary lists: Git; A project test suite the agent can run.

Does Finishing a Development Branch access the network?

SKILL.md contains no URLs. Its commands use git and npm, which can reach the network depending on how they are called. This is read from the text; nothing was executed.

Is Finishing a Development Branch safe to install?

Our automated static check of SKILL.md found no risky patterns, such as piping downloads into a shell, reading credential files or hidden Unicode. It is not a guarantee. Review the folder before installing.

What licence does Finishing a Development Branch use?

Finishing a Development Branch is published under the MIT licence (the repository's licence). It allows redistribution, so the full SKILL.md is shown on this page.

How many tokens does Finishing a Development Branch use?

About 1.9k tokens (SKILL.md is roughly 7.7k characters). Agents keep only the skill's name and description in context until a task matches; then they load SKILL.md in full.

What are the alternatives to Finishing a Development Branch?

Skills that share tags, products or a category with Finishing a Development Branch: Clean Complete Branches (jtenniswood/espcontrol, 1.1k stars), Squad Git Branching Workflow (microsoft/waza, 1.4k stars), Git Workflow (EliasOulkadi/shokunin, 114 stars) and Contributor-First PR Merge (HKUDS/OpenHarness, 16k stars). The comparison table on this page puts their stars, adoption, token cost, safety result and licence side by side.

Who maintains Finishing a Development Branch?

obra (a GitHub user) maintains it in obra/superpowers, which has 296,980 GitHub stars. The repository holds 4 skills in this directory. The repository was last updated on October 10, 2026.

Source: obra/superpowers on GitHub. Facts on this page come from the repository at the commit we read; the author's words are quoted as theirs.