ship

name	ship
description	Use when the user wants to commit, push, and open a pull request for the current changes. Stages relevant files, writes a descriptive commit message, pushes the branch, opens a PR against main, and posts an /oc review comment so opencode automatically reviews and approves if ready.

Ship

Commits staged changes, pushes the branch, opens a PR, and triggers an automated opencode review.

When to Use This Skill

Invoke this skill when the user says things like:

• "ship it"
• "commit push pr"
• "ship this"
• "create a pr"
• "push and open a pr"
• "commit and ship"

Workflow

Follow these steps in order, stopping and reporting any errors immediately.

Step 1 — Sanity checks

Run these in parallel:

git status
git diff
git log --oneline -5
git remote -v

Use the output to understand: what branch we're on, what's changed, what the recent commit style looks like, and what the remote is.

Step 2 — Fetch and rebase

git fetch origin
git rebase origin/main

If there are conflicts, resolve them (keeping both sides where appropriate), then continue the rebase. Do NOT skip this step.

Step 3 — Stage files

Stage all changed/new files that are relevant to the work. Explicitly exclude:

• .DS_Store
• *.db, *.db-shm, *.db-wal
• Any file that looks like it contains secrets (.env, credentials.*, etc.)
• Prototype/demo directories unless they are part of the deliverable

git add <relevant files>
git status   # verify staging looks right

Step 4 — Commit

Write a commit message that:

• Uses the imperative mood (feat:, fix:, ci:, docs:, refactor:)
• First line ≤ 72 characters summarising the why, not the what
• Body bullet points for non-obvious details (optional but preferred for large changes)
• Matches the style of recent commits in git log

git commit -m "<message>"

Step 5 — Push

If the branch has no upstream yet:

git push -u origin <branch>

Otherwise:

git push

Step 6 — Open PR

Use the gh CLI to create a PR targeting main:

gh pr create \
  --title "<concise title matching commit subject>" \
  --body "$(cat <<'EOF'
## Summary

<2-4 bullet points describing what changed and why>

## Notes

<any reviewer context, migration steps, known limitations — omit section if none>
EOF
)" \
  --base main

Capture the PR URL from the output.

Step 7 — Trigger opencode review

Post the review comment on the PR so the opencode GitHub Action picks it up:

gh pr comment <PR number> --body "/oc please review this PR and approve if you find it ready to merge"

Step 8 — Report back

Tell the user:

• The commit hash and message
• The PR URL
• That the opencode review has been triggered

Rules

• Never force-push to main or master
• Never commit .env, secrets, or credential files — warn the user if they're staged
• Always rebase onto origin/main before pushing to minimise conflicts
• If gh is not authenticated, tell the user to run gh auth login first
• If the build/tests are known to exist (e.g. go build ./..., npm test), run them before committing and abort if they fail