/open-pr

Create Pull Request

> **Project context:** Values in angle brackets below (e.g. `<scheme>`, `<JIRA_KEY>`, `<flag-key-enum>`) are resolved at runtime — detect them from the project (`xcodebuild -list -json` for the scheme, `git`/`gh` for repo & owner, the branch name for the Jira key, a codebase search for flag/font files), or ask if they cannot be inferred. This plugin ships no per-project config.

Create a pull request for the current branch following the the team's standard PR template.

**$ARGUMENTS** (optional): space-separated options. All are optional and can be combined in any order.

| Argument | Description | Default | |----------|-------------|---------| | `--base <branch>` | Base branch for the PR | `dev` | | `--draft` | Create as draft PR | off | | `--reviewer <user>` | Add reviewer(s). Can repeat: `--reviewer user1 --reviewer user2` | none | | `--label <name>` | Add label(s). Can repeat: `--label bug --label urgent` | none |

For convenience, a bare value (no `--` prefix) is treated as `--base <value>`.

**Examples:**

• `/open-pr` - PR to `dev`
• `/open-pr main` - PR to `main` (shorthand for `--base main`)
• `/open-pr --base feature/<JIRA_KEY>-XXXX-some-feature` - PR to another feature branch
• `/open-pr --draft` - Draft PR to `dev`
• `/open-pr --base feature/<JIRA_KEY>-XXXX --draft --reviewer jvlcapi` - Draft PR to a feature branch with reviewer
• `/open-pr --label bug --reviewer jvlcapi --reviewer other-dev` - PR to `dev` with label and two reviewers

Steps

1. Parse Arguments

Parse `$ARGUMENTS` to extract:

• **--base <branch>**: the target base branch, or `dev` if not provided. A bare value (no `--` prefix) is also treated as the base branch for convenience (e.g., `main` is equivalent to `--base main`)
• **--draft**: if present, add `--draft` flag to `gh pr create`
• **--reviewer <user>**: collect all `--reviewer` values, add each as `--reviewer <user>` to `gh pr create`
• **--label <name>**: collect all `--label` values, add each as `--label <name>` to `gh pr create`

2. Gather Branch Context

Run these in parallel:

# Current branch name
git rev-parse --abbrev-ref HEAD

# Check if branch has a remote tracking branch
git status -sb

# Untracked and staged files
git status

# Staged + unstaged diff
git diff HEAD

3. Determine Base Branch

Use the parsed base branch from $ARGUMENTS, or default to `dev`.

4. Analyze All Changes

Run these in parallel:

# Full diff between base and HEAD
git diff <base>...HEAD

# Commit log since diverging from base
git log <base>..HEAD --oneline --no-decorate

# Files changed
git diff <base>...HEAD --stat

5. Extract Jira Ticket from Branch Name

Parse the branch name to find the Jira ticket. Expected patterns:

• `feature/<JIRA_KEY>-XXXX-description` -> `<JIRA_KEY>-XXXX`
• `fix/<JIRA_KEY>-XXXX-description` -> `<JIRA_KEY>-XXXX`
• `refactor/<JIRA_KEY>-XXXX-description` -> `<JIRA_KEY>-XXXX`

If no ticket is found, ask the user.

6. Determine PR Type

Infer the PR type from the branch prefix and the nature of changes:

| Branch prefix | Default type | |---------------|-------------| | `feature/` | FEATURE | | `fix/` | FIX | | `refactor/` | REFACTOR | | `test/` | TEST | | `docs/` | DOCS | | `ci/` | CI | | `build/` | BUILD | | `perf/` | PERF | | `style/` | STYLE |

If the prefix is ambiguous, infer from the diff content.

7. Generate PR Title

Format: `[TYPE][<JIRA_KEY>-XXXX] Short description`

Generate a concise description (under 60 chars) summarizing the changes from the diff and commit messages.

8. Generate PR Body

Analyze the diff and commits to fill in each section of the template. Be specific and accurate.

• **Pull Request Checklist**: Leave unchecked (the author will check manually)
• **What is the current behavior?**: Describe what the code did before these changes
• **What is the new behavior?**: Describe what the changes introduce, referencing specific files/modules
• **Have any third-party libraries been added or changed?**: Check if `Package.swift`, `Podfile`, `Tuist/Dependencies`, or dependency files were modified. If none, write "No"
• **Does this change involve any AB testing?**: Check if any feature flag / experiment files were touched. If none, write "No"
• **Evidence**: see step 9 (auto-embed if screenshots exist) — only fall back to "N/A - To be added by the author" if no folder exists AND the user declines to capture them.
• **Other information**: Include any extra context worth mentioning (migration notes, follow-up tasks, etc.)

9. Embed Evidence Screenshots

Before pushing, attach evidence automatically — do not leave the user to drag-drop in the browser.

1. Look for screenshots in this order:

• `~/Desktop/<JIRA_KEY>-XXXX-evidence/` (the smoke-test convention) — if present, use every `.jpg`/`.png` inside.
• If absent, ask the user to point at the screenshots OR offer to capture them via the simulator (`xcodebuildmcp` / `ios-debugger-agent`).

2. Copy them into the repo and commit on a separate commit so the code commit stays focused:

   mkdir -p .github/screenshots/<JIRA_KEY>-XXXX
   cp ~/Desktop/<JIRA_KEY>-XXXX-evidence/*.{jpg,png} .github/screenshots/<JIRA_KEY>-XXXX/ 2>/dev/null
   git add .github/screenshots/<JIRA_KEY>-XXXX/
   git commit -m "[<TYPE>][<JIRA_KEY>-XXXX] Add PR evidence screenshots"

3. Reference each image in the PR body with a one-line caption above and an `<img>` tag pointing at the GitHub raw URL on the same branch (works in private repos for authenticated reviewers):

   <img src="https://github.com/<owner>/<repo>/raw/<branch>/.github/screenshots/<JIRA_KEY>-XXXX/01-foo.jpg" width="320" alt="short description" />

4. In the "Other information" section add: *"Screenshots committed under `.github/screenshots/<JIRA_KEY>-XXXX/` — happy to remove after merge if the team prefers."*

10. Push an