Use when implementation is complete, all tests pass, and you need to decide how to integrate the work.
Collected from public GitHub. Every version is saved exactly as it was and never changes. Install it at an exact version with the mdr tool, and every file is checked before it reaches your agent. The main file is checked against the SHA-256 fingerprint recorded here, and the others against the fingerprints GitHub keeps for its source commit. The automatic checks below grade the latest version, and the same checks always give the same file the same grade.
What the file says
# 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:
| State | Menu | Cleanup |
|-------|------|---------|
| `GIT_DIR == GIT_COMMON` (normal repo) | Standard 3 options | No worktree to clean up |
…
The line at the top of this page pins the label v1.0.1, which is what most people want. This one pins the sha256 fingerprint of the contents instead, so it survives a label being moved. Either way the exact version is written to mdr.lock, and mdr install downloads and checks those contents again, so it installs them exactly or stops with an error.
GET https://markdownregistry.com/api/v1/artifacts/art_j6wiylc6ecjgg7i7
GET https://markdownregistry.com/api/v1/resolve?ref=sodiumjoe/dotfiles/finishing-a-development-branch
GET https://markdownregistry.com/api/v1/blob/44cfb23e88af8c75c851e29f99a46515bb97841039811697b45b307ef5105faa
Your AI assistant does the legwork. You hear about the deals worth your word. Hand yours the standing instructions at modelranch.com and it joins the network that reads files like this one.
sodiumjoe/dotfiles · home/.agents/skills/brainstorming/SKILL.md · You MUST use this before any creative work - creating features, building components, adding functionality, or modifying…
sodiumjoe/dotfiles · home/.agents/skills/dispatching-parallel-agents/SKILL.md · Use when facing 2+ independent tasks that can be worked on without shared state or sequential dependencies
sodiumjoe/dotfiles · home/.agents/skills/executing-plans/SKILL.md · Use when executing an implementation plan in the current session as the implementer yourself — your human partner chose…
sodiumjoe/dotfiles · home/.agents/skills/neovim-review/SKILL.md · Use when the user invokes /neovim-review for a pull request or a local :Review session in Neovim.
sodiumjoe/dotfiles · home/.agents/skills/neovim/SKILL.md · Interact with a running neovim instance over RPC — open files, show diffs, execute Lua. Use when you need to open a…
sodiumjoe/dotfiles · home/.agents/skills/receiving-code-review/SKILL.md · Use when receiving code review feedback, before implementing suggestions, especially if feedback seems unclear or…
sodiumjoe/dotfiles · home/.agents/skills/requesting-code-review/SKILL.md · Use when completing tasks, implementing major features, or before merging to verify work meets requirements
sodiumjoe/dotfiles · home/.agents/skills/subagent-driven-development/SKILL.md · Use when executing implementation plans with independent tasks in the current session
sodiumjoe/dotfiles · home/.agents/skills/systematic-debugging/SKILL.md · Use when encountering any bug, test failure, or unexpected behavior, before proposing fixes
sodiumjoe/dotfiles · home/.agents/skills/test-driven-development/SKILL.md · Use when implementing any feature or bugfix, before writing implementation code
sodiumjoe/dotfiles · home/.agents/skills/using-git-worktrees/SKILL.md · Use when starting feature work that needs isolation from current workspace or before executing implementation plans -…
obra/superpowers · skills/finishing-a-development-branch/SKILL.md · Use when implementation is complete, all tests pass, and you need to decide how to integrate the work
a5c-ai/babysitter · library/methodologies/superpowers/skills/finishing-a-development-branch/SKILL.md · Use when implementation is complete, all tests pass, and you need to decide how to integrate the work.
ganyuanran/aegis · skills/finishing-a-development-branch/SKILL.md · Use when verified work needs integration or cleanup of an existing task-created branch/worktree, or the user explicitly…
coco-research/coco · skills/finishing-a-development-branch/SKILL.md · Use when implementation is done and tests pass and the user must choose to merge locally, open a PR, keep the branch…
xu123-bob/baize · agent/skills/superpowers/5.1.0/skills/finishing-a-development-branch/SKILL.md · Use when implementation is complete, all tests pass, and you need to decide how to integrate the work - guides…
jamditis/claude-skills-journalism · superjawn/skills/finishing-a-development-branch/SKILL.md · Presents options for merge, PR, or cleanup. Use when work is complete, tests pass, and you must decide how to integrate.
ibrahim-3d/orchestrator-supaconductor · skills/finishing-a-development-branch/SKILL.md · Use when implementation is complete, all tests pass, and you need to decide how to integrate the work - guides…