A good PR is a narrative. It tells you what changed, why it changed, and how the change was verified. It's the kind of document a thoughtful engineer could read in five minutes and understand completely, even weeks later when nobody remembers what the original Slack thread was about.
The single most predictive signal of PR quality I've seen is scope discipline. A PR that does one thing; one bug fix, one feature, one refactor is easier to review, easier to test, and easier to revert. PRs that do three things get merged in spite of their quality, not because of it.
I tell new engineers: if your PR description is empty, you haven't finished the work. The description is where the reader reconstructs your thinking. It's where they decide whether to trust the diff.
