Help us improve
Share bugs, ideas, or general feedback.
From sentry-skills
Creates, refreshes, and rewrites PR titles and descriptions following Sentry conventions. Requires GitHub CLI.
npx claudepluginhub getsentry/skills --plugin sentry-skillsHow this skill is triggered — by the user, by Claude, or both
Slash command
/sentry-skills:pr-writerThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
Create pull requests following Sentry's engineering practices.
Creates structured pull requests with Sentry's engineering practices. Analyzes committed branch diffs and generates descriptions covering what changed, why, and reviewer context.
Creates, updates descriptions, and adds comments to GitHub pull requests using file-based drafts for safety, emphasizing material impact and reviewer-friendly communication.
Drafts conventional commit PR titles and Shopware 5-section descriptions for core PRs targeting trunk. Analyzes branch against trunk, uses session context, asks for missing info.
Share bugs, ideas, or general feedback.
Create pull requests following Sentry's engineering practices.
Requires: GitHub CLI (gh) authenticated and available.
Before creating a PR, ensure all changes are committed to a feature branch, not to the default branch.
# Check current branch and for uncommitted changes
git branch --show-current
git status --porcelain
If on main or master, create a feature branch and move any uncommitted changes onto it before committing — a PR cannot be opened from the default branch against itself. If there are uncommitted changes, commit them on the feature branch before proceeding.
# Detect the default branch — note the output for use in subsequent commands
gh repo view --json defaultBranchRef --jq '.defaultBranchRef.name'
# Check current branch and status (substitute the detected branch name above for BASE)
git status
git log BASE..HEAD --oneline
Ensure:
Review what will be included in the PR:
# See all commits that will be in the PR (substitute detected branch name for BASE)
git log BASE..HEAD
# See the full diff
git diff BASE...HEAD
Understand the scope and purpose of all changes before writing the description.
If the current branch already has an open PR, inspect the current title and body before rewriting either one:
gh pr view PR_NUMBER --json number,title,body,url,baseRefName,headRefName
Treat the current PR title and body as inputs, not source of truth. Compare them against the current diff, not the diff from when the PR was first opened.
When refreshing a PR:
If the branch already has an open PR, refresh it after material follow-up changes even if the user did not explicitly ask for a PR edit.
Refresh when follow-up commits change reviewer expectations, such as a scope change, a new implementation approach from review feedback, or new context the current title/body no longer explains. Skip trivial edits like typos or rename-only diffs.
Write or re-evaluate the title before finalizing the body.
Title format: <type>(<scope>): <Subject> or <type>: <Subject>.
Allowed types: feat, fix, ref, perf, docs, test, build, ci, chore, style, meta, license, revert.
Rules:
[codex], [claude], [ai], [bot], or [wip]update, cleanup, misc, fix stuff, or address feedbackRewrite invalid titles before creating or updating the PR:
[codex] Paginate replay segment downloads -> fix(replay): Paginate recording segment downloadsUse this test on updates: if a reviewer read only the title, would they still form the right expectation about the current diff? If not, rewrite it.
Write a reviewer-facing cover note, not a generated changelog.
Default to 1-2 short paragraphs:
<What changed and what effect it has.>
<Why this approach, tradeoff, risk, or review focus matters, if it is not obvious from the diff.>
Write enough context that a reviewer can predict the shape and intent of the diff before opening it. The body should answer the questions that code alone will not: why the change exists, what behavior changes, what tradeoff was chosen, and what deserves careful review.
Use structure only when the change needs it:
| Change shape | Useful body shape |
|---|---|
| Small obvious change | one concise paragraph; no headings |
| Bug fix | problem/root cause/fix in prose; headings only if the body would be confusing without them |
| API, schema, payload, config, permissions, or CLI change | before/after fenced blocks when direct comparison is clearer than prose |
| Performance or reliability change | include measured impact or expected tradeoff when known; do not invent numbers |
| Broad, generated, or cross-cutting change | explain the organizing principle and where reviewers should start |
| Review feedback update | rewrite the whole body around the current final diff; do not append a progress log |
Rules:
Hard constraints:
XXXXX, <issue>, or TODO.When updating, rewrite the body as one coherent description of the current PR.
For a new PR, create a draft with the rewritten title and body:
gh pr create --draft --title "<type>(<scope>): <description>" --body "$(cat <<'EOF'
<description body here>
EOF
)"
Before running the create or update command, strip any issue reference not backed by known context. Never emit placeholder IDs (XXXXX, <issue>, TODO).
For an existing PR, patch the title and body after you have re-evaluated both. If the current title still fits, keep it intentionally rather than skipping title review.
gh api -X PATCH repos/{owner}/{repo}/pulls/PR_NUMBER \
-f title='fix(scope): Preserve replay segment cursor' \
-f body="$(cat <<'EOF'
<updated description body here>
EOF
)"
The AI Customizations section in the sessions sidebar now starts collapsed so
it does not consume space before users need it. Expanding the section keeps the
same persisted preference behavior as before.
Alert updates and resolves now reply to the original Slack message instead of
creating a new channel message. This keeps the notification timeline grouped in
one thread and reduces channel noise.
Inactive authenticated users now go to account reactivation before the login
view honors a `next` URL.
The GET login path could previously bounce an inactive user between
`/auth/login/` and a protected view because it redirected authenticated users
without checking `is_active`. The POST path already handled this case, so this
applies the same guard to the GET redirect and covers the loop with a regression
test.
Run logs now write one versioned record per analyzed chunk instead of one
large skill-level record. This lets `warden runs follow` show findings as
chunks complete while preserving durable run reconstruction at finalization.
Before, each line represented a full skill result:
```jsonc
{
"run": {...},
"skill": "security-review",
"summary": "Found 2 issues",
"findings": [...],
"files": [...]
}
```
After, each line represents one chunk result:
```jsonc
{
"schemaVersion": 1,
"run": {...},
"skill": "security-review",
"chunk": {
"file": "src/api/auth.ts",
"index": 1,
"total": 2,
"lineRange": "42-45"
},
"status": "ok",
"findings": [...]
}
```
Duplicate validation code from the alerts, issues, and projects endpoints now
lives in a shared validator class without changing endpoint behavior.
Future validation rules can now be added in one place instead of being copied
across each endpoint.
The admin layout now holds together at narrow viewport widths: the shared
header, details grid, result table, and sidebar wrap, collapse, or scroll
instead of overflowing the viewport. The changes are intentionally limited to
responsive layout behavior; table column prioritization is left out because it
needs product judgment.
Review the shared layout and table wrappers first, then check individual
component breakpoints for regressions.
Reference issues in the PR body:
| Syntax | Effect |
|---|---|
Fixes #1234 | Closes GitHub issue on merge |
Fixes SENTRY-1234 | Closes Sentry issue |
Refs GH-1234 | Links without closing |
Refs LINEAR-ABC-123 | Links Linear issue |
These are syntax examples — do not copy example IDs into a real PR body.
Note: gh pr edit is currently broken due to GitHub's Projects (classic) deprecation.