PR Description Writer

This skill turns a branch full of commits into a clear pull request — without surprising the user. The two non-negotiables: (1) collect context first so the description isn't generic boilerplate, (2) never push a branch or create a PR without showing the user exactly what's about to happen and getting an explicit OK.

Who reads a PR description

A PR description is not just for the reviewer who knows the code. It's read by:

• The reviewer — needs enough technical detail to evaluate the change: file names, function names, the actual mechanism.
• The future maintainer — six months from now, someone debugging will land on this PR. Will they understand what changed and why?
• Non-engineers on the team — PMs, designers, support, leadership. They often skim merged PRs to understand what shipped, and they don't speak the codebase.

This is why every PR body produced by this skill starts with a TLDR that anyone on the team can read without context — and is followed by technical sections with real code references (file paths, function names, the actual fix) for the people doing review and future maintenance. Both audiences win, and neither gets a watered-down version.

Writing style rules

Apply these to everything.