Ship

Ship

Standardized end-of-work delivery, so the same git ritual doesn't have to be re-typed every time.

Always, in order (every mode)

1. Survey first. git status + git diff --stat. If there are changes you did not make in this session, list them and ask before including them — commit only what belongs together. Never git add -A blindly.
2. Clean before staging.
   • Delete leftover test files, temp scripts, debug logs, and scratch code created during the session.
   • Check for junk that should be gitignored (.env*, node_modules, build output, .DS_Store, IDE dirs, coverage, *.log). Add missing entries to .gitignore before staging.
   • Never commit secrets. If a diff contains an API key or DB URL, stop and say so.
3. Commit style. Short, imperative, lowercase-ish messages ("fix dropdown overflow in dashboard"). No AI/agent attribution, no Co-Authored-By, no emoji, no body unless the change genuinely needs one. If the diff spans unrelated concerns, split into logical commits without being asked.
4. Push and confirm. Push to the correct branch, then report: branch, commit hash(es), one-line summary of what shipped. If push is rejected, pull --rebase and retry once; if conflicts, stop and explain.
5. No false "done". After shipping, explicitly list anything that still needs env vars, provider/dashboard setup, data seeding, or a device install before the change actually works for a user. Pushed ≠ working.

Modes (from args or context)

(default) — commit + push current branch

Just steps 1–5.

migrate — migrations + push

For projects that pair schema changes with a deploy:

1. Detect pending migrations (drizzle / prisma / supabase / raw SQL — from the repo). The DB URL is typically in .env.
2. Run migrations against the project's database. Show the output. If a migration fails, do NOT push — report and stop.
3. Then steps 1–5.

merge — merge to main and come back

1. Steps 1–5 on the current branch first.
2. git checkout main (or master — detect), git pull, merge the feature branch, push.
3. Always return to the original branch — work usually continues there.

pr — branch + pull request

1. If on main/master: create a descriptive feature branch first. Otherwise use the current branch.
2. Steps 1–5, push with -u.
3. gh pr create to main/master with a detailed description of what changed and why (the PR body can be long even though commits are short).
4. Report the PR URL.

review — address reviewer comments on the PR

For when another reviewer (human or an AI review bot) leaves comments:

1. gh pr view --comments + gh api for inline review threads on the current branch's PR.
2. For each finding: verify it is real in the code before fixing. Skip and say so if a comment is wrong or stale — do not blindly apply.
3. Fix the real ones, commit (short messages), push to the same branch, and summarize per-comment: fixed / rejected-why.

Notes

• "push" often means commit + push, not just push.
• If the user chained extra steps in the same request ("...and apply the same change to "), finish shipping FIRST, then do the extra steps — chained trailing steps are easy to drop.
• If a pre-merge review step is part of the workflow (for example, the codex-review skill), run it and only ship when it passes.