ship

Start your message with the literal word ship followed by a description of the feature or fix. The workflow creates a worktree, implements and validates the change, pushes a conventional-commit branch, and opens a PR with gh or an MR with glab.

It creates a sibling directory named <repo>-worktrees next to the main checkout and adds a worktree on a feature/<name> or fix/<name> branch from the remote default branch. All implementation, commits, and pushes happen there, never in the main checkout.

Yes. It detects the hosting platform from the git remote and installed tools, using gh pr create for GitHub and glab mr create for GitLab. If neither CLI is available, it stops after pushing and reports the exact command needed.

The workflow stops and reports that the main checkout must be clean before shipping. It never overwrites, stashes, resets, or deletes existing work, and it refuses to reuse existing branches or worktree paths.

It runs the repository's documented checks first, or detects conventions per language: format, lint, typecheck, and test scripts for JavaScript/TypeScript, gofmt and go vet for Go, cargo fmt and clippy for Rust, and configured tooling for Python.

Do not use it when your message does not start with the literal word ship, or when you only want discussion or exploration without a branch, commits, and PR/MR. The trigger is mandatory once used, even for trivial one-file changes.