" --body-file <tmp> ``` Write the body to a temp file (`mktemp` first), then run. If `gh` is not installed or returns auth error, fall back to manual paste. ### GitLab ```bash glab mr create --title "<title>" --description-file <tmp> ``` Same fallback rule as `gh`. ### Manual paste Print the assembled title and body in a fenced block, with the host's create-URL if you can derive one: ``` ## Manual paste URL: <https://github.com/owner/repo/compare/main...feat/AC-123-...?expand=1> Title: feat(AC-123): rename primary button Body: <body text> ``` ## Confirmation before opening Always show the assembled title + body and ask `[y / N / edit]` before calling `gh` / `glab`. Manual-paste path doesn't need confirmation — printing IS the output. ## Anti-patterns - **Deriving the title from the diff** — refused. Use the branch. - **Adding sections to the body** beyond description + optional bullets — refused. Pure prose. - **Auto-opening without confirmation** — never. Always show + ask. - **Inventing bullets from the diff** — refused. Only the user supplies bullets. - **Falling back to "main" / "master" PR** — if HEAD is on the default branch, stop and tell the user to create a feature branch first.

--- description: Open a cleepi-style PR/MR. Derives the title from the branch name (per git-branch + git-pr), takes a 1–3 sentence description + optional bullets, detects host (GitHub/GitLab), and either runs gh/glab or prints for manual paste. argument-hint: "[]" --- The user wants to open a PR/MR. Args: **$ARGUMENTS** ## Critical: required tool calls BEFORE assembling The whole point of `/pr` is to mechanically derive `(): ` from the branch name. You cannot do that without knowing the branch and cwd. Before producing the title, you MUST run these tool calls in this order: 1. `bash: pwd` 2. `bash: git rev-parse --abbrev-ref HEAD` 3. `bash: git remote get-url origin` (errors are tolerable — detached / no-remote falls back to manual-paste) 4. `bash: git log origin/HEAD..HEAD --oneline 2>/dev/null || git log -10 --oneline` (context only, not for title derivation) If you skip any, the title may come out wrong. Load `/skill:git-branch` and `/skill:git-pr` if you haven't — they have the full convention. ## Then: required output shape After the tool calls, your reply MUST contain this block before any `gh` / `glab` call: ``` ## Resolution - branch: (from git rev-parse) - type: (from branch: /...) - ticket: (from branch: .../-...) - domain: (from cwd, used only when no ticket) - subject: (from branch slug) - host: - title: (): ``` If the branch name doesn't match `/...` (per `git-branch`), **stop** and tell the user: > Branch `` doesn't match `/[-]`. > Rename it first (e.g. `git branch -m feat/AC-123-foo`), > then re-run `/pr`. Do not attempt to guess the type from the diff. Do not open a PR with a bare or malformed title. ## Title derivation Given branch `feat/AC-123-rename-primary-button`: - `type` = `feat` - `ticket` = `AC-123` - `slug` = `rename-primary-button` → `rename primary button` - `title` = `feat(AC-123): rename primary button` Given branch `chore/bump-prettier` (no ticket): - `type` = `chore` - `ticket` = none - `domain` = resolved from cwd per `git-commit` (nearest `packages//` → ``, else ask). Use `meta` for repo-level work if user passes `--domain=meta`. - `slug` = `bump-prettier` → `bump prettier` - `title` = `chore(): bump prettier` ## Body assembly 1. If `$ARGUMENTS` contains a description, that's the body prose (1–3 sentences). Quote it verbatim, no rewriting. 2. Otherwise, ask the user: > Description? (1–3 sentences. What and why combined. > Skip the bullets if the PR is small/obvious; pass them > as a second arg or paste them after.) 3. Bullets (optional) are anything the user explicitly passes after a blank line or via a `--bullets="- a\n- b"` style arg. **Never invent bullets from the diff.** Do not add headers (`## Summary`, `## Test plan`, etc.). Do not add a `Closes #N` footer. The body is plain prose + optional bullets. Full anti-pattern list is in `/skill:git-pr`. ## Host detection From the origin URL: - Contains `github.com` → GitHub. Use `gh pr create`. - Contains `gitlab` (with `.com`, `.io`, custom domain, etc.) → GitLab. Use `glab mr create`. - Anything else, or empty/error → **ask**: > Host? `gh` / `glab` / `manual` (just print for paste) ## Opening the PR/MR ### GitHub ```bash gh pr create --title "" --body-file <tmp> ``` Write the body to a temp file (`mktemp` first), then run. If `gh` is not installed or returns auth error, fall back to manual paste. ### GitLab ```bash glab mr create --title "<title>" --description-file <tmp> ``` Same fallback rule as `gh`. ### Manual paste Print the assembled title and body in a fenced block, with the host's create-URL if you can derive one: ``` ## Manual paste URL: <https://github.com/owner/repo/compare/main...feat/AC-123-...?expand=1> Title: feat(AC-123): rename primary button Body: <body text> ``` ## Confirmation before opening Always show the assembled title + body and ask `[y / N / edit]` before calling `gh` / `glab`. Manual-paste path doesn't need confirmation — printing IS the output. ## Anti-patterns - **Deriving the title from the diff** — refused. Use the branch. - **Adding sections to the body** beyond description + optional bullets — refused. Pure prose. - **Auto-opening without confirmation** — never. Always show + ask. - **Inventing bullets from the diff** — refused. Only the user supplies bullets. - **Falling back to "main" / "master" PR** — if HEAD is on the default branch, stop and tell the user to create a feature branch first.