I stopped writing PR descriptions. Here's what I did instead.
I opened 6 PRs last week. I wrote a good description for exactly one of them. The rest looked like this: "fix bug" "update styles" "wip" "changes" (my personal low point) And I'm not even ashamed —...

Source: DEV Community
I opened 6 PRs last week. I wrote a good description for exactly one of them. The rest looked like this: "fix bug" "update styles" "wip" "changes" (my personal low point) And I'm not even ashamed — I've seen senior engineers with 10 years of experience do the same thing. Here's why it happens: You just finished 3 hours of deep work. You know exactly what you changed and why. Writing it down feels like explaining a joke — the effort of articulating it kills the momentum. So you type something vague and hit submit. The reviewer then has to reverse-engineer your intent from the diff. They leave a comment asking what you changed. You explain it in the comment. Everyone wastes 20 minutes doing what the PR description should have done in the first place. So I started building a GitHub App to fix this for myself. It hooks into GitHub, reads the diff when you open a PR, and writes the description for you. Structured — what changed, why, how to test it, what to watch for. Takes about 4 seconds.