Commit message prompts for commits, PRs and release notes

A good commit message prompt gives the model the diff, your convention and the reason for the change, and asks for a short summary line plus a body that explains why. Below are 12 prompts for the whole trail of a change: commit messages, pull request descriptions, release notes and changelogs.

The general coding prompts include one plain commit message prompt. The prompts here cover the rest: Conventional Commits, splitting a messy diff, rewriting history, PRs and release writing.

How to use these prompts

Copy a prompt into ChatGPT, Claude, Claude Code or Codex. Replace the blanks in double braces, or keep the default after the colon: {{limit:50}} means 50 unless you change it.

Get the input from Git rather than describing it:

• git diff --staged for the change you are about to commit
• git log --oneline main..HEAD for the commits on your branch
• git log --oneline v1.4.0..v1.5.0 for everything between two tags

The diff shows what changed. It almost never shows why. Add one sentence of context, like "users on Safari couldn't upload files", and the message gets much better. In an agent such as Claude Code or Codex, you can skip pasting: the agent can run these commands itself.

The Git docs for git commit give the classic shape: "a single short (no more than 50 characters) line summarizing the change, followed by a blank line and then a more thorough description." Every commit prompt below follows it.

How do you write a commit message with AI?

1. Conventional Commits message from a diff

For repos that use the Conventional Commits format so tools can pick versions and build changelogs.

Write a commit message for this diff using Conventional Commits 1.0.0.

Format: <type>(<scope>): <description>, then a blank line, then a body.
- Type is one of: {{types:feat, fix, docs, refactor, perf, test, build, ci, chore}}
- Scope is the area of the code, from this list if it fits: {{scopes:api, ui, db, auth}}
- Description in the imperative mood, lowercase, no period, under {{limit:50}} characters
- Body: why the change was made and anything a future reader needs. Wrap at 72.
- If the change breaks existing behavior, add ! before the colon and a
  "BREAKING CHANGE:" footer that says what users must do.

Why I made this change: {{reason}}

{{diff}}

In the spec, fix maps to a patch release, feat to a minor release, and a breaking change to a major release, which is why the type matters.

2. Split a messy diff into clean commits

When you did three things at once and want a history that reviewers and git bisect can follow.

This staged diff mixes several unrelated changes. Split it into a sequence
of small commits, each doing one thing and leaving the code working.

For each commit give:
- The files or hunks it includes
- The commit message ({{convention:plain imperative messages}})
- The order, with the reason (for example, the refactor goes before the
  feature that depends on it)

Then give the git commands to stage each commit, using git add -p where a
file belongs to more than one commit.

{{diff}}

3. Squash message for a whole branch

For the single commit that lands when you squash and merge. Work-in-progress messages like "fix typo" and "try again" should not survive.

I'm squashing this branch into one commit. Here are the branch's commits
and the final diff against {{base:main}}.

Commits:
{{git_log}}

Diff:
{{diff}}

Write one commit message that describes the end result, not the journey.
Summary line under {{limit:50}} characters in the imperative mood. Body:
what changed and why, in a few short paragraphs. End with
"{{trailer:Refs: #123}}" if I gave an issue number. Drop dead ends that
didn't make it into the final diff.

4. Interview me, then write the message

For changes where the why lives in your head: a subtle bug fix, a performance trade-off, a workaround for a vendor problem.

Here is a diff. Before writing a commit message, ask me up to three short
questions about why I made this change and what I considered instead. Wait
for my answers. Then write a commit message whose body records the reason,
the alternatives I rejected and anything that would surprise someone
reading this code in a year.

{{diff}}

How do you write a pull request description with AI?

5. PR description from the diff and the ticket

Reviewers read the description first. A good one cuts review time more than any other step.

Write a pull request description for this change.

Ticket or issue: {{ticket}}
Diff or commit list: {{diff}}

Sections:
## What
One or two sentences on what this PR does.
## Why
The problem it solves, linked to the ticket.
## How
The approach, and any choice a reviewer might question.
## Testing
How I tested it, as steps a reviewer can repeat. Leave a TODO if I didn't
say.
## Risk
What could break, and how to roll back.

Keep it under {{words:250}} words. Don't list every file.

6. Fill in your repo's PR template

If your repo has a template on its default branch, contributors see its contents in the body of every new pull request. The GitHub docs on PR templates list where it can live, such as .github/pull_request_template.md. Paste it in so the AI fills your sections, not its own.

