Create pr

Create PR

Prepare a GitHub PR that is scoped to the actual branch diff, follows the repo's PR template when one exists, and is useful to reviewers.

Defaults:

• Target GitHub and use gh for PR creation.
• Create a draft PR unless the user passes --open/-o, which creates a ready-for-review PR and opens it in the browser.
• Base branch: --base <branch> if given, otherwise the first of origin/main, main, origin/master, master, or the repo's default branch that exists.
• Use .github/PULL_REQUEST_TEMPLATE.md at the repo root unless the user passes a different template path.

Flags:

• --open / -o: skip the draft — create a ready-for-review PR — and open it in the browser. There is no flag for "ready-for-review but don't open a browser tab" or "draft but open in browser"; ask the user if they need that split.
• --base <branch>: base branch for the PR (default: see above).

Workflow

1. Check the current branch is eligible:

   • Run git branch --show-current. If it's main or master, stop:

     Refusing to create a PR from main/master. Check out or create a feature branch, then re-run /create-pr.

   • Run gh pr list --head <branch> --state all (or gh pr view <branch>). If an open PR already exists for this branch, stop:

     This branch already has an open PR: <URL>. Nothing to create.

   • If the existing PR is merged, stop:

     This branch's PR is already merged: <URL>. Nothing to create.

2. Resolve the base branch:

   • Use --base <branch> if the user supplied one.
   • Otherwise detect the most likely one in this order: origin/main, main, origin/master, master, then the repository's default branch if available. Use the resolved branch name (without an origin/ prefix) as the value for gh pr create --base.
   • If none can be detected and no --base was given, stop and ask the user for a base branch.

3. Choose the PR template:

   • Default: .github/PULL_REQUEST_TEMPLATE.md from the repo root.
   • Explicit path: resolve the supplied Markdown path from the repo root first, then current working directory.
   • If no template is found (default or explicit), don't stop — draft the PR body from scratch, structuring it however best fits the change (summary, changes, testing, etc.).

4. Inspect the change in parallel:

   • git status (no -uall)
   • git diff
   • git diff --staged
   • git log <base>..HEAD and git diff <base>...HEAD

5. Draft the body:

   • If using a template: keep its section order, required checkboxes, and wording. Remove irrelevant optional sections instead of writing N/A. Tick only materially affected areas; incidental files do not count.
   • If not using a template: cover what changed, why, reviewer entry points, material risks, verification, and anything intentionally out of scope.
   • Explain the problem and approach, not just a file-by-file listing.

6. Draft the title using the repo's style from the template or recent PRs. Prefer a specific, searchable, action-based title under 70 characters with no trailing period.

7. Verification must be truthful. Only mark commands as passing if they were actually run; otherwise use not run, blocked, or skipped (docs-only; low risk).

8. Create the PR:

   gh pr create --draft --base "$base" --title "$title" --body-file "$body_file"
   

   Omit --draft when --open/-o was passed (ready-for-review). Use --web only when the user wants manual browser creation.

   If creation fails (e.g. gh auth error, no remote, push required first), stop and report the actual error:

   PR creation failed: <error from gh>. Fix the issue above, then re-run /create-pr.

9. After creation, add suitable existing labels only (gh label list, then gh pr edit <num> --add-label ...). Common labels: bug, frontend, backend, tooling, config, docs, infra, refactor.

10. If --open was used, run gh pr view --web.

Output

TITLE:
<title>

PR:
<GitHub URL>