# Ship

> Git and deploy ritual behind an explicit green-light gate. Use for any commit/push/PR/deploy intent — "commit", "push", "open a PR", "ship it", "deploy" — or when work is finished and needs to leave the machine.

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

---


# Ship — nothing leaves without a green

## Absolute gates
- **One green, one action.** An explicit approval in THIS session covers exactly ONE action. "Fix it" is not "commit it". "Commit" is not "push". "Push" is not "open a PR". Never chain ahead of the green. This is the whole point of the skill — approval for a step is not approval for the step after it.
- **Check repo-level rules first**: the repo's `.claude/settings.json`, `CLAUDE.md`, and the runbook's deploy section. A repo can ban git/GitHub operations entirely — in that case hand the user the commands to run themselves instead of running them.
- **Verify committer identity** matches the repo's expected account before committing. A wrong identity gets CI and deploy pipelines blocked.
- **Attribution follows the user's preference.** Many maintainers don't want AI co-author trailers or "generated with" footers in their history. Default to omitting them unless the project or user asks for them.

## Sequence
1. **Sanity**: `git status` + diff review. Confirm only intended files staged — no `.env`, no secrets, no stray docs. One concern per branch/PR; if the diff mixes concerns, say so and offer to split.
2. **Pre-merge check** (when merging/PRing): diff vs main — does anything revert or regress recent merges? Check CI status; root-cause failures, don't retry blindly.
3. **Message**: conventional commit (feat:/fix:/chore:/refactor:/docs:/test:/hotfix:), body explains *why*. Branch name reflects the work. Never commit to the default branch unless the user explicitly says to.
4. **Green**: state the exact plan in one or two lines ("branch X, commit 'fix: …', PR to main") and WAIT for approval. Then execute exactly that — no more.
5. **Deploys**: a push is not a deploy. Confirm the deployment actually built and is serving — not just that the commit landed. For serverless/edge functions, verify with a real invocation after deploying.

## Expo repos — OTA classification (run before any "submit to store" work)
1. Diff commits since the last native build.
2. JS/asset-only → `eas update` on the right channel per platform. Report: "OTA-safe. Pushed to <channel>."
3. Native touched (native modules, app.json, Info.plist, gradle, expo SDK) → version bump + `eas build` path. Report which files force it, one line.
4. Prepare, don't submit. Store submission is the user's call.

## Reply shape
Short: what shipped, where, and the URL or channel if one exists.