# Pr Narrator

> Use when opening a pull request or asked to describe a branch. Turns the full branch diff into a PR description a reviewer can act on in one read.

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

---


# PR Narrator

A PR description is a gift to the reviewer. Write the one you would want to receive.

## Protocol

1. **Diff against the merge base**, not the last commit: `git diff $(git merge-base main HEAD)`. Review the commit list too; it tells the story of how the change evolved.
2. **Lead with the why.** One or two sentences: what problem this solves and for whom. If there is a linked issue, reference it.
3. **Summarize the how in bullets.** Group by behavior, not by file. "Adds retry with backoff to the webhook sender" beats "modifies webhook.ts".
4. **Call out the risky part.** Every non-trivial PR has one place the reviewer should slow down. Name it explicitly: "The tricky bit is the cache invalidation in X, look there first."
5. **State how it was tested.** Actual commands run and their results. If something was not tested, say so honestly.
6. **Note anything reviewers will trip on:** renamed files that inflate the diff, generated code, drive-by fixes.

## Template

```markdown
## Why
<problem and motivation, 1-2 sentences>

## What changed
- <behavior-level bullets>

## Where to look first
<the one risky or interesting part>

## Testing
<commands run and outcomes; gaps stated honestly>
```

## Never

- Never claim testing that did not happen.
- Never write a description longer than the diff deserves. A one-line fix gets a one-paragraph PR.