Write pull request titles and descriptions from a branch diff – problem and evidence, approach, risk and blast radius, real test evidence, rollout and rollback, a reviewer guide, before/after screenshots for UI, and correct closing keywords – inside the repo's PR template when one exists.
Write pull request titles and descriptions from a branch diff - problem and evidence, approach, risk and blast radius, real test evidence, rollout and rollback, a reviewer guide, before/after screenshots for UI, and correct closing keywords - inside the repo's PR template when one exists. Use when someone asks "write the PR description", "open a PR for this branch", "summarize this branch for reviewers", or "my PRs keep getting rubber-stamped". Do NOT use for reviewing someone else's PR - use code-review-checklist instead - or for individual commit messages - use git-commit-writer instead.This is the skill's description: the text your AI reads to decide when the skill applies.
pr-description-writer/SKILL.md
---
name: PR Description Writer
description: Write pull request titles and descriptions from a branch diff - problem and evidence, approach, risk and blast radius, real test evidence, rollout and rollback, a reviewer guide, before/after screenshots for UI, and correct closing keywords - inside the repo's PR template when one exists. Use when someone asks "write the PR description", "open a PR for this branch", "summarize this branch for reviewers", or "my PRs keep getting rubber-stamped". Do NOT use for reviewing someone else's PR - use code-review-checklist instead - or for individual commit messages - use git-commit-writer instead.
---
# PR Description Writer
A pull request description tells a time-limited reviewer what to check, what could break, and what is already verified. The costly mistake this skill prevents is the description that restates the title ("Updates the checkout flow") or lists files, forcing the reviewer to reverse-engineer intent from the diff. They either rubber-stamp it or spend an hour rediscovering context the author had - and either way the riskiest part gets the least scrutiny.
## Operating procedure
### Step 1: Gather the inputs
Collect before writing:
- The full branch diff against its base: `git diff <base>...HEAD` (three dots, so you see only this branch's changes) and `git log <base>..HEAD --oneline`.
- The motivation: linked issue, ticket, incident, or the user's own explanation. If none exists, ask. Never invent a motivation.
- The repo's PR template, if any (`.github/pull_request_template.md`, `.github/PULL_REQUEST_TEMPLATE/`, or `docs/`). If one exists, fill its headings in its order; the sections below go inside it, not around it.
- How the repo merges. With squash merges the PR title usually becomes the commit subject (GitHub's default for multi-commit PRs); check the repo's squash-message setting and follow its commit convention.
- What testing was actually done: commands, results, manual checks. Ask; do not assume.
### Step 2: Classify the change and its risk
Sort changed files into core logic, mechanical (renames, generated files, lockfiles, snapshots), and tests. Then answer explicitly:
… load the full skill through Skill MeClick to play with sound.