---
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:

```bash
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:

```bash
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:

```bash
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:

```markdown
## 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:

```bash
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:

```bash
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

```bash
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:

```bash
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:

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

If the user selects reviewers:

```bash
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