Finishing a Development Branch

What it does

Finishing work requires more than a green message from an implementation agent. This skill reruns the project suite, detects normal checkout versus named or detached worktree state, and confirms the correct base branch. Named branches can be merged locally, pushed for a pull request or kept; detached workspaces use a reduced handoff that avoids assuming a local merge destination. Discarding work is separate and requires an explicit request plus confirmation. Cleanup depends on workspace ownership, not merely whether the feature looks finished.

When to use it

• Turn a completed feature into a reviewable pull request.
• Integrate a tested branch into the correct local base and test the merged result.
• Keep an externally managed detached checkout intact for a later review.

Step-by-step workflow

1. Run the full project suite on the tree being handed off and stop integration if it fails.
2. Record the worktree path and Git metadata before any directory changes; establish the actual base branch.
3. Present the integration options appropriate to branch state and obtain the user’s choice.
4. Perform the selected merge, pull-request push or keep action; verify a merged tree before cleanup.
5. Remove only workflow-owned eligible worktrees after success, preserving uncommitted files and externally managed workspaces.

Example request

Use finishing-a-development-branch for the completed export feature. Run the project tests again and confirm the feature’s base from history. Show the correct choices for this checkout’s branch state. If I select a pull request, include the verified behavior and tests and preserve the checkout for review feedback. Do not discard changes or force-remove a worktree when cleanup reports untracked files.

Worked example

A named feature branch can pass its own tests yet fail after merging because the base changed. The workflow requires testing that merged result before deleting its worktree. Conversely, a pull request keeps the checkout available for review fixes. If worktree removal reports an untracked migration note, forced cleanup would erase the only copy. The user should see that file and choose whether to preserve, move or explicitly delete it.

What you get

An integrated and verified change, a reviewable pull request, or an intentionally preserved branch, with clear workspace disposition.

How to evaluate the result

• The final report distinguishes merged, pushed for review and kept states.
• The correct final tree, including a merge result when applicable, passed verification.
• Uncommitted files and externally owned workspaces remain preserved unless deletion was explicitly chosen.

What you need

Git history, a known base branch, runnable project tests and access to the chosen forge when creating a pull request. Integration and deletion need their actual authorization.

Setup and activation

The publisher documents separate installation routes for Claude Code, Codex App and CLI, Cursor and other harnesses. Use the README for your exact client; installing the whole Superpowers framework can activate additional workflows automatically. Preserve this skill’s companion files and relative references. Review and security-scan the exact selected version before installation. This directory only reviews sources; it has not installed, executed or tested this skill on those clients.

Limits and considerations

Tests do not choose the correct target branch or grant release permission. The reviewed source reserves integration choices to the user and requires exact confirmation for discard. Host-managed workspaces stay intact; a rejected push is not permission to force-push. Worktree cleanup must occur from outside the directory and must not erase uncommitted material.

Related workflows

• Use verification-before-completion for fresh evidence behind the handoff.
• Use requesting-code-review before selecting an integration route.

License and reuse

MIT, copyright 2025 Jesse Vincent. Preserve the copyright and permission notice when redistributing substantial source portions; inspect separately supplied dependencies and assets under their own terms.

Further reading

• Reviewed skill version (immutable commit)
• Publisher setup, compatibility and telemetry notes
• Reviewed MIT license