Ship

# Ship — Safe Push to Remote

## Trigger
User says "/ship", "ship it", "ship this", or "safe push".

For normal "push" or "commit this" — commit and push normally but still never commit secrets.

## Purpose
Audited push for a PUBLIC repo. Prevents accidental secret leaks, catches files that shouldn't be public, and ensures clear commit messages. Think of it as checking your pockets before walking through the door.

## Process

### Step 1 — Pre-flight check
1. Run `git status` and `git diff --staged` (or `git diff` if nothing staged yet)
2. Show the user a **plain-English summary**: what files changed, what the changes do, how many additions/deletions
3. If nothing to commit, say so and stop

### Step 2 — Secret scan
Scan **every staged/changed file** for these patterns:

**API keys & tokens:**
- `sk-ant-`, `sk-` (Anthropic, OpenAI)
- `ghp_`, `gho_`, `github_pat_` (GitHub)
- `AKIA` (AWS access key)
- `xoxb-`, `xoxp-` (Slack)
- `whsec_` (Stripe webhook)
- `pk_live_`, `sk_live_`, `rk_live_` (Stripe)

**Generic secret patterns:**
- `API_KEY=`, `api_key=`, `apikey=` followed by a value
- `SECRET=`, `secret=` followed by a value
- `TOKEN=`, `token=` followed by a value
- `PASSWORD=`, `password=` followed by a value
- `PRIVATE_KEY` followed by content
- `Bearer ` followed by a token (not in docs/examples)
- `Basic ` followed by encoded credentials

**Dangerous files:**
- `.env`, `.env.local`, `.env.production` (even if gitignored — verify)
- `credentials.json`, `service-account.json`, `*.pem`, `*.key`
- Files > 10MB (large binaries don't belong in git)

**Production hazards:**
- Hardcoded `http://localhost` or `http://127.0.0.1` in non-config, non-test files

**If ANY match is found:**
- **STOP immediately.** Do not push.
- Show the exact file, line, and matched pattern
- If the pattern is in `.env.example` with placeholder values (like `sk-ant-...`), that's fine — skip it
- If a secret appears to have been committed in a prior commit, warn: **"This secret is burned. Deleting it from code doesn't help — bots already scraped it. Rotate the key immediately."**

### Step 3 — Stage and commit
1. If changes aren't staged yet, show which files will be staged and ask user to confirm
2. Stage specific files (never `git add .` or `git add -A` without reviewing)
3. Write a clear commit message: imperative mood, what changed and why
4. Show the commit message to user before committing
5. Commit

### Step 4 — Push
1. `git push origin <current-branch>`
2. **Never force push** unless user explicitly requests it AND you warn what will be lost
3. If push is rejected (remote has new commits), explain and offer `git pull --rebase` first

### Step 5 — Confirm
One line: `Shipped: {commit message} → origin/{branch} ({N} files, +{additions} -{deletions})`

## Rules
- Never skip the secret scan — even for "just a quick fix"
- Never commit `.env`, `.env.local`, credentials, or private key files
- Never force push without explicit user request + warning about consequences
- `.env.example` with placeholder values is fine to commit
- If in doubt about a file, ask the user before staging
- This skill is portable — works for any git repo, not just this project