The finishing-a-development-branch Skill — Four Options, No Guesswork
How Datarim closes the gap between "tests pass" and "work is done" — with a structured four-option menu, worktree-aware cleanup, and a push verification that does not rely on stdout text.
Implementation being complete and the branch being ready to ship are two different things. The finishing-a-development-branch skill handles the step between them: it verifies tests, detects the workspace state, presents exactly the right options, executes the chosen one, and cleans up correctly — without leaving orphaned worktrees or merged branches.
The skill runs when the developer signals that the implementation is done. Its core sequence is: verify tests, detect environment, determine base branch, present options, execute choice, clean up workspace.
The four-option menu
For a normal repository and for a named-branch worktree, the skill presents exactly four options: merge back to the base branch locally, push and create a pull request, keep the branch as-is for later handling, or discard the work. For a detached HEAD workspace — one the harness manages externally — the local merge option is removed and three options are presented instead.
The menu is intentionally concise. Adding explanations or caveats is an anti-pattern; the structure itself carries the decision surface. A discard request requires typing the word "discard" as confirmation; there is no shortcut past that step.
Push verification by SHA, not stdout
After git push, the canonical output line showing the remote branch reference is frequently rewritten or truncated by hook wrappers — token reducers, lint filters, terminal multiplexers. Gating the next step on that text has caused agents to wait 15 minutes on pushes that had already succeeded. The skill verifies push success by comparing the local HEAD SHA to the upstream tracking ref directly: if they match, the push is confirmed; if not, the push failed and the process stops.
The same SHA-equality check applies to pull and fetch operations. When the upstream tracking ref is not yet configured — on the first push of a new branch — the skill uses git ls-remote to read the remote SHA and compares it to the local HEAD.
Worktree cleanup rules
Cleanup runs only for options 1 (merge locally) and 4 (discard). Options 2 and 3 always leave the worktree in place — option 2 because the operator needs it alive while iterating on pull request feedback, option 3 because the operator explicitly chose to handle it later.
When cleanup does run, the skill checks provenance before removing anything. Agent-created scratch worktrees live under .worktrees/ or worktrees/ and are safe to remove. External worktree-manager paths under ~/.config/ are owned by that tool and must not be touched. Cleanup always runs from the main repository root — not from inside the worktree — and is followed by git worktree prune to clear any stale registrations.
Test failure is a hard stop
If the test suite reports failures, the skill stops before presenting any options. It shows the failing tests and states that no merge or push can proceed until they pass. This is not advisory — the skill does not offer to continue anyway. The reasoning is that presenting integration options on a broken branch creates a choice that should not exist.
Read more about the Datarim pipeline in what Datarim is, or see how the expectations-checklist skill ensures the work met the operator's original intent before the branch is closed.