Ship

Install

npx -y skills add vasu-devs/Forge --skill ship

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

1 stars1 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

What its author says it does

Copied from the file, not written here

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.

SKILL.md

3.2 KB, as published. Nobody here has run it

███████╗██╗  ██╗██╗██████╗
██╔════╝██║  ██║██║██╔══██╗
███████╗███████║██║██████╔╝
╚════██║██╔══██║██║██╔═══╝
███████║██║  ██║██║██║
╚══════╝╚═╝  ╚═╝╚═╝╚═╝

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.