ship

name	ship
description	Create branch, commit changes, and open PR with concise description. Triggers on "ship", "open pr", "send pr".
allowed-tools	["Read","Grep","Glob","Bash","Skill","AskUserQuestion"]

Ship Changes

Automates the full flow: branch creation (if needed), commit, push, and PR creation with a concise description.

---

Important Rules

• BLOCKING: NEVER add Co-Authored-By lines or Claude attribution to commits or PR descriptions
• BLOCKING: NEVER mention that the PR description was generated by an AI or assistant
• Write all commit messages and PR descriptions as if the user wrote them
• Use imperative mood for commit messages
• Keep PR descriptions concise and focused on the "why"

---

Phase 1: Assess Current State

Run these commands in parallel:

git status
git diff --stat
git diff --staged --stat
git log --oneline -5
git rev-parse --abbrev-ref HEAD

Determine:

• Current branch: Are we on the base branch (main/master/develop)?
• Changes: What files are modified, staged, or untracked?
• If no changes exist: Inform the user and stop.

---

Phase 2: Create Branch (if on base branch)

If current branch is main, master, or develop:

1. Analyze the changes to generate a short, descriptive branch name
2. Use format: <type>/<short-description> (e.g. fix/search-pagination, feat/match-scoring)
3. Present the branch name to the user for confirmation using AskUserQuestion
4. Create and switch to the branch:

   git checkout -b <branch-name>
   

If already on a feature branch, skip this phase.

---

Phase 3: Commit Changes

1. Review git diff (staged and unstaged) to understand all modifications
2. Group related changes logically — prefer one commit unless changes are clearly separate concerns
3. Stage files with specific paths (never use git add -A or git add .)
4. Draft clear commit message(s):
   • Imperative mood ("Add feature" not "Added feature")
   • Focus on why, not just what
   • First line under 72 characters
5. Create the commit(s) — do NOT add any Co-Authored-By lines
6. Verify with git log --oneline -3

If $ARGUMENTS includes a commit message hint, use it as guidance.

---

Phase 4: Push and Create PR

1. Push the branch:

   git push -u origin HEAD
   

2. Analyze all commits on this branch (vs base) to write a PR description:

   git log main..HEAD --oneline
   git diff main..HEAD --stat
   

3. Create the PR using gh:

   gh pr create --title "<concise title>" --body "<description>"
   

   PR title: Short, under 70 characters, imperative mood.

   PR body format:

   ## Summary
   <1-3 sentences explaining what changed and why>
   
   ## Changes
   <bulleted list of key changes>
   

   Keep it concise. No filler, no boilerplate sections, no AI disclaimers.

4. Output the PR URL to the user.

---

Phase 5: Compound Learnings

After the PR is created, invoke the compound skill to capture knowledge from this work session:

skill: compound

The compound skill will review the conversation for non-trivial problems solved, debugging insights, or patterns discovered during implementation. If nothing worth documenting was encountered (simple feature, no surprises), compound will detect this and skip gracefully.

BLOCKING: Do NOT skip this phase. The value of shipping is not just the code — it's the institutional knowledge captured alongside it.

---

Edge Cases

• No remote configured: Inform the user and stop
• Branch already has a PR: Show the existing PR URL, ask if they want to update it
• Push fails: Check if branch exists on remote, suggest force-push only with user confirmation
• Pre-commit hooks fail: Fix the issue if possible, re-stage, create a NEW commit (never amend)

---

Key Principles

• No attribution — commits and PRs read as human-authored
• Concise — minimal PR descriptions, no unnecessary sections
• Safe — never force-push without asking, never use git add .
• Fast — minimize back-and-forth, only ask when truly needed (branch name)