Take the current changes from a dirty tree to an open pull request — branch, commit, push, and open the PR. Use when the user says any of: 'create a pr to main/dev', 'open a pr', 'push to main', 'commit and push', 'push this to git', 'ship it', 'push to the linear branch and open a draft PR', or asks to do the same across multiple repos ('push to each repo except infra').
Scanned 9/5/2026
Install to Claude Code
npx -y skills add therapys/dotagents --skill ship --agent claude-codeInstalls into .claude/skills of the current project.
Are you the author of Ship?
Add the live security badge to your README — it updates automatically with every re-scan.
[](https://www.skillsdirectory.com/skills/therapys-ship)More formats (shields.io, HTML) on the badges page.
---
name: ship
description: "Take the current changes from a dirty tree to an open pull request — branch, commit, push, and open the PR. Use when the user says any of: 'create a pr to main/dev', 'open a pr', 'push to main', 'commit and push', 'push this to git', 'ship it', 'push to the linear branch and open a draft PR', or asks to do the same across multiple repos ('push to each repo except infra')."
---
# Ship
One flow from working changes to an open PR. Delegates the commit *message* to the `commit` skill; owns everything around it (branch, push, PR).
## Conventions
- **Base branch is `main`.** Only target `dev` when the user explicitly says "to dev".
- **Branch naming:**
- Linear issue given (e.g. `ABC-123`): name the branch `<id>/<slug>` (lowercase id + short kebab slug from the issue title), matching Linear's copy-branch format. Use the Linear MCP to fetch the issue title for the slug when available.
- Otherwise: `feat/<slug>` for features, `fix/<slug>` for bug fixes (mirrors existing branches).
- **PR is a normal PR by default.** Open a **draft** only when the user says "draft".
- Never target or push directly onto `main`/`dev` for feature work — always go through a branch + PR, even when the user says "push to main" (that means "get it onto main *via a PR*").
## Steps
1. `git status` / `git diff` to understand the changes and the current branch.
2. **Branch:** if currently on `main`/`dev`, create the correctly-named branch (see conventions) and switch to it. If already on a suitable feature branch, stay.
3. **Commit:** follow the `commit` skill for the message (Conventional Commits subject). Honor any file scoping or guidance in the user's prompt.
4. **Push:** `git push -u origin <branch>`.
5. **Open PR:** `gh pr create --base <main|dev> --title "<subject>" --body "<short summary>"` (add `--draft` only if requested). Prefer `--fill` when the commit subject/body already say enough.
6. Return the PR URL. If CI matters, hand off to `fix-ci`.
## Multi-repo mode
Trigger: "on each of the repos", "all repos except infra", "push to git on each repo".
- Target set = the sibling git repos under a shared parent dir.
- Honor any excludes the user names (e.g. "except infra").
- Run steps 1–5 per repo that has changes. Skip clean repos and report them as skipped.
- Summarize at the end: one line per repo → branch + PR URL (or "no changes").
## Guardrails
- If there are unrelated/ambiguous staged files, ask which to include before committing (per the `commit` skill).
- Don't force-push. Don't amend or rebase shared history unless asked.
- If a Linear issue id was given, after opening the PR, offer to move the issue to "In Review" / link the PR via the Linear MCP — do it only if the user confirms.
Is this your skill, or is something wrong with this listing? Request removal or report an issue. Author removals are honored within 72 hours.
No comments yet. Be the first to comment!