Ship the current changes through commit, push, and PR creation. Confirm with the user before each step using the AskUserQuestion tool.
Step 1: Scan
Current scan state (injected read-only below — no need to re-run these to gather it):
- Status: !
git -C "${CLAUDE_PROJECT_DIR:-.}" status --short 2>/dev/null || echo "(no git repo or no changes)"
- Change summary: !
git -C "${CLAUDE_PROJECT_DIR:-.}" diff --stat HEAD 2>/dev/null || echo "(no diff)"
- Recent commit style: !
git -C "${CLAUDE_PROJECT_DIR:-.}" log --oneline -5 2>/dev/null || echo "(no commits yet)"
For the full patch of a specific file before committing, run git diff -- <file> on demand (kept out of the injection to hold the render small).
- Present a clear summary to the user:
- Files modified
- Files added
- Files deleted
- Untracked files
- If there are no changes, tell the user and stop
Step 2: Stage & Commit
- Propose which files to stage. Never stage these:
- Secrets:
.env*, *.pem, *.key, credentials.json
- Lock files:
package-lock.json, yarn.lock, pnpm-lock.yaml (unless intentionally updated)
- Generated:
*.gen.ts, *.generated.*, *.min.js, *.min.css
- Build output:
dist/, build/, .next/, __pycache__/
- Dependencies:
node_modules/, vendor/, .venv/
- OS/editor:
.DS_Store, Thumbs.db, *.swp, .idea/, .vscode/settings.json
- Draft a commit message based on the changes, matching the repo's existing commit style
- ASK the user to confirm or edit: show the exact files to stage and the proposed commit message
- Only after confirmation: stage the files and create the commit
- If the commit fails (e.g., pre-commit hook), fix the issue and try again with a NEW commit
Step 3: Push
- Check if the current branch has an upstream remote
- If not, propose creating one with
git push -u origin <branch>
- ASK the user to confirm before pushing
- Only after confirmation: push to remote
Step 4: Pull Request
- Check if a PR already exists for this branch (
gh pr view. If it exists, show the URL and stop)
- Analyze ALL commits on this branch vs the base branch (not just the latest commit)
- Draft a PR title (under 72 chars) and body with:
- Summary: 2-4 bullet points
- Test plan: how to verify
- ASK the user to confirm or edit the title and body
- Only after confirmation: create the PR with
gh pr create
- Show the PR URL when done
Step 5: Branch cleanup (optional)
After the PR is created (or if invoked when everything is already shipped), offer to clean up stale local branches:
git fetch --prune, then find branches whose upstream is gone:
git for-each-ref --format '%(refname:short) %(upstream:track)' refs/heads | grep '\[gone\]'
- Show the list and ASK before deleting. Delete with
git branch -d only.
- If a branch isn't fully merged (
-d refuses), list it separately — deleting unmerged branches needs the user to explicitly say so, every time.
Rules
- NEVER skip a confirmation step. Each step requires explicit user approval
- NEVER force-push
- NEVER commit .env, secrets, or credential files
- If the user says "skip" at any step, skip that step and move to the next
- If $ARGUMENTS is provided, use it as the commit message / PR title
1---2name: ship3description: Commit, push, and create a PR for staged changes, with confirmation at each step. Use when your work is done and you want to ship.4---56Ship the current changes through commit, push, and PR creation. Confirm with the user before each step using the AskUserQuestion tool.78## Step 1: Scan910Current scan state (injected read-only below — no need to re-run these to gather it):1112- Status: !`git -C "${CLAUDE_PROJECT_DIR:-.}" status --short 2>/dev/null || echo "(no git repo or no changes)"`13- Change summary: !`git -C "${CLAUDE_PROJECT_DIR:-.}" diff --stat HEAD 2>/dev/null || echo "(no diff)"`14- Recent commit style: !`git -C "${CLAUDE_PROJECT_DIR:-.}" log --oneline -5 2>/dev/null || echo "(no commits yet)"`1516For the full patch of a specific file before committing, run `git diff -- <file>` on demand (kept out of the injection to hold the render small).1718- Present a clear summary to the user:19 - Files modified20 - Files added21 - Files deleted22 - Untracked files23- If there are no changes, tell the user and stop2425## Step 2: Stage & Commit2627- Propose which files to stage. **Never stage** these:28 - Secrets: `.env*`, `*.pem`, `*.key`, `credentials.json`29 - Lock files: `package-lock.json`, `yarn.lock`, `pnpm-lock.yaml` (unless intentionally updated)30 - Generated: `*.gen.ts`, `*.generated.*`, `*.min.js`, `*.min.css`31 - Build output: `dist/`, `build/`, `.next/`, `__pycache__/`32 - Dependencies: `node_modules/`, `vendor/`, `.venv/`33 - OS/editor: `.DS_Store`, `Thumbs.db`, `*.swp`, `.idea/`, `.vscode/settings.json`34- Draft a commit message based on the changes, matching the repo's existing commit style35- **ASK the user to confirm or edit**: show the exact files to stage and the proposed commit message36- Only after confirmation: stage the files and create the commit37- If the commit fails (e.g., pre-commit hook), fix the issue and try again with a NEW commit3839## Step 3: Push4041- Check if the current branch has an upstream remote42- If not, propose creating one with `git push -u origin <branch>`43- **ASK the user to confirm** before pushing44- Only after confirmation: push to remote4546## Step 4: Pull Request4748- Check if a PR already exists for this branch (`gh pr view`. If it exists, show the URL and stop)49- Analyze ALL commits on this branch vs the base branch (not just the latest commit)50- Draft a PR title (under 72 chars) and body with:51 - Summary: 2-4 bullet points52 - Test plan: how to verify53- **ASK the user to confirm or edit** the title and body54- Only after confirmation: create the PR with `gh pr create`55- Show the PR URL when done5657## Step 5: Branch cleanup (optional)5859After the PR is created (or if invoked when everything is already shipped), offer to clean up stale local branches:6061- `git fetch --prune`, then find branches whose upstream is gone:62 `git for-each-ref --format '%(refname:short) %(upstream:track)' refs/heads | grep '\[gone\]'`63- Show the list and **ASK before deleting**. Delete with `git branch -d` only.64- If a branch isn't fully merged (`-d` refuses), list it separately — deleting unmerged branches needs the user to explicitly say so, every time.6566## Rules6768- NEVER skip a confirmation step. Each step requires explicit user approval69- NEVER force-push70- NEVER commit .env, secrets, or credential files71- If the user says "skip" at any step, skip that step and move to the next72- If $ARGUMENTS is provided, use it as the commit message / PR title