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.
80
100%
Does it follow best practices?
Run evals on this skill
Adds up to 20 points to the overall score
View guide
Low
Low-risk findings worth noting
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.
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 listAlso check for existing PR on the current branch:
gh pr view --json url,state 2>/dev/nullBased on the assessment, follow the appropriate path:
If working tree is clean AND no commits ahead of master → inform user there's nothing to PR.
master with uncommitted changes onlygit checkout -b <branch-name>git add -Amaster with commits ahead (not yet on a branch)git checkout -b <branch-name>git add -AContinue to Step 3.
Inform the user and provide the existing PR URL. Ask if they want to update it instead.
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 --porcelainIf 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.
git push -u origin HEADGather 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 READMERead 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:
Use gh pr create with the project's PR template structure. Base branch is always master.
Follow commit convention style:
feat: <description> — new featurefix: <description> — bug fixenhance: <description> - improvementsdocs: <description> — documentation onlypkg: <description> — dependency updatesinternal: <description> — internal tooling/infrademo: <description> — example app changesScope 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.
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
<Any unresolved design questions, or "N/A" if none>gh pr create --base master --title "<title>" --body "$(cat <<'EOF'
<body content>
EOF
)"Capture the PR URL from the output.
gh pr view --webe823560
If you maintain this skill, you can claim it as your own. Once claimed, you can manage eval scenarios, bundle related skills, attach documentation or rules, and ensure cross-agent compatibility.