pr-open

name	pr-open
description	Open or create a pull request from the current branch with a clean, deduplicated summary
argument-hint	[optional target branch or PR number]

Open a new pull request (or view an existing one) from the current branch. Generates a clear summary and deduplicated checklist of changes, asks the user which branch to target and whether to request reviewers.

Usage

• pr-open — Create a PR from the current branch (asks for target branch)
• pr-open main — Create a PR targeting main
• pr-open dev — Create a PR targeting dev

Process

Step 1: Preflight checks

Run these commands in parallel:

git status
git branch --show-current
gh auth status

Verify:

• gh CLI is authenticated. If not, inform the user and stop.
• The working tree is clean. If there are uncommitted changes, warn the user and stop — do NOT auto-commit.
• Note the current branch name.

Step 2: Determine the target branch

If $ARGUMENTS contains a branch name, use it as the target branch.

If $ARGUMENTS is empty, ask the user which branch to create the PR against. Show common options and recent remote branches:

git branch -r --list 'origin/*' --sort=-committerdate | head -10

Present the branches as options and let the user pick. Default suggestion should be main if it exists, otherwise the most common base branch.

Step 3: Collect all changes

Fetch the full diff and commit history between the target branch and the current branch:

git log <target>..HEAD --pretty=format:"%h %s (by @%an)" --no-merges
git diff <target>..HEAD --stat

If there are zero commits ahead, inform the user there is nothing to open a PR for and stop.

Step 4: Build the PR title and description

Title:

• Derive a concise title from the branch name or the overall theme of the commits
• Keep it under 72 characters
• Use natural language (no conventional commit prefixes like feat: or fix:)
• Should clearly describe what this PR does

Description:

Build the PR body with these sections:

## Summary

[2-4 sentences describing what this PR does and why. Focus on the "why" and the user-facing impact.]

## Changes

- [Deduplicated checklist item 1]
- [Deduplicated checklist item 2]
- [Deduplicated checklist item 3]
...

Deduplication rules for the Changes list:

• Scan all commits between the target branch and HEAD
• Group commits that touch the same feature or area into a single checklist item
• If multiple commits describe the same change (e.g., "Add X" then "Fix X" then "Update X"), merge them into one item that describes the final state
• Each item should describe WHAT was changed, not individual commits
• Use simple, clear English
• Each line starts with a capital letter
• Do NOT include "fix typo", "fix lint", or other trivial followup commits as separate items — fold them into the parent change
• Attribution: if a change was made by someone other than the PR author, append (by @<author>) to that checklist item. If all changes are by the same person, omit attribution entirely.
• Keep the list concise — aim for 3-10 items. If there are more than 15 distinct changes, group related ones.

Do NOT include:

• AI attribution lines (no "Generated by Claude", "Co-Authored-By: Claude", etc.)
• Emoji in the description
• Empty sections

Step 5: Push the branch

Check if the branch is already pushed and up to date:

git rev-parse --abbrev-ref --symbolic-full-name @{u} 2>/dev/null
git status -sb

If the branch is not pushed or is ahead of remote, push it:

git push -u origin $(git branch --show-current)

If push fails, show the error and let the user decide how to proceed.

Step 6: Create the PR

gh pr create \
  --base <target-branch> \
  --head "$(git branch --show-current)" \
  --title "<title>" \
  --body "$(cat <<'EOF'
<the PR body from Step 4>
EOF
)"

If a PR already exists for this branch, detect it and show the existing PR URL instead of failing:

gh pr view --json url --jq '.url' 2>/dev/null

Step 7: Ask about reviewers

After the PR is created, ask the user:

"Should this PR request a reviewer?"

Present options:

• None (default) — skip reviewer assignment
• Select reviewer(s) — fetch collaborators and let the user pick:

gh api repos/{owner}/{repo}/collaborators --jq '.[].login'

If the user selects reviewers:

gh pr edit <pr-number> --add-reviewer <reviewer1>,<reviewer2>

Step 8: Output the PR link

Output a clean summary:

PR created!

Title:    <title>
Target:   <target-branch>
URL:      <pr-url>
Reviewer: <reviewer(s) or "None">

The PR URL is the most important output — make sure it is clearly visible.

Error Handling

• If gh CLI is not installed or not authenticated, inform the user and stop
• If there are uncommitted changes, warn and stop — do NOT auto-commit
• If the current branch equals the target branch, warn the user and stop
• If no commits ahead of the target, inform the user there is nothing to PR and stop
• If a PR already exists for the branch, show the existing PR URL
• If push fails, show the error and let the user resolve it
• If PR creation fails for any other reason, show the full error

Important Notes

• Do NOT add any AI attribution to the PR title, body, or commits
• Do NOT use conventional commit prefixes in the PR title
• Do NOT auto-commit — if the user has uncommitted changes, warn and stop
• The default reviewer is "None" — only assign if the user explicitly asks
• Keep the PR body clean, concise, and free of noise
• The Changes list must be deduplicated — never list the same change twice

User Arguments

$ARGUMENTS