ship

Ship

Three-step pipeline. The user can invoke any step standalone or the whole chain:

• Commit mode — quickly stage and commit with a conventional-commit message, then push to current branch
• PR mode (default for "ship") — detect + merge base branch, run tests, review diff, bump version, update CHANGELOG, commit, push, create PR
• Land-and-deploy mode — takeover after PR creation: merge the PR, wait for CI + deploy, verify production health via canary

Use whichever scope the user wants. If they say "ship" or "deploy", default to PR mode + ask whether to chain into land-and-deploy.

---

Commit mode (fastest — for WIP pushes mid-work)

When: user says "commit", "quick commit", "stage and commit."

Process:

1. Verify the cwd is a git repo on a non-main branch.
2. Run verification first (superpowers:verification-before-completion — tests pass, lint clean, type-check clean).
3. Review git status and git diff. Stage files explicitly by name (never git add -A — avoids accidentally staging .env or credentials).
4. Draft a conventional-commit message based on the diff. Imperative mood, concise subject, explain the "why" in body if non-obvious.
5. Commit. Push to current branch if tracked.

No PR, no deploy. Just a checkpoint commit.

---

PR mode (default)

When: user says "ship", "push to main", "create a PR", "get it deployed", or explicitly "ship PR."

Process:

1. Detect base branch. Usually main; fall back to master. Verify cwd's branch tracks that base.
2. Rebase/merge base. Fetch + merge origin/<base> into current branch. Resolve conflicts (never discard work).
3. Run the test suite. Unit + integration. Must pass fully — no "most tests pass" rationalizations (superpowers:verification-before-completion applies).
4. Review the diff. Use the review skill's changes mode. Catch SQL safety, LLM trust boundary violations, conditional side effects, structural issues. Block on Critical findings.
5. Bump version + update CHANGELOG (if the project uses them). Semver rules — see CLAUDE.md conventions if specified.
6. Stage + commit. Use conventional-commit format. Co-author line optional; follow project convention.
7. Push branch to remote with -u if not tracked.
8. Create PR via gh pr create. Title under 70 characters; body has ## Summary + ## Test plan sections.
9. Return the PR URL to the user.

Does NOT merge. The user (or land-and-deploy mode) handles merge + deploy.

---

Land-and-deploy mode

When: user says "land", "merge and deploy", "ship it to prod", "land it."

Prerequisites: PR already exists (from PR mode above, or manually).

Process:

1. Verify CI is green on the PR.
2. Merge the PR (gh pr merge --squash or --merge based on project convention; check .github/branch-protection or project CLAUDE.md).
3. Wait for the deploy workflow. If the project has a known deploy target (configured via /setup-deploy once), monitor its status endpoint.
4. Once deploy claims success, run the qa skill's canary mode for N minutes to verify production health.
5. If canary detects anomalies, alert the user and offer rollback guidance (does NOT rollback automatically — that's user decision).
6. Report success + URL to production + summary of what shipped.

---

Red flags (always stop)

• Tests failing → fix, don't skip
• Main/master branch is target → never force-push; never commit directly
• .env, credentials.json, or other sensitive files staged → unstage + tell user
• No CHANGELOG/version bump on a project that uses them → ask user
• User pushed earlier "from this session" but you haven't verified → always fetch fresh state

---

Migration

Consolidated from gstack's ship, land-and-deploy, and claudefather's commit-push-pr. Pick the mode based on how far the user wants to go.