ship

Task: Ship the current main branch

Bring the local main up to date, commit any pending work, and push to origin/main. A successful push is the end of the ship — do not watch CI, do not monitor the deploy, do not chase runs to green. Report the pushed HEAD and stop.

Session-aware mode

If you (the agent) made the pending changes yourself earlier in this conversation, you already know what changed and why — do not re-derive it from git:

• Skip the git diff --stat / git diff --cached --stat calls in Step 2. Run only git status as a sanity check.
• In Step 4, stage exactly the files you edited this session (by name) and write the commit message from your session knowledge.
• If git status shows modified/untracked files you did not touch this session, fall back to full inspection for those files (or ask the user) before staging anything beyond your own edits.

Only when the working tree contains changes you didn't make (fresh session, external edits) do the full Step 2 inspection.

Step 1 — Verify branch

git branch --show-current

If not on main, STOP and ask the user whether to switch or abort. Do not silently switch branches.

Step 2 — Inspect state

git status

Session-aware: if every change listed by git status is one you made this session, stop here — no diff commands needed.

Otherwise, inspect the unfamiliar changes:

git diff --stat

git diff --cached --stat

If the working tree is clean and there's nothing to commit, skip Step 4: still do Step 3 (pull) and Step 5 (push).

Step 3 — Pull latest with rebase

git pull --rebase origin main

If the pull/rebase has conflicts, resolve them proactively and continue shipping. A conflict by itself is not a reason to stop or ask the user what to do.

1. Inspect git status, the unmerged-file list (git diff --name-only --diff-filter=U), each combined diff, and relevant surrounding code/history. For difficult cases, inspect both index stages (git show :2:<path> and git show :3:<path>) and the commits being replayed.
2. Infer the intent of both sides and produce the smallest coherent merge that preserves both whenever possible. Follow current repository conventions and update dependent code, tests, generated outputs, or documentation when the combined result requires it.
3. Do not resolve wholesale with --ours, --theirs, --strategy=ours, or by blindly choosing the newer side. Use a side-specific version only when inspection shows that it is the complete intended result for that file.
4. Remove all conflict markers, run the most relevant formatting, generation, and tests that are practical, and review the resolved diff for accidental loss.
5. Stage only the resolved paths explicitly, run git rebase --continue (with a non-interactive editor if needed), and repeat until the rebase completes. If an autostash is restored with conflicts after the rebase, resolve and validate those conflicts with the same care, but do not run git rebase --continue when no rebase is active.