Prompt: Write a Commit Message and PR Description

A prompt for a clear commit message and pull request description built from your actual diff, explaining why the change was made.

Updated Sep 2026 PIS score 89
The prompt
Open in Studio
You are a senior engineer writing a commit message and PR description for review by teammates.

Objective: Write a commit message and PR description for the change below.

Context: What problem this change solves: {{WHAT PROBLEM THIS SOLVES}}. Anything reviewers should pay special attention to: {{REVIEWER FOCUS — e.g. edge case, performance, breaking change}}.

Constraints:
- Commit message subject line under 50 characters, imperative mood (e.g. "Fix", not "Fixed" or "Fixes")
- PR description must explain why the change was made, not just restate the diff
- List what was NOT changed if that's relevant context (e.g. "does not touch the API layer")
- Do not invent testing that wasn't described — if no testing is mentioned, say "testing not specified" instead

Output format: Return the commit message (subject + body), then a separate "PR description" section with "What changed", "Why", and "Reviewer notes".

Before finishing, check the subject line is under 50 characters and in imperative mood.

Diff or change summary:
{{PASTE DIFF OR CHANGE SUMMARY HERE}}

Example

Input

WHAT PROBLEM THIS SOLVES: Users on slow connections were seeing a blank page for up to 5 seconds because the loading spinner only appeared after the API call started, not immediately on navigation
REVIEWER FOCUS — e.g. edge case, performance, breaking change: The spinner timeout logic — it hides after 8 seconds even if the API call hasn't returned, to avoid an infinite spinner
PASTE DIFF OR CHANGE SUMMARY HERE: Moved the loading spinner state to trigger on route navigation instead of on API call start; added an 8-second timeout that shows an error state if the API still hasn't responded

Output

Show spinner on navigation, not API start

Previously the loading spinner only appeared once the API call
began, leaving users on slow connections looking at a blank
page for up to 5 seconds. The spinner now triggers immediately
on route navigation, with an 8-second timeout that shows an
error state instead of spinning indefinitely if the API hasn't
responded.
Show more
PR description

What changed: The loading spinner's trigger point moved from "API call started" to "route navigation began". Added an 8-second timeout that switches to an error state if the API still hasn't responded by then.

Why: Users on slow connections were seeing a blank page for up to 5 seconds before the spinner appeared, because it only showed once the API call had started, not on navigation.

Reviewer notes: Please check the 8-second timeout value — it's intended to avoid an infinite spinner on a hung request, but confirm that's long enough for legitimately slow, non-hung requests. Testing not specified.

Why it works

  • An imperative, under-50-character subject line matches git convention and stays readable in a one-line log view.
  • Requiring the 'why', not just the diff summary, gives reviewers the context needed to judge whether the change is the right fix.
  • Saying 'testing not specified' instead of inventing test coverage keeps the PR description honest about what reviewers still need to verify.

Why the basic version fails

“Write me a commit message for this change” from a diff alone usually produces a message that restates what the diff shows — “updated spinner logic” — without explaining why the change was needed, which is exactly the information a reviewer or a future git-blame reader actually wants.

What this prompt fixes

Requiring an imperative, under-50-character subject line matches standard git convention and stays readable in a one-line log view, rather than a long descriptive sentence that gets truncated. Requiring the “why” as a separate, required field forces the description to explain the reasoning, not just restate the diff. Saying “testing not specified” instead of inventing a testing claim keeps the PR description honest about what reviewers genuinely still need to check themselves.

Tips per model

  • Claude tends to stick to the 50-character subject limit strictly, which is useful since a message it writes will actually pass a commit-lint hook.
  • ChatGPT is good at drawing out the “why” from a described problem, even when the diff summary alone doesn’t state it explicitly.
  • Describe the real problem being solved, not just the code change — the “why” section is only as good as the reasoning you actually give it.