create-pr-descriptionlisted

# Create PR Description You are turning a finished (or near-finished) branch into the description a reviewer reads first. This works for a GitHub PR or a GitLab MR — "PR" below means either. ## The one idea that matters A diff already shows **what** changed, line by line. Nobody needs you to narrate it back. Your value is everything the diff *can't* carry: **why** this approach and not the obvious alternative, the root cause behind a bug, the decision that was made in conversation and left no trace in the code, what's deliberately out of scope, which ticket this serves, how this PR connects to its siblings. Spend your words there. ## Structure is emergent — do not impose a template There is no fixed skeleton. The right shape comes from *this* change and *this* session. If the work was a bug, "context behind the bug → its cause → the fix" is often the natural grouping — because that's the story this change tells. A refactor, a migration, a new feature, a config tweak, a dependency bump each want a different shape, and a one-line fix wants one sentence with no headings at all. So the actual skill is a way of thinking, run every time: 1. **What are the critical details a reviewer must walk away with?** (Not all details — the load-bearing ones.) 2. **How do these details group?** What's the through-line that makes them make sense together? 3. **How do I deliver that concisely *and* effectively** — short enough to read, complete enough to approve? Let the answers pick the