# Pr

> Branch

- Skill: `steph-dove/pr` (Agent Skill)
- Install (CLI): `npx skillmds@latest add steph-dove/pr`
- Raw SKILL.md: https://api.skillmd.com/api/skills/steph-dove/pr/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: steph-dove (https://skillmd.com/u/steph-dove)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/steph-dove/pr

---


## Branch

```!
git branch --show-current
```

## Commit history vs base

```!
git log {{BASE_BRANCH}}..HEAD --oneline
```

## Files changed

```!
git diff {{BASE_BRANCH}}...HEAD --stat
```

## Instructions

Generate a PR description for the changes summarized above. Extract any ticket reference (e.g. FEAT-1234) from the branch name. Read CLAUDE.md for project conventions and any PR template rules. For key changed files, read them to understand the full context — do not paraphrase from the diff alone.

Output format:

```markdown
## Summary

<!-- 1-3 sentences explaining what this PR does and why -->

## Changes

<!-- Key changes, grouped logically. Aim for 3-6 bullets; one line each. -->

## Visual QA / Evidence (for UI & visual changes)

<!-- Include Before & After comparison table and responsive demo video -->
| Before | After |
| :---: | :---: |
| ![Before](image-url) | ![After](image-url) |

<!-- Demo Video: [Watch Full Interaction Video](video-url) -->

## Test Plan

<!-- How the changes were tested -->
- [ ] Tests pass locally
- [ ] Manually verified

## Notes

<!-- Anything reviewers should pay attention to, migration steps, feature flags, etc. -->
```

Rules:
- **Write for a reviewer who has 30 seconds.** Lead with what changed and why it matters; surface the one thing they must look at. The Summary should orient them before they open a single file.
- **Don't echo the diff.** The reviewer can read the diff. Summarize intent and group related changes — do not narrate every edit line by line.
- **Describe the current end state, not a changelog.** Write what the PR *is*, not a chronological story of how you got there ("first I tried X, then changed to Y"). If you revised an approach mid-branch, describe only the final shape.
- Be specific — reference actual file names, functions, and components.
- Focus on the "why" not just the "what".
- If the branch name has a ticket reference, include it in the summary.
- Keep it concise. No filler.
- **A short PR gets a short description.** One bullet under Changes is a fine answer for a one-file fix; padding it out to fill the template wastes the reviewer's time. Drop the Notes section entirely when there's nothing a reviewer needs flagged, rather than writing "N/A" or inventing something.
- If there are database changes, call them out explicitly.
- If there are new dependencies, mention them.

{{HUMANIZE}}

Write the output to `pr-description.md` in the repo root.

## When NOT to use

- The user wants the PR or MR opened for real — this skill only writes the description text into a file, so hand the file to whichever create command their host takes.
- The branch has no commits ahead of `{{BASE_BRANCH}}` — there's nothing to describe; tell the user instead.
- The user wants a release-notes-style summary spanning multiple PRs — different shape; don't try to fit it in this template.