Ship It

The work of this conversation is finished, or the user thinks it is. Your job is to get it all the way out — merged, released, and running in every environment this repo deploys to, production included — and to prove it got there rather than assume it did.

Two failure modes to hold in mind. The first is stopping early: a merged PR is not a shipped change, and a green deploy job is not proof the environment is running your commit. The second is shipping more than the user knows about: on most repos a release carries everything sitting unreleased on the target branch, which can include work by other people and other agent sessions. Section 4 exists entirely for that.

1. Ground yourself before doing anything

Take no action until you can name, from evidence, all four of these. Read; do not recall.

The work. What this session actually produced — the branches you created or committed to, and the commits on them. If the session is long or compacted and you cannot reconstruct it confidently, do not guess: check git log --author for the configured user, recent branches (git branch --sort=-committerdate), and the current branch, and state which of it you are treating as "the work" so the user can correct you.

The PRs. For each branch: is there a PR, is it open, merged, or closed-unmerged? A branch whose PR was closed without merging is a trap — the work looks done and is not. gh pr list --state all --head <branch> and gh pr view settle it.

The environments. What this repo actually deploys, and where. Do not assume a shape. Read the CI/CD definitions: .github/workflows/*, gh api repos/{owner}/{repo}/environments, plus whatever config is present — vercel.json, fly.toml, Procfile, Dockerfile, .circleci/, charts/, terraform/. Work out from those files what triggers each deploy: a push to a branch, a tag or release, a manual workflow_dispatch, or an external system Claude cannot reach at all.

The route. The ordered path from the branch to production — for example branch → PR → main → auto-deploy staging → tag → production. Name the base branch from the repo, not from habit.

If the repo defines no deploy mechanism you can see, say so and stop. Do not invent one.

2. Scope

Default: every environment, ending at production.

The user may pass an override — only staging, staging only, skip prod, --env=dev,staging. Honour it literally, narrowing which environments you deploy to and nothing else. Say in your final report which environments were deliberately left out, so a partial ship never reads as a finished one.

3. Land the work

Bring each branch to merged, in dependency order. Open the PR if there isn't one; if a PR was closed unmerged, ask before reopening — that closure may have been deliberate.

Before merging, make sure the branch is current with its base. Rebase or merge the base in, whichever this repo does. On conflict, apply the policy in section 6.

Wait for required checks to pass. If a check fails on your own work, fix it — that is part of shipping. If it fails on something you did not touch, stop and report; do not merge around it.

4. The confirmation gate — what rides along

Before anything reaches production, work out what else is going with it: everything on the target branch (or between the last release and the new one) that is not yours. Use git log <last-released-ref>..<target> --format='%h %an %s' — the release tag, the currently deployed SHA, or the last production deploy, whichever this repo makes knowable.

If everything in the release is this session's work, no gate. Proceed.

If it is not, stop and ask. First a very short summary — a few lines, not a changelog: each other author, and in plain terms what their change does. Have the reviewer agent read those commits for it (Agent tool, subagent_type: reviewer; general-purpose if it is not installed, and say so in a line): give it only the commit range and ask what each author's change does, judged from the code rather than the commit messages. You write the summary from its report. Then ask with the AskUserQuestion tool — a real "are you sure?", not a sentence in prose. Offer:

• Ship everything (recommended when the extra work is small and routine)
• Cancel — do not deploy

If the repo genuinely supports releasing only your commits, offer that as a third option. Do not offer it otherwise; a cherry-pick invented on the spot is worse than an honest question.

Never bypass this gate on your own judgement. If the user wants it skipped, that is /ship-it-now, which is their decision to make and not yours.

5. Deploy, then verify

Deploy to each in-scope environment in the repo's own order, lowest first, production last. Trigger deploys the way the repo does it — merge, tag, release, or gh workflow run. Watch each run to completion (gh run watch); a queued job is not a deployed one.

Then verify, per environment, and prefer proof over inference: the deployed SHA from a health or version endpoint, gh api .../deployments, the platform's own CLI, or the release tag on the environment. If an environment cannot be verified from here, say exactly that — do not upgrade "the job went green" into "it is live".

If a deploy fails, stop the chain there. Report what failed, what is already live, and what your recommended next step is. Never quietly retry into production.

6. Merge conflicts

Resolve conflicts yourself, at low effort, when the resolution is obvious: both sides added to the same list, formatting or import churn, a lockfile, one side is a strict superset. Keep both intentions. Then make sure it still builds.

Stop and ask the operator — with AskUserQuestion — only when the conflict signals something a merge cannot decide:

• The two sides want different behaviour from the same code. A genuine divergence of intent.
• Resolving either way removes or breaks behaviour the other side deliberately added.
• The conflict is in something structural — schema, migrations, config, a security or access rule — where a wrong guess is expensive and quiet.

When you stop, describe the two intentions in one line each and name who wrote each side. Everything else: resolve, note it in the final report, and keep moving.

7. Report

Close with a short report: what shipped, which PRs merged, which environments are confirmed running which commit, anything deliberately skipped, any conflict you resolved on your own judgement, and anything still outstanding. If the work did not fully ship, say so in the first line rather than the last.

8. Close-out check, after the ship (optional)

Once the report is out and the environments are confirmed, run /are-we-done if it is installed. Skip this silently if it is not: never a prerequisite, never installed on the fly.

After, not before. /ship-it is often used deliberately to push work that is still in testing, with a dirty tree and known gaps. A close-out sweep run before landing would flag every one of those as undecided and argue with a user who has already decided — the fastest way to make both skills annoying. Run afterwards, the same sweep is information rather than an obstacle: the release is out, and the question changes from may I ship? to what is left, now that shipping is no longer the thing occupying you?

It never gates the ship and never reverses one. Anything it surfaces is next session's work, or the user's call — including a blocker, which by this point is a known-shipped defect to decide about, not a reason to hold a release that has already gone.

If the ship was clean and /check-skill-updates is installed, run it last and append its one line. Skip it after a ship that did not fully land: the user has something real to deal with.