| name | ship |
| description | Finish a completed piece of work and integrate it cleanly — verify, then decide how to merge, PR, or set it aside. Use when implementation is done and tests pass, and you need to land the work and clean up. |
███████╗██╗ ██╗██╗██████╗
██╔════╝██║ ██║██║██╔══██╗
███████╗███████║██║██████╔╝
╚════██║██╔══██║██║██╔═══╝
███████║██║ ██║██║██║
╚══════╝╚═╝ ╚═╝╚═╝╚═╝
Ship and clean up
The end of a task is where state gets messy — half-merged branches, orphaned worktrees, premature pushes. This closes work out cleanly.
1. Verify first, always
Do not start shipping until forge:verify is green with this-turn evidence. Re-run the verify command(s) now and read the exit code / summary line in this same turn — "it passed earlier" is not evidence. If you can't show the output from this turn, stop and go verify. If anything is red or unverified, you're not finishing; you're still working.
2. Detect the environment
Establish where you are before acting: Are you in a git worktree or the main checkout? On a feature branch, main, or detached HEAD? Is the tree clean? This determines which options are even valid.
3. Present fixed options (let the user choose)
- Merge into the main/integration branch
- Open a PR (target the base it was branched from — if cut from a non-default branch, don't accidentally target
main and create a fat diff)
- Keep the branch as-is for later
- Discard the work (require the user to type "discard" to confirm — it's destructive)
(On detached HEAD, drop option 1.) Don't assume — integration choices are the user's.
4. Provenance-aware cleanup
- Only remove worktrees/branches you created in this work. Never touch harness-owned or pre-existing ones.
- Before removing a worktree, confirm its tree is clean (
git status inside it shows nothing to commit) — removing a dirty worktree loses work and is forbidden. After deleting a worktree directory, run git worktree prune.
- Order matters: merge → remove the worktree (from outside it, never from within) → delete the branch. Doing it out of order strands state.
5. Commit & push hygiene
- Write a clear commit message that matches this repo's existing convention: run
git log --oneline -20; if most subjects follow Conventional Commits (type(scope): subject), use that form, otherwise mirror the dominant style — and state which you detected before committing. Do not add AI/Claude co-author attribution or "generated with" trailers unless the user explicitly asks — match the user's own commit style.
- Never
push or force-push without an explicit request. Landing locally and pushing are separate decisions; the second is the user's to make.
- If on the default branch and about to commit substantial work, branch first.
Exit
Work landed (or deliberately parked) with a clean tree and no orphaned state.
