Article
“Yeah, no”: Using Claude Code to Write Concise PR Descriptions
April 24, 2026
When I moved to Minnesota, I didn’t know much about the place or its culture. All I knew were clichés like the Vikings, Prince, and the Mississippi. I remember asking a new friend if he wanted to play some disc golf with me. I will never forget what he said. He responded, “Yeah, no.”
That two-word answer captured a local style of brevity that I hadn’t heard before. To those in Minnesota and the Midwest, you already know this is a perfectly logical statement that encompasses the following.
- “Yeah,” meaning “I have received your invitation, and I appreciate that you invited me.”
- “No,” meaning “No thank you.”
And, this is extra Minnesota nice because it wastes no one’s time with unnecessary words!
In this article, I will describe how I sometimes use Claude Code to write a Pull Request (PR) description. I’ll share my suggestion for when to use Claude Code in PR descriptions, offer some tips, and share advice on how we can learn from our Midwest friends who want to respect our time. While I use Claude Code, this advice could apply to any AI coding agent.
Should you use Claude Code to write your PR Description?
The answer to this question typically depends on the size or complexity of the changes. If the changes are small and straightforward, the time to write a prompt is the same as the time to write the PR description. In that case, write the PR description without Claude.
Have you set up your ~/claude/CLAUDE.md?
Anthropic trained Claude on other people’s code and other people’s writings. You may have a particular style of writing or grammar rules that are important to you that would not come naturally to Claude. Since I’m a stickler for grammar, I have a “Proper Grammar” section in my user memory file located at ~/claude/CLAUDE.md. It includes rules like the following:
- Never drop articles or auxiliary verbs.
- Start sentences with capital letters and end with punctuation.
- Never end sentences with a preposition.
You may have other grammar rules or just writing styles that are important to you. Claude doesn’t always follow instructions in user memory, but including them still improves your odds.
Setting Up Claude For Success
The best way for Claude to write a good PR description of your changes is to provide any helpful information.
What issue are we solving?
Does Claude have access to your issue management system, for example, via the GitHub command-line client or Atlassian’s MCP server? Or is there a separate requirements document? Whatever you have, be prepared to reference or include this information in the prompt. Including this information allows Claude to explain why we are making the changes.
How to Review Changes with Claude
Key Consideration: Claude’s ability to track your changes depends on whether they fit within the context window. For larger changes, Claude may lose track of earlier edits once the window fills.
Best Practice: Avoid relying on prior context. Instead, ask Claude to reevaluate changes by referencing a Git command in your prompt.
Recommended Command: To review changes, use a git command that fits your scenario, such as this:
git --nopager diff mainThis command shows how your current state differs from the main branch, assuming no prior commits. Adjust the command as needed for your specific scenario.
Why This Helps: Including this information helps Claude explain the exact changes you’ve made, rather than relying on context, which may be full of superfluous discussion.
Prompting Claude
At this point, the essentials are available for Claude: what changed and why. You could ask Claude to write a PR description for you at this point. Claude may see that you have a PR template in your project and use it to draft a PR. Some PR descriptions are too involved for a one‑shot draft. Claude can handle the basics, but design, QA, and security checklists may require manual input beyond what Claude provides.
I often will start the PR draft in a temp file (e.g. ./tmp/pr.md) where Claude and I can work on it together. I’ll run through and fill in the items I can quickly complete, then leave TODOs for Claude. Then ask Claude to complete the TODOs in the file.
# Scope
TODO: Claude, give a concise summary of our changes, especially why we are making these changes.
# Implementation
- TODO: Claude, concisely list out the changes we made.
# Checklist
...Whether you are asking Claude to write a PR description from scratch or to collaborate on one, the most important keywords I have found are these: concise and concisely. By emphasizing “concise,” you encourage Claude to deliver a description that’s both professional and considerate. It’s about respecting your reviewer’s time by cutting out unnecessary verbosity.
Give Claude Examples
I have also found that Claude is very good at mimicking. So, I keep a few PR descriptions locally to give to Claude as a reference. That can also be helpful if you are doing a series of PRs that may be very similar.
Review Claude’s Work
It may be tempting to let Claude write the PR description and go with it. Yeah, no. Take a moment and review what Claude wrote.
- Did Claude get it right?
- Did Claude leave anything out?
- Did Claude add information that isn’t relevant to the review, e.g., some implementation detail from the context that makes no sense in the PR description?
If your experiences are similar to mine, that last case happens more than the others. So, reviewing Claude’s work means editing out irrelevant or excessive details and leaving only the pertinent info needed to help our reviewer.
Conclusion
Like hearing “Yeah, no” in Minnesota, brevity shows respect. Claude can draft a PR description, but it’s your job to trim it down to what matters. Use AI for speed, but don’t skip your own judgment. Keep the description concise, professional, and useful so reviewers can see exactly what changed and why.