Fill in this pull request template for the change below. Keep every
heading and checkbox from the template. Check a box only if the diff or my
notes show it's true; otherwise leave it unchecked and add a short note.
Write "N/A" for sections that don't apply instead of deleting them.

Template:
{{template}}

My notes: {{notes}}

Diff:
{{diff}}

7. Break a big PR into stacked PRs

When the diff is too large to review well. Smaller PRs get better reviews and merge faster.

This change is too big to review in one pull request ({{size:1,800 lines}}).
Propose how to split it into a stack of {{count:3 to 5}} smaller PRs that
can be reviewed and merged in order.

For each PR: a title, which files or parts it contains, why it can merge
on its own without breaking main, and a two-line description. Put
refactors and renames first, behavior changes after.

{{diff}}

How do you write release notes with AI?

8. User-facing release notes

For the GitHub Releases page, a docs site or an email. The reader is a user, not a contributor.

Write release notes for version {{version}} of {{product}} from this list of
merged pull requests and commits.

{{changes}}

Readers: {{audience:developers who use our library}}.
- Group under "New", "Improved", "Fixed" and "Breaking changes"
- Leave out internal changes (CI, refactors, dependency bumps) unless they
  affect users
- One line per item, starting with what the user can now do or no longer
  hits. Keep PR numbers at the end in parentheses.
- If an item's user impact is unclear, list it under "Check:" at the end
  instead of guessing

GitHub can draft a starting point for you. Per the automatically generated release notes docs, the generated notes list merged pull requests, contributors and a link to the full changelog, and you can group them by label with a .github/release.yml file. Paste that draft into the prompt above as {{changes}}.

9. Upgrade guide for breaking changes

Breaking changes need more than a line in the notes. Users need to know exactly what to change.

Version {{version}} has these breaking changes:

{{breaking_changes}}

Write an upgrade guide for people moving from {{from_version}}. For each
change: what changed, who is affected, a before and after code example,
and how to find affected code (a search pattern or error message). Order
by how many users each change will hit, most first. End with a short
checklist.

10. Short release announcement

For a team chat channel, a social post or the top of a newsletter.

Write a short announcement of {{product}} {{version}} for
{{channel:our team chat}}. Under {{words:80}} words. Lead with the one change
users will care about most, then two or three more in a short list, then a
link placeholder for the full notes. Plain language, no hype words, no
emoji unless I ask.

Release notes:
{{notes}}

How do you keep a changelog with AI?

11. Changelog entry in Keep a Changelog format

Keep a Changelog groups changes under Added, Changed, Deprecated, Removed, Fixed and Security, keeps an Unreleased section at the top, and puts the latest version first.

Turn these commits into a CHANGELOG.md entry in Keep a Changelog 1.1.0
format.

Version: {{version:Unreleased}}
Date: {{date}}

Commits:
{{git_log}}

Use only these headings, and only the ones that have items: Added, Changed,
Deprecated, Removed, Fixed, Security. Write each item for a human reader,
not as the raw commit message. Merge commits that describe the same change.
Skip commits with no user-visible effect.

12. Set up label-based release notes

For when you want GitHub to group the generated notes the way your changelog does.

Write a .github/release.yml for GitHub's automatically generated release
notes. Our pull request labels are:
{{labels:breaking, feature, bug, docs, dependencies, internal}}.

Map them to these categories in this order:
{{categories:Breaking changes, New features, Bug fixes, Documentation, Other changes}}.
Exclude PRs labeled
{{exclude:internal}} and PRs from {{bots:dependabot}} (use the exact bot login shown on their
pull requests). Use "*" as the
catch-all for the last category. Then list any label we should add so that
every PR lands in a category.

Which of these should become a skill or command?

Commit messages are the most repeated writing job in development, so prompt 1 or prompt 3 is a natural first skill. Paste one into the SKILL.md generator, and Claude Code or Codex will apply it whenever you ask for a commit. In Claude Code, a skill saved at .claude/skills/commit/SKILL.md also becomes a /commit slash command, because the folder name (or the skill's name field, if set) becomes the command, as the Claude Code skills docs explain. Before the PR goes up, run it through the code review prompts.

To keep these within reach, save them in Kipt. Tag them git, press ⌘K to find one, and fill the blanks for your limit and convention. The whole library is Markdown in a private GitHub repo you own.