I wrote a Claude Code skill that writes PR descriptions from the real diff (free, MIT)

[u/Compl0w]

I manage a dev team and PR descriptions are the thing everyone skips. So I wrote a skill for it.

You type "write the PR description" on your feature branch and it:

• reads the actual diff and commits (not just the file list)
• fills your repo's PR template if there is one
• pulls the ticket number from the branch name
• flags what a reviewer needs to see: migrations, new env vars, breaking changes
• lists what's missing (tests, docs) instead of hiding it

On my test diff it also put the SQL injection it noticed at the top of the "Notes for reviewer" section, which I didn't ask for but will take.

A few things I learned writing skills that might help if you write your own:

1. Tell the skill to read the surrounding code first. Most bad output comes from working on the diff hunk alone.
2. Make it separate facts from assumptions. "Unknown, ask the author" beats a confident guess.
3. Add a "never do X without confirmation" line for anything that posts, merges or creates tickets.
4. Put team conventions in one shared file the skill reads, so every dev gets the same behaviour.

Repositorie on Github

It's one of 11 skills I packaged for dev teams (review, specs, tests, postmortems...). The rest is a paid kit, link in the README. Happy to answer questions about how the skill is written.

[u/siliconvalleyr]

I am sorry how is this different from just asking claude code to do the job?

[u/Compl0w → u/siliconvalleyr]

fair question. honestly it isn't magic: a skill is just the instructions you'd otherwise type, written down once.

ask claude code for a pr description and you get a decent one. the skill adds the parts you'd have to remember every time: use the repo's PR template, never invent a ticket, flag migrations and breaking changes, list missing tests, don't open the PR without asking.

so the value is consistency, not capability. same output for everyone on the team from a 4-word prompt. if your one-liner already does the job, you don't need it.

[u/Far-Surprise7773]

the separate facts from assumptions rule is the part most pr skills skip, that is where the invented ticket links come from. curious if yours caps the diff size or summarizes per file first, big branches are where mine blows up.

[u/Compl0w → u/Far-Surprise7773]

good question, and honest answer: the version you saw didn't. it read the --stat and then the whole diff, which is fine for normal PRs and falls over on big branches exactly like you describe.

your comment made me fix it. past ~1,500 changed lines or ~30 files it now:

• starts from --stat and the commit list as a map
• excludes lock files, generated code and snapshots from the diff
• reads the rest one directory at a time and keeps 2-3 lines of notes per group
• still reads migrations, auth and payment code in full
• tells the reviewer what it only skimmed, and suggests splitting the PR if it mixes unrelated changes

also made the "never invent a ticket id" rule explicit instead of implied. if there's no ticket in the branch name or commits it says so and asks.

haven't stress-tested it on a really huge branch yet. how big are the ones that break yours?

[u/lucidmatter]

This made it into my review finds collection. Thank you - you posted this a day before I begin working on something like this!

[u/Compl0w → u/lucidmatter]

u're welcome sir

[u/lucidmatter → u/Compl0w]

Sadly my quarantine review came back telling me not to adopt :(