ship

Files (1)

• SKILL.md

SKILL.md (first lines)

# 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.

From therapys/dotagents, MIT.

More from therapys/dotagents