| name | pull-request |
| description | Create a GitHub pull request for the current branch with minimal description and appropriate labels. |
Create Pull Request
Create a GitHub pull request for the current branch with minimal description and appropriate labels.
Description
This command creates a pull request by analyzing the commits on the current branch, generating a concise summary of changes, and applying relevant labels from the repository.
- Keep descriptions minimal and focused
- Do NOT add emojis to PR titles or descriptions
- Add appropriate labels based on the changes (e.g., logging, development, feature request, bug, etc.)
Usage
pull-request
Steps
- Detect the VCS: run
jj root to check if the repo uses Jujutsu (jj). If it succeeds, use jj commands; otherwise fall back to git.
- jj: run
jj bookmark list to find the current bookmark, then jj log --no-pager -r "main..<bookmark>" and jj diff -r "main..<bookmark>" --stat for commits and scope. Use jj git remote list to find the GitHub remote for gh commands (e.g. --repo owner/name).
- git: run
git log master..HEAD --oneline and git diff master...HEAD --stat.
- Run
gh label list (with --repo if needed) to see available labels
- Analyze the commits and changes to create a summary
- Ensure the branch/bookmark is pushed to the remote before creating the PR
- Create PR with
gh pr create including:
- Short, descriptive title
- One-paragraph description of the changes
- Brief bullet-point summary (if applicable)
- Appropriate labels based on the nature of changes
Example
gh pr create --title "Upgrade Sentry browser packages and configuration" --body "$(cat <<'EOF'
This PR upgrades Sentry's browser packages to the latest versions and configures the latest integrations for improved error tracking. It also adds user data to the initial scope and wires up server-side Sentry configuration for view rendering.
EOF
)" --label "logging,development"
Notes
- Ensure the branch is pushed to remote before creating PR
- Use comma-separated labels:
--label "label1,label2"
- For the PR's subject line, use the imperative mood (e.g. "Add a Foo to the Bar feature")
- Do not use emojis or bullet lists in the PR's body
- Keep the PR's body concise
- Don't be overly technical unless the PR itself is technical (e.g. a very finicky bug fix)
- Reference any relevant issues where possible (check the messages of the commits included in the PR)
- Do NOT list the files, classes or types that were changed in the PR
- Do NOT add a Claude co-authorship footer to the PR body
- Always use American English