| name | ship |
| description | Scan changes, commit, push, and create a PR. With confirmation at each step |
| argument-hint | [optional commit message or PR title] |
| disable-model-invocation | true |
| allowed-tools | ["Bash(git status)","Bash(git diff *)","Bash(git log *)","Bash(git add *)","Bash(git commit *)","Bash(git push *)","Bash(git checkout *)","Bash(git branch *)","Bash(gh pr create *)","Bash(gh pr view *)","Bash(git fetch *)","Bash(git for-each-ref *)"] |
Ship the current changes through commit, push, and PR creation. Confirm with the user before each step using the AskUserQuestion tool.
Step 1: Scan
- Run
git status to see all changed, staged, and untracked files
- Run
git diff to see what changed (staged + unstaged)
- Run
git log --oneline -5 to see recent commit style
- 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