# Ship

> Commit all current work in logical chunks, synchronize it with origin/main or origin/master, run the full test suite, push to trunk, and update relevant tracker issues. Use when the user asks to ship, publish, or push all changes.

- Skill: `mikker/ship` (Agent Skill)
- Install (CLI): `npx skillmds@latest add mikker/ship`
- Raw SKILL.md: https://api.skillmd.com/api/skills/mikker/ship/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: mikker (https://skillmd.com/u/mikker)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/mikker/ship

---


# Ship

Ship the current branch's committed and uncommitted work to the trunk branch on
`origin`. This skill is explicit authorization to create commits and push them,
but never to force-push.

## Workflow

1. **Inspect the repository**
   - Read repository instructions and determine the full-suite test command.
   - Inspect the current branch, `git status`, staged and unstaged diffs, and
     untracked files.
   - Determine trunk from `origin/HEAD`, falling back to `main`, then `master`.
     If the target is still ambiguous, ask the user.
   - Do not include ignored files, secrets, credentials, or obvious generated
     artifacts merely because they exist locally.

2. **Commit all uncommitted work**
   - Include staged, unstaged, and appropriate untracked changes.
   - Split the work into the smallest sensible logical commits. Keep tests with
     the behavior they verify and avoid mixing independent concerns.
   - Review each staged diff before committing. Follow the project's commit
     conventions; otherwise use concise, imperative commit messages.
   - Do not amend or rewrite existing commits unless synchronization requires a
     rebase. Do not bypass commit hooks.

3. **Synchronize with trunk**
   - Fetch `origin`, then rebase the current branch onto `origin/<trunk>` when
     the remote branch contains commits not already in `HEAD`.
   - Resolve straightforward, mechanical conflicts carefully and continue the
     rebase. Never resolve conflicts wholesale with `ours` or `theirs`.
   - A substantive conflict is one where both sides changed behavior, intent is
     ambiguous, data could be lost, or the resolution requires a product or
     design choice. For any substantive conflict, explain the competing changes
     and ask the user how to proceed before editing the resolution. Leave the
     rebase paused while waiting.

4. **Run the full test suite**
   - Run the project's complete test suite after the final commit/rebase and
     before pushing. Also run required lint, type-check, or build commands when
     the project treats them as part of its standard verification.
   - Fix failures caused by the work being shipped, then rerun verification.
   - A failure may be ignored only when there is concrete evidence that the same
     failure occurs on the exact upstream trunk commit, ideally verified in a
     temporary clean worktree. Record that evidence in the final report. Any
     other failure blocks the push.

5. **Push to trunk**
   - Push with a normal fast-forward update, for example:
     `git push origin HEAD:<trunk>`.
   - Never force-push or use `--force-with-lease`.
   - If the push is rejected because upstream advanced, fetch, rebase onto the
     updated `origin/<trunk>`, apply the conflict rules above, rerun the full test
     suite, and retry the push.
   - If branch protection, authentication, or another non-fast-forward reason
     prevents the push, report it rather than bypassing the protection.

6. **Update issue tracking**
   - If the project uses an issue tracker, identify relevant issues from the
     branch, commits, repository metadata, and the changes themselves. Do not
     guess an issue association.
   - After a successful push, close issues fully resolved by the shipped work;
     otherwise add a concise progress update with the pushed commit when useful.
   - If no tracker or relevant issue is evident, skip this step.

7. **Report**
   - Summarize commits created, the pushed branch and commit, verification
     results (including any proven upstream failures), and issue updates.

## Guardrails

- Do not discard local work.
- Do not push until every intended local change is committed and accounted for.
- Do not push with unresolved or unexplained test failures.
- Ask only for ambiguous target selection or substantive conflict decisions;
  routine commit, rebase, test, and push steps are already authorized.