ship

Ship the current branch: push it, open or update the MR/PR, and report. When
the argument names a local branch, run every step from that branch's worktree.
Create one with the worktree skill if none exists. Other argument text is a
task to finish first.
Parse --approve and --merge as options, not branch or task names.
With several branch names or all, ship each branch in turn, a parent before
its dependent children. For all, list the branches that have a .worktrees/
worktree with a clean tree and commits ahead of TARGET, excluding worktrees
another task uses. Show each with its ahead count and ask once before the first
push. For branches that depend on each other, follow Chains of dependent
MRs/PRs in dependent-branches.md.
Ordinary shipping ends after the push, MR/PR update, and any triggered review with its fix push.
When a rebase of more than about 5 commits conflicts on a lockfile, read
lockfile-rebase.md.
With --approve or --merge, read merge.md before
mutations to check platform support and scope. Approval and merge run after the
review's fix loop (step 4).

When a session-resume record exists for the task, read it before the context
check and apply session-resume's reuse rules.

Start only with push authorization under git-policy.md. Without it,
ask one question and stop. With it, run every step yourself. Never tell the
user to type /ship.

0. Detect context (always run first)

Always read first, in one parallel batch: context.md,
shared/git-flow.md, shared/default-branch.md, and shared/git-policy.md.

1. Commit gate

Run the Commit gate from shared/git-flow.md. It owns task scope, the
clean-tree check, and the commit report against COMMIT_BASE. With a changed
submodule, run the Commit gate in shared/submodules.md first; it gates the
submodule and the gitlink bump before the superproject.

2. Push

Immediately before any push, refresh BRANCH and resolve the live
REMOTE_DEFAULT again. Stop if BRANCH equals it or TARGET.
Pause auto-merge on EXISTING and any submodule MR/PR per
auto-merge-pause.md. If EXISTING is queued,
follow its Queued MR/PR rule, then rerun step 0 on the new branch.
If auto-merge cannot be disabled and the user agrees to push, review before the push; that is the hand-off review, so skip the after-push review.

• First push, or new commits on an already-pushed branch: git push -u origin <BRANCH>.
• Branch exists on the remote but histories diverged (rebase/amend since last push):
  git push --force-with-lease --force-if-includes origin <BRANCH>.
  If rejected, reconcile remote changes and rerun affected checks; never drop either safeguard.
  Never plain --force; never any force on
  TARGET or REMOTE_DEFAULT; never push either from this skill.
• With a changed owned submodule, follow Ship in
  submodules.md first; it owns the submodule push and
  the superproject's --recurse-submodules=check push.
• Check that the push landed (git status -sb shows no ahead-count) and say so.
• Record HEAD_SHA from git ls-remote origin refs/heads/<BRANCH>. Record it
  again after each later push. Step 6 and merge.md use it.

3. Open or update the MR/PR

• Refresh EXISTING before creation. Update it instead of creating a duplicate.
  If its base changed during this run, reread it before deciding the target.
• Title: the repo's commit/MR convention — read the repo's AGENTS.md / CLAUDE.md /
  CONTRIBUTING for it. For conventional titles, choose the type with the commit skill's
  Choosing the type procedure; a squash merge makes the title the commit. Include TICKET when set. If the repo requires a ticket and there is
  none, never invent a key:
  • The user asked for a ticket: run mr-ticket and use its key.
  • The user said no ticket: ship without one.
  • Otherwise run mr-ticket to find or create one; it picks the project.
    Skip the ticket for dx, docs, or test-only changes. Ask once only when two candidate tickets match.
• Description: follow the repository template when present. Otherwise:
  • Use 1–4 sentences on what changed and why, then 1–10 bullets, as few as
    possible, for behavior changes, risks, and validation.
  • Attach UI evidence for UI changes unless text or the diff suffices.
  • No checklists, file-by-file walkthroughs, or Summary/Changes/Testing headings.
  • Lead with the concrete problem and resulting behavior. Describe the final
    change for someone who has not read the conversation.
  • Reread before posting; drop sentences repeating another sentence, the title, or the diff.
• Use the recorded TARGET. Leave draft state alone unless asked.
• When TICKET is set, move it to the open-MR/PR status per mr-ticket step 6.

4. Finish the requested scope

Before finishing the requested shipping scope: finish-scope.md.

5. Clean up

Follow task-resources.md,
except keep a running CI watch from step 4. Keep a worktree and its branch while
the MR/PR is open, unless the user requests cleanup; after merge or closure, use
the worktree skill's Remove section. If IN_WORKTREE is false, leave the
main checkout and its branch in place. Report retained paths and reasons.

6. Report

Before reporting shipping results: report.md.

Hard rules

• Never merge, approve, close, or mark ready unless the user asks.
• Create or transition tickets only through mr-ticket, per step 3. Reuse keys you find.
  Transitions move TICKET forward only.
• Everything in Shared rules of shared/git-flow.md.