Ship

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.