finishing a development branch
current authority
existing user authority determines integration. do not require another menu or approval after an already authorized action; ask only when the next step exceeds authority. inspect staged paths and preserve peer edits.
verify, detect, present options, execute the choice, clean up. the integration decision belongs to the human partner — the agent presents a menu and waits.
what it teaches
the sequence:
- verify the full suite on the tree about to be integrated. a green run from earlier proves only the tree it ran on. failures stop everything before the menu exists.
- detect the environment — normal repo, named-branch worktree, or detached HEAD — it determines the menu and who owns cleanup.
- confirm the base branch before any merge; merging into the wrong base is the most expensive undo in the flow.
- present exactly three options: merge locally, push and create a PR, or keep as-is. discarding work appears only on an explicit request, confirmed by the literal word.
- execute, then clean up — worktree removal only when it's ours, never forced past a refusal: a refused removal means uncommitted files exist nowhere else, and destroying them is a three-option conversation.
why it exists
"They obviously want it merged" is the rationalization this skill kills. integration is irreversible-ish: a merge on a stale or unverified tree publishes work nobody validated, and deleting the branch afterward closes the cheap rollback window, leaving recovery as archaeology in someone else's session. exactly three options — merge, push for review, or keep — made from a fresh green run on the final tree converts that gamble into a one-word human decision with recorded evidence behind it. the choice is asked exactly once: repeated prompts re-open the negotiation the skill exists to close.
the rules
- no menu before a green suite on the final tree.
- merged results get re-verified; a failure leaves everything in place for investigation.
- force-deleting a branch happens only on the typed word
discard.
when to use
when implementation is complete and verified, at the end of every plan execution or feature branch.
good and bad
bad
checks: probably greenaction: merge and delete branch
an irreversible integration decision made from assumed rather than fresh evidence. merging on a remembered green run integrates a tree nobody validated: a change committed after the run, a broken dependency, or a stale checkout all slip through and surface in someone else's session. the branch is already deleted, so the cheap rollback window is gone and recovery means archaeology.
good
checks: current tree verifiedhandoff: merge, keep, or discard with the recorded evidence
the human receives a complete decision after the final tree is proven. a fresh green run on the exact tree means the menu options are real; recording the evidence makes the choice defensible later. integration stops being a gamble and becomes a one-word answer to a verified handoff.