Developer pack
Claude Skill
Dev Branch Finisher
Closes out a finished branch the right way — verify tests first, then present merge / PR / cleanup options and execute the choice.
What it does
Once implementation is done, runs the project's test suite first (and refuses to proceed if it fails), detects the workspace state, then presents clear integration options — merge, open a PR, keep working, or discard — and executes the chosen path including branch and worktree cleanup. Built so "done" means tested-and-integrated, not abandoned on a branch.
When to use
- ✓A feature branch is implemented and needs to be integrated
- ✓Deciding between a direct merge and opening a PR
- ✓Cleaning up branches and worktrees after the work lands
When not to use
- ✗The work isn't actually finished or tests haven't been written yet
- ✗A trivial trunk-based commit that needs no integration flow
Install
Download the .zip, then unzip into your Claude skills folder.
mkdir -p ~/.claude/skills
unzip ~/Downloads/dev-branch-finisher.zip -d ~/.claude/skills/
# Restart Claude Code session.
# Skill is now available — Claude will use it when relevant.SKILL.md
SKILL.md
---
name: dev-branch-finisher
description: Use when implementation is complete and you need to integrate the branch. Triggers on "finish this branch", "ready to merge", "open a PR", "wrap up this work", "clean up the branch/worktree".
---
# Dev Branch Finisher
Integrate finished work deliberately: verify tests pass, understand the workspace state, present the real options, execute the choice, and clean up. "Done" should mean tested-and-integrated — not left on a branch that rots.
## Step 1 — Verify tests first
Run the project's suite before anything else. If tests fail, stop — show the failures and fix them; do not present merge or PR options on a red branch. Integrating untested work is the failure this skill exists to prevent.
## Step 2 — Detect the environment
Determine the state before offering options: current branch, how far ahead/behind the base it is, whether you're in a worktree, and whether there's a remote / PR convention in this repo. The right options depend on this.
## Step 3 — Present the options
Lay out the genuine choices with their trade-offs:
- **Merge to the base branch** — when direct merge is the team's norm and review isn't required
- **Open a pull request** — when changes warrant review or the repo expects PRs
- **Keep working** — not actually done
- **Discard** — abandon the branch
Recommend based on the repo's conventions; don't force a merge where a PR was expected.
## Step 4 — Execute and Step 5 — Clean up
Carry out the chosen path. Then clean up: delete the merged branch, remove the worktree if one was used, and prune. Don't leave stale branches and worktrees accumulating.
## Anti-patterns
- Presenting merge/PR options while tests are red
- Force-merging when the repo expects a reviewed PR
- Claiming the work is done without running the suite
- Leaving merged branches and orphaned worktrees behind
- Skipping environment detection and offering options that don't fit the repo
Example prompts
Once installed, try these prompts in Claude:
- This feature branch is done. Verify the tests, then walk me through merging or opening a PR and clean up after.
- Tests pass on my branch. What's the right way to integrate this and remove the worktree?