Ship
Stage, verify, commit, and push your changes in one workflow.
Usage
/ship # Full workflow: stage → check → commit → push
/ship --skip-checks # Emergency: stage → commit → push (skip quality gates)
/ship --deploy # Full workflow + deploy after push
Step 1: Smart Staging
- Run
git status to see all changes
- Auto-exclude from staging:
.env, .env.*
*credentials*, *.pem, *.key
*id_rsa*, *id_ed25519*
*.sqlite, *.db
- If excluded files are found, warn the user:
"Excluded from staging: .env.local (contains secrets). Add manually with git add .env.local if intentional."
- Stage all remaining changes:
git add with specific file paths (not git add .)
Step 2: Quality Gate (skip with --skip-checks)
Run all three checks in parallel (separate Bash calls):
# Parallel execution — do NOT run sequentially
npm run lint # or ruff check .
npx tsc --noEmit # or mypy .
npm run test # or pytest
On failure:
- Show which checks failed with summary output
- Ask the user: "Quality gate failed. Options: (1) Fix issues, (2) Ship anyway, (3) Abort"
- If user says "fix": attempt auto-fix (lint --fix, etc.), then re-run checks
- If user says "ship anyway": proceed with a warning commit message prefix
- If user says "abort": stop entirely
Step 3: Commit
- Run
git diff --staged to see what will be committed
- Analyze changes and generate a conventional commit message:
- Use the appropriate type:
feat:, fix:, refactor:, docs:, chore:, test:
- Keep subject under 72 chars, imperative mood
- Add body explaining WHY if the change is non-obvious
- Show the proposed commit message to the user for approval
- Commit with the approved message (include
Co-Authored-By line)
Step 4: Push
- Push to remote:
git push
- If remote branch doesn't exist:
git push -u origin HEAD
- If push fails (e.g., behind remote):
- Run
git pull --rebase then retry push
- If rebase conflicts, stop and alert the user
Step 5: Deploy (only with --deploy)
Auto-detect deployment target:
Vercel
# Check for vercel.json or .vercel/
vercel --prod
Docker
# Check for Dockerfile
docker build -t $(basename $(pwd)):latest .
docker push $(basename $(pwd)):latest
Custom
- Check for
deploy script in package.json: npm run deploy
- If no deployment target found, tell the user and suggest setting one up
Constraints
- NEVER stage files matching the exclusion patterns without explicit user approval
- ALWAYS show the commit message for user approval before committing
- If quality gates fail and user doesn't choose to proceed, do NOT commit
- On
--skip-checks, add to commit body: [skip-checks: user requested emergency ship]
1---2name: ship3description: Stage, verify, commit, and push in one command — smart staging, parallel quality gates, conventional commits, optional deploy. Use when asked to "ship it", "commit and push", or "send it"4---56# Ship78Stage, verify, commit, and push your changes in one workflow.910## Usage11```12/ship # Full workflow: stage → check → commit → push13/ship --skip-checks # Emergency: stage → commit → push (skip quality gates)14/ship --deploy # Full workflow + deploy after push15```1617---1819## Step 1: Smart Staging20211. Run `git status` to see all changes222. Auto-exclude from staging:23 - `.env`, `.env.*`24 - `*credentials*`, `*.pem`, `*.key`25 - `*id_rsa*`, `*id_ed25519*`26 - `*.sqlite`, `*.db`273. If excluded files are found, warn the user:28 > "Excluded from staging: .env.local (contains secrets). Add manually with `git add .env.local` if intentional."294. Stage all remaining changes: `git add` with specific file paths (not `git add .`)3031---3233## Step 2: Quality Gate (skip with `--skip-checks`)3435Run **all three checks in parallel** (separate Bash calls):3637```bash38# Parallel execution — do NOT run sequentially39npm run lint # or ruff check .40npx tsc --noEmit # or mypy .41npm run test # or pytest42```4344### On failure:45- Show which checks failed with summary output46- Ask the user: "Quality gate failed. Options: (1) Fix issues, (2) Ship anyway, (3) Abort"47- If user says "fix": attempt auto-fix (lint --fix, etc.), then re-run checks48- If user says "ship anyway": proceed with a warning commit message prefix49- If user says "abort": stop entirely5051---5253## Step 3: Commit54551. Run `git diff --staged` to see what will be committed562. Analyze changes and generate a conventional commit message:57 - Use the appropriate type: `feat:`, `fix:`, `refactor:`, `docs:`, `chore:`, `test:`58 - Keep subject under 72 chars, imperative mood59 - Add body explaining WHY if the change is non-obvious603. Show the proposed commit message to the user for approval614. Commit with the approved message (include `Co-Authored-By` line)6263---6465## Step 4: Push66671. Push to remote: `git push`682. If remote branch doesn't exist: `git push -u origin HEAD`693. If push fails (e.g., behind remote):70 - Run `git pull --rebase` then retry push71 - If rebase conflicts, stop and alert the user7273---7475## Step 5: Deploy (only with `--deploy`)7677Auto-detect deployment target:7879### Vercel80```bash81# Check for vercel.json or .vercel/82vercel --prod83```8485### Docker86```bash87# Check for Dockerfile88docker build -t $(basename $(pwd)):latest .89docker push $(basename $(pwd)):latest90```9192### Custom93- Check for `deploy` script in package.json: `npm run deploy`94- If no deployment target found, tell the user and suggest setting one up9596---9798## Constraints99100- NEVER stage files matching the exclusion patterns without explicit user approval101- ALWAYS show the commit message for user approval before committing102- If quality gates fail and user doesn't choose to proceed, do NOT commit103- On `--skip-checks`, add to commit body: `[skip-checks: user requested emergency ship]`