ChatGPT Prompt to Write Clear Commit Messages and Pull Request Descriptions
This ChatGPT prompt for writing commit messages and pull request descriptions turns a raw code diff into a clean, reviewable summary a teammate can actually use. It's built for developers and engineering teams who write good code but write commit messages like "fix stuff" or leave PR descriptions blank, making code review slower and git history nearly useless six months later.
The prompt works by feeding the model your diff (or a plain description of the change) along with the ticket or issue it relates to, then asking it to separate the what changed from the why it changed — the part most engineers skip. It also asks for a short list of things reviewers should pay close attention to, like a schema change or a new external dependency, so nothing risky slides through review unnoticed.
Because commit history and PR descriptions are exactly the kind of long, repetitive writing task that benefits from a reusable structure, it's worth running this prompt through Prompt Optimizer in Coding mode first if you want to tighten the wording or adapt it to your team's specific PR template.
Prompt template
ROLE: You are a senior software engineer writing a commit message and pull request description for a code change.
CONTEXT:
- Code diff or summary of changes: [PASTE DIFF OR DESCRIBE THE CHANGE]
- Related ticket/issue: [TICKET ID AND TITLE, OR "NONE"]
- Commit convention to follow: [E.G. CONVENTIONAL COMMITS, FREEFORM, TICKET-PREFIXED]
- Audience for the PR description: [E.G. TEAM ENGINEERS, EXTERNAL CONTRIBUTORS]
TASK:
- Write a commit subject line under 72 characters that follows the specified convention.
- Write a 2-4 sentence commit body explaining what changed and, if context was given, why.
- Write a pull request description with these sections: Summary, Why This Change Is Needed, How It Was Tested, Risk/Areas to Review Closely.
- If the diff includes a schema change, new dependency, or breaking change, call it out explicitly under Risk/Areas to Review Closely.
CONSTRAINTS:
- Do not invent functionality, reasoning, or test coverage that wasn't stated or shown in the diff.
- Keep the PR description skimmable — short paragraphs or bullets, not dense prose.
- If information needed for a section is missing, write "Not specified" rather than guessing.
OUTPUT FORMAT: Commit Subject: [text] Commit Body: [text]
PR Description:
Summary
[text]
Why This Change Is Needed
[text]
How It Was Tested
[text]
Risk / Areas to Review Closely
[text]
Example input
Code diff or summary of changes: Changed the validateSession() function in auth/session.js to check token expiry against server time instead of client-provided time. Added a new getServerTime() helper that calls /api/time. Removed the old isTokenExpired() function which is no longer used anywhere.
Related ticket: AUTH-482 - Users can bypass session expiry by changing their system clock
Commit convention to follow: Conventional Commits
Audience for the PR description: Team engineers reviewing for security impact
Example output
Commit Subject: fix(auth): validate session expiry against server time
Commit Body: Session expiry checks previously trusted the client's system clock, letting users bypass expiry by changing their device time. validateSession() now calls a new getServerTime() helper to check expiry against server time instead. The unused isTokenExpired() function was removed.
PR Description:
Summary
Replaces client-side clock trust in session validation with a server time check. Adds getServerTime() and removes the now-unused isTokenExpired() helper.
Why This Change Is Needed
Fixes AUTH-482: users could extend or bypass session expiry by changing their local system clock, since validateSession() compared token expiry against client-reported time.
How It Was Tested
Not specified.
Risk / Areas to Review Closely
- New dependency on the /api/time endpoint inside validateSession() — confirm this endpoint has acceptable latency and a fallback if it's unreachable.
- isTokenExpired() was removed; confirm no other module still imports it.
- Any session-expiry unit tests that mocked client time will need to be updated to mock the new server time call.
When to use it
- You've finished a feature branch or bug fix and need to open a pull request with a real description
- Your team's git history is full of vague messages like "updates" or "wip" and you're trying to fix that habit
- You're squashing several small commits into one and need a single message that reflects the whole change
- You're onboarding a new team member and want to model what a good commit message looks like
Best practices
- Paste the actual diff or patch when you have it — a vague description of "I changed the login flow" produces a vague commit message back
- Always give the model the linked ticket number or issue title so it can reference the reason for the change, not just the mechanics
- Ask explicitly for a separate "why" section — models default to describing code changes line by line unless you ask for intent
- Set a hard line-length or character limit for the commit subject line (50-72 characters is the common git convention) since models will otherwise write long, run-on subject lines
Common mistakes
- Pasting only the file names that changed instead of the actual diff, which forces the model to guess at what happened
- Not specifying commit message convention (Conventional Commits, freeform, ticket-prefixed) so the output doesn't match what your team's tooling expects
- Letting the model invent a rationale for the change when none was given, instead of asking it to just describe the mechanics if intent isn't provided
- Using the same generated message for the commit and the PR description when they serve different audiences — a commit message is terse, a PR description should explain context and testing
FAQs
How do I write a good commit message with ChatGPT?
Give the model the actual diff, not just a summary, along with the related ticket and your team's commit convention. Ask it to separate the mechanical "what changed" from the "why" so the message stays useful in git history months later.
What's the difference between a commit message and a pull request description?
A commit message is terse — usually a one-line subject and a short body describing the change. A PR description is longer and written for reviewers, covering context, testing, and what to look at closely, since the audience and purpose differ.
Can AI write commit messages directly from a git diff?
Yes — pasting a diff gives the model concrete evidence of what changed, which produces far more accurate messages than describing the change from memory. Most models handle diffs of a few hundred lines well in a single prompt.
Should I use Conventional Commits format for AI-generated messages?
If your team already uses Conventional Commits (feat:, fix:, chore:, etc.) tooling for changelogs or semantic versioning, specify that convention explicitly in the prompt — otherwise the model will default to a freeform style that your tooling can't parse.
Which Cuelara tool can help me refine this prompt for my team's exact PR template?
Prompt Optimizer — its Coding mode is built for exactly this kind of structured, engineering-specific prompt and can adapt the template's sections to match your team's existing PR checklist.