generate-pr-descriptionlisted

# Generate PR description Generate the PR description without wrapping it in a code fence. Never post or edit it unless authorised under **4. Decide whether to update the PR**. ## 1. Establish the change - If given a PR number or URL, inspect its metadata, commits, and full diff. - Otherwise, inspect the PR associated with the current branch. If none exists, compare the current branch with the repository's default branch, including committed changes only. - Read enough surrounding code and documentation to understand behaviour rather than merely restating file changes. - Derive motivation from reliable context such as the PR, linked issue, commit messages, or repository documentation. Never invent motivation. If it remains unclear, ask one focused question before drafting. ## 2. Select content ### What Describe outcomes and observable behaviour, not the editing process. - Use 1–5 bullets; target at most 15 words each. - Keep one distinct change per bullet and group closely related implementation details. - Prefer product or user-facing behaviour over file names and implementation mechanics. - Include internal changes only when they are the substance of the PR or materially affect maintainers. - Omit tests, formatting, generated files, routine wiring, and incidental refactors from feature or fix PRs. - If the PR only changes tests, describe those test changes. - Do not claim behaviour unsupported by the diff. ### Why Write at most one extremely succinct sentence expla