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.
I'm still building it. Calling it PRDraft.
Honest question for this community: is this a real pain
for you, or have you just accepted it as part of the job?
If you want early access when it's ready: https://prdraft.carrd.co
Top comments (1)
I wanted to ask like what makes it different from me asking my cli to generate a description based on the commits, + how would you tackle PR's in which the description is very strict incase of opening a pr on any opensource project with strict contribution guidelines, if you could tackle that, it'll be great! :D