pr

Opens a pull/merge request using the forge's native CLI, never a raw API call. Every forge speaks a different noun for the same thing (PR vs MR) — resolve the forge first, then use its verb throughout.

Steps

1. Check the current branch against the primary-branch list: main, master, dev, develop, trunk, staging, production, and glob release/*, hotfix/*. Get it with git branch --show-current.

   • Not primary → this is the head branch; skip to step 3.
   • Primary → a new branch is required; go to step 2. Done when: you know whether a new branch is needed.

2. Create the head branch off the primary branch, before committing anything (never commit to a primary branch directly). Name it <type>/<kebab-case-summary>, where <type> is the Conventional Commits type the change belongs to (fix, feat, docs, refactor, chore, test, etc.) — e.g. feat/add-login-page, fix/null-check-on-parse. Then git checkout -b <type>/<kebab-case-summary>. Done when: git branch --show-current prints the new branch name.

3. Ensure everything is committed. Run git status --porcelain; if anything is unstaged or uncommitted, stage the relevant files (review — don't blindly git add -A), show the staged diff, and commit with a Conventional Commits message (type(scope): subject). If a commit already covers the change, don't make an empty one. Done when: git status --porcelain is empty.

4. Push the branch with upstream tracking: git push -u origin "$(git branch --show-current)". Done when: the push succeeds and the remote reports the branch.

5. Resolve the forge from the remote URL (git remote get-url origin) by host, and use that forge's CLI for every remaining action — never gh/glab/tea/fj interchangeably: