pr

name	pr
description	Create a GitHub pull request from current working changes. Handles all git states - uncommitted changes, no branch, unpushed commits, etc. Analyzes diffs and changesets to generate a PR with filled-in template. Opens the PR in the browser when done. Use when the user asks to create a PR, open a PR, submit changes, or push for review.
disable-model-invocation	true

Create Pull Request

Overview

Analyze the current git state, prepare changes for a PR, create it on GitHub with a well-crafted description, and open it in the browser.

Step 1: Assess Git State

Run these commands in parallel to understand the current state:

git status --porcelain
git branch --show-current
git log --oneline master..HEAD 2>/dev/null
git diff --stat master...HEAD 2>/dev/null
git stash list

Also check for existing PR on the current branch:

gh pr view --json url,state 2>/dev/null

Step 2: Handle Git States

Based on the assessment, follow the appropriate path:

No changes anywhere

If working tree is clean AND no commits ahead of master → inform user there's nothing to PR.

On master with uncommitted changes only

1. Ask the user for a branch name, or infer one from the changes (lowercase, hyphenated, concise)
2. Create and switch to branch: git checkout -b <branch-name>
3. Stage all changes: git add -A
4. Analyze the diff and write a commit message following the project's conventional commit style (see Commit Style below)
5. Commit the changes

On master with commits ahead (not yet on a branch)

1. Ask the user for a branch name, or infer one
2. Create branch at current position: git checkout -b <branch-name>
3. (The commits come along automatically)

On feature branch with uncommitted changes

1. Stage all changes: git add -A
2. Analyze the diff and write a commit message
3. Commit the changes

On feature branch, all committed, not pushed

Continue to Step 3.

PR already exists

Inform the user and provide the existing PR URL. Ask if they want to update it instead.

Step 3: Validate Changesets and Blog (before committing)

For user-facing changes (feat:, fix:, enhance:), check that changesets and blog updates exist:

ls .changeset/*.md 2>/dev/null | grep -v README
git diff --name-only master...HEAD 2>/dev/null
git status --porcelain

If changesets are missing or the draft blog post is unmodified, invoke the skill "changeset" to create them before proceeding. Skip this step for docs:, pkg:, internal:, demo: changes.

Step 4: Push to Remote

git push -u origin HEAD

Step 5: Analyze Changes for PR Description

Gather information for the PR body:

# Full diff against master
git diff master...HEAD

# Commit messages
git log --format='%s%n%n%b' master..HEAD

# Check for changesets
ls .changeset/*.md 2>/dev/null | grep -v README

Read any changeset files (.changeset/*.md, excluding README.md) — these contain curated descriptions of what changed and why. Use them as primary source material for the PR description.

Examine the diff to understand:

• Which packages are affected
• Whether there are test changes
• Whether there are doc changes
• The nature of the change (feature, fix, refactor, docs, internal, pkg)

Step 6: Create the PR

Use gh pr create with the project's PR template structure. Base branch is always master.

PR Title

Follow commit convention style:

• feat: <description> — new feature
• fix: <description> — bug fix
• enhance: <description> - improvements
• docs: <description> — documentation only
• pkg: <description> — dependency updates
• internal: <description> — internal tooling/infra
• demo: <description> — example app changes

Scope is optional, used for specificity (e.g., feat(rest):, fix(core):). Use imperative mood, under 72 chars. If the PR spans multiple types, use the most significant one. Commit messages follow the same convention.

PR Body Template

Fill in the template based on the analyzed changes. Remove HTML comments. Leave sections empty with "N/A" if not applicable. The Fixes # line should be omitted if there's no linked issue.

Fixes #<issue number if known, otherwise remove this line>

### Motivation

<Why this change exists. Pull from changeset descriptions, commit messages, and diff analysis.
Be specific: does it solve a bug? Enable a new use-case? Improve DX?>

### Solution

<High-level description of what was done. Key technical decisions and their rationale.
Mention affected packages, architectural choices, trade-offs.>

### Open questions

<   ,  "/"  >

Create Command

gh pr create --base master --title "<title>" --body "$(cat <<'EOF'
<body content>
EOF
)"

Capture the PR URL from the output.

Step 7: Open in Browser

gh pr view --web