ship

name	ship
description	Commit and push all local current-branch work, open a ready PR, babysit it, merge when clean, then create a fresh branch. Use when the user asks to ship, publish, or hand off the current branch's local changes.
user-invocable	true
scope	dev
metadata	{"internal":true}

Ship

Ship the current branch end-to-end: commit and push all local work, open a ready PR, run /babysit-pr, merge when the babysit merge gates are satisfied, then run /new-branch after the merge lands.

Non-Negotiable Shipping Invariant

/ship ships the branch, not just the agent's own edits. Commit and push all non-gitignored local changes that are present on the current branch, including work created by the user or other concurrent agents. Do not leave local changes behind because you did not author them. The only routine exceptions are learnings.md and ignored/personal files.

Invoking /ship is explicit authorization to merge this PR once the merge gates below pass, unless the user says not to merge. Do not ask again just to merge a clean PR. Do not stop after creating the PR; the default /ship outcome is a merged PR and a fresh post-merge branch.

Push-All Default

pnpm ship:push

That is the whole procedure. scripts/ship-push.mjs stages the complete non-ignored worktree as whole files, applies the only routine exclusions (learnings.md, bridge/**, data/**), commits, pushes the current branch, and reads the remote sha back to confirm the push actually landed. It refuses to run on main and never creates, switches, or resets a branch. Anything it had to leave behind is printed under "left behind" — say those paths out loud.

Treat these as an immediate call to it: /ship, "ship our latest local changes", "push up the local changes", "push all local changed files". Run it before any long test, prep run, review wait, or cleanup — local files cannot receive CI or AI review, so the first remote checkpoint is the priority. Do not make the user ask twice.

Then keep running it. Once the ready PR exists, re-run pnpm ship:push after each focused slice (at most every couple of minutes) so CI and review agents see the work in parallel. A dirty worktree during this phase is expected: a clean tree is a merge gate, not a push gate. This cadence does not relax the final pnpm run prep, review, or merge-soak gates.

A live file lease means "do not edit this file right now" — never "do not publish it". The lease is about writes; the push snapshots whatever is on disk.

If the branch updates templates or publishable packages, shipping does not stop at merge. Treat the work as shipped only after the affected templates are live in production and affected packages have successfully published/released. If a production template deploy or package publish fails, retrigger the failed job when the existing code already contains the fix; otherwise make the necessary code/config fix and ship that follow-up until production is live.

Steps

1. Stay on the current branch: never create, switch, rebase, reset, or stash before opening the PR. This repo uses shared/platform-managed branches; ship the branch you are already on.

2. Check local changes: run git status --short and git diff --stat to understand all modified/untracked files. Multiple agents may have added work; include all non-gitignored local files in shipment instead of stashing, skipping, or reverting them.

3. Validate enough to avoid obvious breakage: run focused tests for the changed area. Push the first safe slice before running pnpm run prep or another long validation. Run prep when it is practical, but if prep is slow, flaky, or contaminated by concurrent in-flight edits, do not stall shipment: record the exact failure, keep pushing stable slices, and let GitHub Actions be the validation gate that /babysit-pr monitors.

4. Publish the snapshot: run pnpm ship:push. Pass -m "<message>" when the change deserves a specific commit message; otherwise it writes one from the diff. Never add Co-Authored-By or other agent attribution.

   The first successful push is the review handoff point: open or update the ready PR immediately, before waiting on pnpm prep, a stability window, or additional concurrent work. Later commits update that same PR and let CI and review run in parallel with the rest of the ship workflow. Re-run pnpm ship:push for each later slice as soon as it is coherent; do not wait for all local files to become commit-ready at once.

5. Open or update a ready PR immediately after the first push: use the current branch. PRs are ready for review by default, not drafts. Do not put codex, [codex], or similar agent labels in the title/body.

   For every later safe slice, update this same PR immediately after pushing; do not create a second PR or wait for prep to finish before handing the slice to CI and review.

6. Babysit immediately: run /babysit-pr <number> and follow that skill’s tick loop exactly. Treat babysit-pr as the source of truth for how to watch the PR; do not duplicate, shorten, or invent a lighter monitoring loop. Its Step 0 is authoritative: every tick starts by committing and pushing all local files and any unpushed commits, then checking mergeability, every unaddressed review comment by reply state, and CI. Keep going until the PR is either merged/closed or the user explicitly tells you to stop.

Important

• Multiple agents run concurrently. There will often be locally changed files you didn't generate. This is normal. Include everything and move forward. Don't revert other agents' work; fix real bugs if CI or review feedback flags them.
• Never commit learnings.md or files in .gitignore.
• If feedback appears in inline comments or review bodies, every item needs a fix or a reply before merge.
• Treat /babysit-pr as the source of truth for CI/review monitoring cadence, comment handling, local-file push discipline, and merge gates. Update babysit-pr first if the watcher behavior changes.
• Treat production deploy/publish verification as part of /ship whenever templates or publishable packages changed. A green PR is not enough if the affected template build or package publish later fails.
• Treat /new-branch as mandatory after a successful merge so the workspace is ready for the next task on fresh main.