ship

Installation
SKILL.md

# ship

Ship like a careful engineer: know the diff, prove it works, publish only the intended change, and leave a PR a reviewer can understand.

Process

  1. Pin the scope. Read git status, the current branch, unstaged diff, staged diff, and recent commits if needed. State what belongs to this shipment.
  2. Protect user work. Never stage unrelated files. If the tree contains ambiguous changes, ask before staging or committing them. Keep generated artifacts out unless the task requires them.
  3. Be on the right branch. Not on one? Create it before committing — never commit new work straight to main.
  4. Verify before commit. Run the narrowest meaningful tests, lint, typecheck, build, or smoke command. If verification cannot run, say exactly why and do not pretend it passed.
  5. Commit deliberately. Prefer one cohesive commit per reviewable change. Message format: imperative subject under 72 characters, optional body explaining why. Avoid vague subjects like update or fix stuff.
  6. Push the branch. Push the current branch to the expected remote, usually origin, and set upstream when needed. Do not force-push unless the user explicitly requests it or the branch is clearly yours and the reason is stated first.
  7. Open the PR. Use gh pr create; without gh, push and hand the user the compare URL. Default to a draft PR when confidence is incomplete or checks are still pending; otherwise make it ready for review.
  8. Report the shipment. Include branch, commit SHA, PR URL, verification command and result, and any residual risk.

PR shape

Use a compact PR body:

Installs
4
First Seen
Jun 12, 2026
ship — h00mankind/workflow