Finishes a development branch

Finishing a development branch

by obra · MIT license · ★ 289,792 on GitHub · updated Sep 20

Finishing a development branch cover

Use when implementation is complete, all tests pass, and you need to decide how to integrate the work

---
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:

Overview

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

Manual install (npx, ZIP)
Claude Codenpx skills add obra/superpowers --skill finishing-a-development-branch -g -a claude-code
Claude Code (manual)mkdir -p ~/.claude/skills && curl -sL https://codeload.github.com/obra/superpowers/tar.gz/5bf4e7801107 \ | tar -xz -C ~/.claude/skills --strip-components=2 superpowers-5bf4e7801107/skills/finishing-a-development-branch
Windows (PowerShell)New-Item -ItemType Directory -Force "$HOME\.claude\skills" | Out-Null; Invoke-WebRequest "https://m.agentalley.io/zip/7a68cc92839ebeeca6b7/finishing-a-development-branch.zip" -OutFile "$env:TEMP\finishing-a-development-branch.zip"; Expand-Archive "$env:TEMP\finishing-a-development-branch.zip" -DestinationPath "$HOME\.claude\skills" -Force
Claude.ai / desktopDownload the ZIP and upload it under Settings → Capabilities → Skills.
Codex, Cursor, other agentsPoint them at SKILL.md. The other files are plain text.

Connects with Agent Alley MCP · agentalley.io/mcp

Files included

  • SKILL.md7.6 KB
Read the files here
obra/5bf4e781 file
SKILL.md
Show the full text226 lines

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

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:

State Menu Cleanup
GIT_DIR == GIT_COMMON (normal repo) Standard 3 options No worktree to clean up
GIT_DIR != GIT_COMMON, named branch Standard 3 options Provenance-based (see Step 6)
GIT_DIR != GIT_COMMON, detached HEAD Reduced 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
# 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:

git branch -d <feature-branch>
Option 2: Push and Create PR
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:

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:

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:

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:

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.

Quick Reference

Option Merge Push Keep Worktree Cleanup Branch
1. Merge locally yes - - yes
2. Create PR - yes yes -
3. Keep as-is - - yes -
Discard (explicit request only) - - - yes (force)

Common Rationalizations

