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
- Pin the scope. Read
git status, the current branch, unstaged diff, staged diff, and recent commits if needed. State what belongs to this shipment. - 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.
- Be on the right branch. Not on one? Create it before committing — never commit new work straight to main.
- 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.
- Commit deliberately. Prefer one cohesive commit per reviewable change. Message format: imperative subject under 72 characters, optional body explaining why. Avoid vague subjects like
updateorfix stuff. - 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. - Open the PR. Use
gh pr create; withoutgh, 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. - Report the shipment. Include branch, commit SHA, PR URL, verification command and result, and any residual risk.
PR shape
Use a compact PR body: