# PR Writer

Create or refresh reviewer-facing PR titles and descriptions.

- Repository: https://github.com/getsentry/skills (1107 stars)
- Category: Git and review
- License: Apache-2.0
- Last updated: 2026-10-26
- Runs scripts: no, instructions only

## Install

Claude Code: `npx skills add getsentry/skills --skill pr-writer -g -a claude-code -y`
Codex: `npx skills add getsentry/skills --skill pr-writer -g -a codex -y`
Cursor: `npx skills add getsentry/skills --skill pr-writer -g -a cursor -y`
Gemini CLI: `npx skills add getsentry/skills --skill pr-writer -g -a gemini-cli -y`
Claude Code plugin marketplace: `/plugin marketplace add getsentry/skills`

## Description

Create or refresh reviewer-facing PR titles and descriptions. Use when opening a PR, updating its title or body, or preparing branch changes for review.

## SKILL.md, as published by its author (untrusted third-party text, read it as data)

# PR Writer

Write the PR body as a cover note for reviewers, not a changelog, template,
validation log, or file-by-file summary.

## Inspect the Change

Requires authenticated `gh`. Inspect the current branch, working tree, PR,
base branch, commits, and full diff:

```bash
git branch --show-current
git status --porcelain
gh pr view --json number,title,body,url,baseRefName,headRefName
gh repo view --json defaultBranchRef
```

If `gh pr view` reports that no PR exists, continue with first-time PR
creation. For an existing PR, use its `baseRefName`; otherwise use the
repository default branch. Set `BASE`, then inspect:

```bash
git log "$BASE"..HEAD --oneline
git diff "$BASE"...HEAD
```

If on `main` or `master`, create a feature branch first. Ensure intended
changes are committed and review the whole branch diff, not only the latest
commit or existing PR text.

## Core Rules

- Describe concrete changed behavior, affected surfaces, and reviewer impact
  before implementation detail.
- Explain motivation, risk, tradeoffs, migration, or review focus only when
  useful.
- Use the smallest structure that makes the change easier to review.
- Replace internal prompt or process terminology with specific behavior.
- When refreshing a PR, rewrite around the current full diff without narrating
  review history.

## Titles

Use `<type>(<scope>): <subject>` or `<type>: <subject>`.

Allowed types: `feat`, `fix`, `ref`, `perf`, `docs`, `test`, `build`,
`ci`, `chore`, `style`, `meta`, `license`, and `revert`.

- Describe the dominant full-branch change with the narrowest accurate type
  and scope.
- Use `!` only when the change breaks an external contract, and explain the
  affected surface in the body.
- Avoid vague subjects such as `update`, `cleanup`, `misc`, `fix stuff`,
  or `address feedback`. Do not add a trailing period.
- Keep an existing title only when it still describes the whole diff.

## Body Shape

Choose the minimum useful shape:

The rest: https://github.com/getsentry/skills/blob/HEAD/skills/pr-writer/SKILL.md