# Pr Storyteller

> MUST be used whenever the user asks to write a PR title, PR description, or test plan for the current branch. Always invoke this instead of writing a PR description manually.

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

---


Generate PR text (title, description, test plan) for the current branch. Do not open a PR or push anything — only output markdown text.

Steps:

1. Determine the base branch: use `$1` if provided. Otherwise try `main`; if `main` does not exist as a branch, use `master`.
2. Run `git merge-base <base> HEAD` to get the merge-base commit.
3. Run `git log <merge-base>..HEAD --no-merges --pretty=format:%s` to get commit subjects since the merge-base.
4. Run `git diff <merge-base>..HEAD --stat` to get the changed files and diff stat.
5. From these, generate:
   - **Title**: a single-line, conventional-commit-style summary of the overall change (e.g. `feat: add X`, `fix: correct Y`). Base it on the overall theme of the commits, not just the first commit.
   - **Description**: short bullet points synthesized from the commit subjects. Group related/overlapping commits into single bullets instead of listing every commit verbatim. Keep it factual — only describe what the commits and diff actually say.
   - **Test Plan**: a checklist inferred mechanically from the file types/areas touched in the diff stat. Examples of the mapping to apply:
     - Test files changed (`*test*`, `*spec*`) -> "Run the test suite"
     - Config/dependency files changed (`package.json`, `*.lock`, `requirements.txt`, `Cargo.toml`, `go.mod`, Dockerfile, CI config) -> "Verify build/install still works"
     - UI/frontend files changed (`.tsx`, `.jsx`, `.vue`, `.css`, `.html`) -> "Manually verify affected screens"
     - Docs changed (`.md`, `docs/`) -> "Proofread rendered docs"
     - Otherwise/generally -> "Review the diff for correctness"
     Keep items generic and mechanical — do not invent specific test scenarios that require domain knowledge of the change.
6. Output the final result as markdown ready to paste directly into a PR, in this shape:

```
## Title
<title>

## Description
- <bullet>
- <bullet>

## Test Plan
- [ ] <item>
- [ ] <item>
```

Do not include any other commentary before or after the markdown output.