Installs into .claude/skills of the current project.
Are you the author of Ship?
Add the live security badge to your README. It updates with every re-scan.
[](https://www.skillsdirectory.com/skills/wsauret-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:
```bash
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:
```bash
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:
```bash
git push -u origin HEAD
```
2. Analyze all commits on this branch (vs base) to write a PR description:
```bash
git log main..HEAD --oneline
git diff main..HEAD --stat
```
3. Create the PR using `gh`:
```bash
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)