Excuse Reality
"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.
1---
2name: finishing-a-development-branch
3description: Use when implementation is complete, all tests pass, and you need to decide how to integrate the work
4---
5 
6# Finishing a Development Branch
7 
8## Overview
9 
10**Core principle:** Verify tests → Detect environment → Present options → Execute choice → Clean up.
11 
12**Announce at start:** "I'm using the finishing-a-development-branch skill to complete this work."
13 
14## Step 1: Verify Tests
15 
16Run the project's full test suite (`npm test` / `cargo test` / `pytest` / `go test ./...`).
17 
18**If tests fail**, report the failures and stop — the menu comes after a green suite:
19 
20```
21Tests failing (<N> failures). Must fix before completing:
22 
23[Show failures]
24```
25 
26**If tests pass:** continue to Step 2.
27 
28## Step 2: Detect Environment
29 
30```bash
31GIT_DIR=$(cd "$(git rev-parse --git-dir)" 2>/dev/null && pwd -P)
32GIT_COMMON=$(cd "$(git rev-parse --git-common-dir)" 2>/dev/null && pwd -P)
33# Capture now, while still inside the workspace — Step 5 changes directory
34# before cleanup (Step 6) needs this value
35WORKTREE_PATH=$(git rev-parse --show-toplevel)
36```
37 
38This determines which menu to show and how cleanup works:
39 
40| State | Menu | Cleanup |
41|-------|------|---------|
42| `GIT_DIR == GIT_COMMON` (normal repo) | Standard 3 options | No worktree to clean up |
43| `GIT_DIR != GIT_COMMON`, named branch | Standard 3 options | Provenance-based (see Step 6) |
44| `GIT_DIR != GIT_COMMON`, detached HEAD | Reduced 2 options (no merge) | Externally managed — leave in place |
45 
46## Step 3: Determine Base Branch
47 
48The base branch is whatever this work forked from — usually named in the
49plan, the conversation, or the branch's upstream. If it is not already
50known, ask: "This branch split from <your best guess> - is that correct?"
51Confirm before merging: merging into the wrong base is expensive to undo.
52 
53## Step 4: Present Options
54 
55**Normal repo and named-branch worktree — present exactly these 3 options:**
56 
57```
58Implementation complete. What would you like to do?
59 
601. Merge back to <base-branch> locally
612. Push and create a Pull Request
623. Keep the branch as-is (I'll handle it later)
63 
64Which option?
65```
66 
67**Detached HEAD — present exactly these 2 options:**
68 
69```
70Implementation complete. You're on a detached HEAD (externally managed workspace).
71 
721. Push as new branch and create a Pull Request
732. Keep as-is (I'll handle it later)
74 
75Which option?
76```
77 
78Present the menu exactly as written — concise, with every option coming
79from the list above. Discarding the work happens only in response to your
80human partner explicitly asking for it (see "If your human partner asks to
81discard the work" below). Wait for their answer; the integration decision
82is theirs.
83 
84## Step 5: Execute Choice
85 
86### Option 1: Merge Locally
87 
88```bash
89# Get main repo root for CWD safety
90MAIN_ROOT=$(git -C "$(git rev-parse --git-common-dir)/.." rev-parse --show-toplevel)
91cd "$MAIN_ROOT"
92 
93# Merge first — verify success before removing anything
94git checkout <base-branch>
95git pull
96git merge <feature-branch>
97 
98# Verify tests on merged result
99<test command>
100```
101 
102If tests fail on the merged result: stop, leave the worktree and branch in
103place, and investigate — nothing has been pushed, so the merge is local
104and recoverable.
105 
106Once the merged result is green: clean up the worktree (Step 6), then
107delete the branch:
108 
109```bash
110git branch -d <feature-branch>
111```
112 
113### Option 2: Push and Create PR
114 
115```bash
116git push -u origin <feature-branch>
117# From a detached HEAD, name the new branch on the remote:
118# git push origin HEAD:refs/heads/<new-branch>
119```
120 
121Then create the pull/merge request against <base-branch> with the forge's
122tooling — its CLI if one is available, or the creation URL most forges
123print when you push — following the repo's PR template and conventions if
124present, and report the URL to your human partner.
125 
126Keep the worktree — your human partner iterates on PR feedback there.
127 
128### Option 3: Keep As-Is
129 
130Report: "Keeping branch <name>. Worktree preserved at <path>."
131 
132### If your human partner asks to discard the work
133 
134This path exists only as a response to an explicit request to throw the
135work away. Confirm first:
136 
137```
138This will permanently delete:
139- Branch <name>
140- All commits: <commit-list>
141- Worktree at <path>
142 
143Type 'discard' to confirm.
144```
145 
146Wait for that exact confirmation. When it arrives:
147 
148```bash
149MAIN_ROOT=$(git -C "$(git rev-parse --git-common-dir)/.." rev-parse --show-toplevel)
150cd "$MAIN_ROOT"
151```
152 
153Then clean up the worktree (Step 6) and force-delete the branch:
154 
155```bash
156git branch -D <feature-branch>
157```
158 
159## Step 6: Cleanup Workspace
160 
161**Runs for Option 1 and confirmed discards.** Options 2 and 3 always
162preserve the worktree. Both callers have already changed directory to the
163main repo root — worktree removal must run from outside the worktree —
164and use the `GIT_DIR`/`GIT_COMMON`/`WORKTREE_PATH` values captured in
165Step 2, from before that directory change.
166 
167**If `GIT_DIR == GIT_COMMON`:** Normal repo, no worktree to clean up. Done.
168 
169**If `WORKTREE_PATH` is under `.worktrees/` or `worktrees/`:** Superpowers
170created this worktree — we own cleanup:
171 
172```bash
173git worktree remove "$WORKTREE_PATH"
174git worktree prune # Self-healing: clean up any stale registrations
175```
176 
177**If removal is refused** (`contains modified or untracked files`): the
178worktree holds files that exist nowhere else — uncommitted plans, notes,
179or scratch work. Never `--force` on your own initiative. Show your human
180partner what is at stake and ask:
181 
182```bash
183git -C "$WORKTREE_PATH" status --porcelain -uall
184```
185 
186```
187Worktree removal refused — these files were never committed:
188 
189<file list>
190 
1911. Commit them to <branch> before cleanup
1922. Move them into <main repo root>
1933. Delete them (unrecoverable)
194 
195Which?
196```
197 
198Carry out the choice, then remove the worktree.
199 
200**Otherwise:** The host environment owns this workspace — leave it in
201place. If your platform provides a workspace-exit tool, use it.
202 
203## Quick Reference
204 
205| Option | Merge | Push | Keep Worktree | Cleanup Branch |
206|--------|-------|------|---------------|----------------|
207| 1. Merge locally | yes | - | - | yes |
208| 2. Create PR | - | yes | yes | - |
209| 3. Keep as-is | - | - | yes | - |
210| Discard (explicit request only) | - | - | - | yes (force) |
211 
212## Common Rationalizations
213 
214| Excuse | Reality |
215|--------|---------|
216| "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. |
217| "They obviously want it merged" | Integration is your human partner's decision. Present the menu and wait. |
218| "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. |
219| "'Yeah, get rid of it' counts as confirmation" | Only the typed word `discard` authorizes deletion. |
220| "The PR is up, so the worktree is clutter now" | PR feedback gets fixed in that worktree. It stays until the work lands. |
221| "This other worktree looks stale — I'll clean it too" | Clean up only worktrees under `.worktrees/` or `worktrees/`. Everything else belongs to the host. |
222| "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. |
223| "The merged-result failure is probably flaky" | A failing merged result stops everything. Branch and worktree stay put while you investigate. |
224| "The base branch is obviously main" | Confirm the fork point or ask. Merging into the wrong base is expensive to undo. |
225| "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. |
226 
View all files on GitHub →

Details

Updated
Sep 20, 2026
License
MIT
Stars on the repo
★ 289,792
Checked
Source
obra/superpowers ↗
Creator
obra · 14 listings
View creator

Similar skills

See all →
SkillAutomates CI/CD pipeline setupCI/CD and Automationaddyosmani/agent-skills · by addyosmaniAutomates CI/CD pipeline setup. Use when setting up or modifying build and deployment pipelines. Use when you need to automate quality gates, configure test runners in CI, or establish deployment strategies.★ 98.7k GitHub starsSkillAutomated semantic versioning and release workflowVersion Bump & Release Workflowthedotmack/claude-mem · by thedotmackAutomated semantic versioning and release workflow for Claude Code plugins. Handles version increments across package.json, marketplace.json, plugin.json manifests, build verification, git tagging, GitHub releases, and changelog generation. NPM publishing is the final human-required handoff because the maintainer raised npm security.★ 95.6k GitHub starsSkillOperate Orca-managed worktrees, folder contexts, terminalsOrca CLIstablyai/orca · by stablyaiOperate Orca-managed worktrees, folder contexts, terminals, repos, automations, artifacts, skill sharing, worktree comments, and Orca's embedded browser through the `orca` CLI. Use when the user says "$orca-cli", "Orca worktree", "child worktree", "spawn codex/claude in a worktree", "read/wait/send Orca terminal", "handoff" / "handover" / "give this to another agent", "Orca browser", "orca artifacts", or "share skills". Prefer it over raw git worktree, ad hoc PTYs, or Computer Use when Orca state is involved. Use Computer Use only when a visible window needs GUI control that a CLI, filesystem, or API cannot do.★ 84.5k GitHub starsSkillThreaded messages, blocking ask/reply, task dispatchOrca Orchestrationstablyai/orca · by stablyaiCoordinate supervised Orca workers: threaded messages, blocking ask/reply, task dispatch, worker_done/escalation waits, task DAGs, decision gates, coordinator loops, and decomposing work across agents. Use `orca-cli` for full ownership handoffs — "hand off", "handoff", "handover", "give this to another agent", "another worktree" — unless asked to supervise, monitor, or coordinate a DAG, and for terminal control, lightweight terminal prompts, shell commands, Orca worktree management, and reading or waiting on terminals.★ 84.5k GitHub starsSkillDeploy applications and websites to VercelVercel deploybytedance/deer-flow · by bytedanceDeploy applications and websites to Vercel. Use this skill when the user requests deployment actions such as "Deploy my app", "Deploy this to production", "Create a preview deployment", "Deploy and give me the link", or "Push this live". No authentication required - returns preview URL and claimable deployment link.★ 83.5k GitHub starsSkillOpen or update a pull request on pascalorg/editorOpen PRpascalorg/editor · by pascalorgOpen or update a pull request on pascalorg/editor from the current branch, describing only what the branch actually did. Use when the user asks to open/create a PR, push and PR, or ship a branch in the editor repo.★ 24.6k GitHub stars

More from obra

SkillBrainstorms ideas into designs before any creative workBrainstorming Ideas Into Designsobra/superpowers · by obraYou MUST use this before any creative work - creating features, building components, adding functionality, or modifying behavior. Explores user intent, requirements and design before implementation.★ 290k GitHub starsSkillRequires technical rigor and verificationCode Review Receptionobra/superpowers · by obraUse when receiving code review feedback, before implementing suggestions, especially if feedback seems unclear or technically questionable - requires technical rigor and verification, not performative agreement or blind implementation★ 290k GitHub starsSkillDispatches parallel agentsDispatching parallel agentsobra/superpowers · by obraUse when facing 2+ independent tasks that can be worked on without shared state or sequential dependencies★ 290k GitHub starsSkillExecutes plans with review checkpointsExecuting plansobra/superpowers · by obraUse when you have a written implementation plan to execute in a separate session with review checkpoints★ 290k GitHub starsSkillRequests code review before mergingRequesting code reviewobra/superpowers · by obraUse when completing tasks, implementing major features, or before merging to verify work meets requirements★ 290k GitHub starsSkillExecuting implementation plans with independent tasksSubagent driven developmentobra/superpowers · by obraUse when executing implementation plans with independent tasks in the current session★ 290k GitHub stars