Release notes prompt from commit history

Paste this into a chat window and replace each {{variable}}, or open it in the prompt builder to fill them in a form. Sections are marked with XML tags, which every major model reads well.

You write release notes for {{audience}}. You translate developer changes into what users will notice.

<context>
Commits or merged pull requests since the last release:
<changes>
{{changes}}
</changes>
</context>

<constraints>
- Group changes by what users notice: breaking changes, new features, improvements, fixes.
- Put breaking changes first, each with the exact upgrade step.
- Leave out internal changes users can’t see: refactors, CI, test-only and dependency bumps without a visible effect.
- Describe each change in terms of user impact, not implementation. Keep PR or issue numbers in brackets.
- Don’t invent features or details that aren’t in the change list. If an entry is unclear, leave it out and list it at the end under “Unclear”.
</constraints>

<output_format>
Markdown: a heading with the version, then one H3 per non-empty group, one bullet per change. End with an “Unclear” list only if there were unclear entries.
</output_format>

<task>
Write the release notes for version {{version}}.
</task>

You write release notes for {{audience}}. You translate developer changes into what users will notice.

<constraints>
- Group changes by what users notice: breaking changes, new features, improvements, fixes.
- Put breaking changes first, each with the exact upgrade step.
- Leave out internal changes users can’t see: refactors, CI, test-only and dependency bumps without a visible effect.
- Describe each change in terms of user impact, not implementation. Keep PR or issue numbers in brackets.
- Don’t invent features or details that aren’t in the change list. If an entry is unclear, leave it out and list it at the end under “Unclear”.
</constraints>

<output_format>
Markdown: a heading with the version, then one H3 per non-empty group, one bullet per change. End with an “Unclear” list only if there were unclear entries.
</output_format>

<context>
Commits or merged pull requests since the last release:
<changes>
{{changes}}
</changes>
</context>

<task>
Write the release notes for version {{version}}.
</task>

{{audience}}

Who reads the notes, such as “developers who use our Python SDK” or “non-technical customers of a web app”.

{{changes}}

The output of git log --oneline v1.4.0..HEAD, or the merged PR titles with numbers. PR titles are usually better input than raw commit subjects.

{{version}}

The version being released, such as 1.5.0.

{{audience}}

developers who use our TypeScript SDK

{{changes}}

a1f3c2e feat!: rename client.search() option "limit" to "pageSize" (#311)
b7d9e01 feat: add client.exportCsv() (#305)
c33a8f4 fix: retry on 429 using the Retry-After header (#309)
d0e1a77 ci: cache node_modules in GitHub Actions
e5b2f90 refactor: split http.ts into transport and retry modules
f81c6d3 fix: typo

{{version}}

2.0.0

What to look for. Expect the renamed option under breaking changes with a before-and-after snippet, the export and the 429 fix as user-facing items, and the CI and refactor commits left out. “fix: typo” should land in the Unclear list, because it doesn’t say where the typo was.

You write release notes for developers who use our TypeScript SDK. You translate developer changes into what users will notice.

<context>
Commits or merged pull requests since the last release:
<changes>
a1f3c2e feat!: rename client.search() option "limit" to "pageSize" (#311)
b7d9e01 feat: add client.exportCsv() (#305)
c33a8f4 fix: retry on 429 using the Retry-After header (#309)
d0e1a77 ci: cache node_modules in GitHub Actions
e5b2f90 refactor: split http.ts into transport and retry modules
f81c6d3 fix: typo
</changes>
</context>

<constraints>
- Group changes by what users notice: breaking changes, new features, improvements, fixes.
- Put breaking changes first, each with the exact upgrade step.
- Leave out internal changes users can’t see: refactors, CI, test-only and dependency bumps without a visible effect.
- Describe each change in terms of user impact, not implementation. Keep PR or issue numbers in brackets.
- Don’t invent features or details that aren’t in the change list. If an entry is unclear, leave it out and list it at the end under “Unclear”.
</constraints>

<output_format>
Markdown: a heading with the version, then one H3 per non-empty group, one bullet per change. End with an “Unclear” list only if there were unclear entries.
</output_format>

<task>
Write the release notes for version 2.0.0.
</task>

• All models

  Feed PR titles and descriptions rather than raw commits where you can. More context per change means fewer entries in the Unclear list.

• Gemini

  If you publish notes every release, add a previous release’s notes as a few-shot example. Google’s guide recommends examples for Gemini and warns that their formatting should be consistent, so use one that matches your current style exactly.

• Claude

  Anthropic recommends telling Claude what to do rather than what not to do. If the output is too long, “one line per change” works better than “don’t be verbose”.

• Commit message from a diffTurn a staged diff into a Conventional Commits subject and a body that explains why, not what.
• Pull request descriptionA PR summary with what changed and why, how it was tested, risks, and where reviewers should look.
• Write a READMEA project README from your code and notes: what it is, install, quick start, configuration and limits.

Edited the template? Compare your version with this one in the prompt diff, and count it for your model with the token counter. Browse all 29 prompt templates.