Ship

---
name: ship
description: >-
  Run the quality gate, then commit staged and unstaged changes and push to the remote in one step.
  Load when the user asks to commit and push, or invokes /ship.
compatibility:
  - claude-code
  - github-copilot
  - opencode
metadata:
  version: "1.0"
  author: team
---

# Ship (Commit and Push)

Stage tracked changes plus any new feature files, write a single conventional commit, and push to `origin`.

## Instructions

1. Run `git status`, `git diff --stat`, and `git log --oneline -10` in parallel to assess the change set and match recent commit style.
2. Run the project's quality gate (see CLAUDE.md) and confirm green. If it fails, stop and report — do not commit broken builds.
3. Draft a commit message following the convention in `CLAUDE.md` (`<type>(<scope>): <subject>`, imperative mood, lowercase, no period, ≤50 chars). The subject names the capability or outcome a reader would search the log for, never the mechanism; the body opens with one sentence on what changed and for whom, then one bullet per touched area, then how it was verified. Reference the REQ-XX-NNN identifier in the subject when applicable.
4. Stage files explicitly by name. Do not use `git add -A` or `git add .`. Skip `.scratch/` (gitignored) and any file that looks like a secret.
5. Commit using a HEREDOC so the body formats correctly. Include the `Co-Authored-By` attribution trailer your tool specifies; omit it if the tool specifies none.
6. Run `git push`. If the local branch is ahead by more than one commit, surface that to the user before pushing.
7. Report the resulting commit SHA and the push destination.

## Execution Template

```bash
git commit -m "$(cat <<'EOF'
<type>(<scope>): <subject>

<optional body — wrap at ~72 chars, explain why, not what>

<Co-Authored-By trailer as specified by your tool, if any>
EOF
)"
git push
```

## Rules

- Never commit if the quality gate is red.
- Never use `--no-verify`, `--amend`, or `git push --force` unless the user explicitly asks.
- Never stage files that look like secrets (`.env`, credentials, keys). Warn the user if they are present.
- One commit per invocation. If the change set spans unrelated concerns, flag it and ask whether to split before committing.
- If the working tree is clean, report it and stop — do not create empty commits.