Create pull requests following Sentry conventions. Use when opening PRs, writing PR descriptions, or preparing changes for review. Follows Sentry's code review guidelines.
View on GitHubgetsentry/skills
sentry-skills
January 20, 2026
Select agents to install to:
npx add-skill https://github.com/getsentry/skills/blob/main/plugins/sentry-skills/skills/create-pr/SKILL.md -a claude-code --skill create-prInstallation paths:
.claude/skills/create-pr/# Create Pull Request Create pull requests following Sentry's engineering practices. **Requires**: GitHub CLI (`gh`) authenticated and available. ## Prerequisites Before creating a PR, ensure all changes are committed. If there are uncommitted changes, run the `sentry-skills:commit` skill first to commit them properly. ```bash # Check for uncommitted changes git status --porcelain ``` If the output shows any uncommitted changes (modified, added, or untracked files that should be included), invoke the `sentry-skills:commit` skill before proceeding. ## Process ### Step 1: Verify Branch State ```bash # Detect the default branch BASE=$(gh repo view --json defaultBranchRef --jq '.defaultBranchRef.name') # Check current branch and status git status git log $BASE..HEAD --oneline ``` Ensure: - All changes are committed - Branch is up to date with remote - Changes are rebased on the base branch if needed ### Step 2: Analyze Changes Review what will be included in the PR: ```bash # See all commits that will be in the PR git log $BASE..HEAD # See the full diff git diff $BASE...HEAD ``` Understand the scope and purpose of all changes before writing the description. ### Step 3: Write the PR Description First, check if the repository has a PR template: ```bash # Fetch PR template from GitHub gh repo view --json pullRequestTemplates --jq '.pullRequestTemplates[0].body' ``` If a PR template exists, follow its structure and fill in all required sections. Otherwise, follow this structure: ```markdown <brief description of what the PR does> <why these changes are being made - the motivation> <alternative approaches considered, if any> <any additional context reviewers need> ``` **Do NOT include:** - "Test plan" sections - Checkbox lists of testing steps - Redundant summaries of the diff **Do include:** - Clear explanation of what and why - Links to relevant issues or tickets - Context that isn't obvious from the code - Notes on specific areas that need carefu