Draft a what-and-why PR description before every PR, tracker or not
Whenever an implementation is finished and about to become a pull request — whether or not there is a linked Jira/tracker ticket — draft a short plain-English PR description ready to paste into the PR body, alongside the usual 2-3 commit-message options. But hold these back until the pre-PR review has run: the developer runs the `pre-pr-review` command after every coding session, so do not volunteer the commit messages or PR description at the moment coding finishes — wait until that review is done and its findings are addressed, then produce them together. The description should be a few sentences covering: what changed at a user- or system-visible level, why (the motivation, and the ticket key if one exists), and any notable caveats, follow-ups, or testing notes. Never write it as a dry restatement of the diff or a bullet list of touched files (updated X.ts, modified Y.tsx) — that tells a reviewer nothing they cannot already see in the file list. Only draft the description; never post it, comment on the PR, or open/merge it yourself — the developer pastes it in when they create the PR.