Awesome Claude Prompts Unofficial

Draft release notes from git history

Have Claude Code compare two git tags or branches and draft release notes grouped into breaking changes, features and improvements for your readers.

Task: Draft release notes from git history · Other tasks

Fill in the details

Optional. A file whose format and tone the new notes should follow.

Copy your prompt

This site doesn't run Claude or show model output. Results depend on your input and the model you use.

2 required fields are empty.

What you type is kept in this tab's session storage so a reload doesn't lose it. Use "Clear this task" to remove it. Browsers can restore session data when they reopen tabs, so closing a tab isn't a guaranteed way to erase it.

When to use this template

  • A release is ready and you need a first draft of the notes from what actually changed, not from memory.
  • Commit messages are uneven, and you want someone to read the diffs behind the vague ones before they turn into vague release notes.
  • You publish notes for more than one audience and want each version written for its readers.

When not to use it

  • The project already generates notes automatically from structured commit messages and they are good enough. Use Claude to polish that output instead.
  • The release contains security issues that are not yet disclosed. Keep those out of a draft that may be shared early.
  • Your history is mostly squashed commits with titles such as "updates". Claude can read the diffs, but for very large releases the result will need careful checking.

Why this structure

  • Two refs, an older and a newer one, define exactly which changes are in scope, so the notes cover the release and nothing else.
  • Reading the diff when a commit message is unclear grounds each item in what changed rather than in how someone summarized it at the time.
  • Breaking changes come first and must say what readers have to do. Readers need that part most, and it is the costliest to leave out.
  • The readers setting changes the vocabulary and the level of detail, because end users, API developers and your own team need different notes from the same history.
  • Asking for unclassified commits and unmarked breaking changes surfaces the items you most need to check, instead of hiding them in the draft.
  • The final rule keeps this a draft: Claude does not commit, tag or publish, so nothing goes out before you have read it.

Example input (fictional)

Previous release (tag, branch or commit)
v2.3.0
New release (tag, branch or commit)
v2.4.0
Readers
developers who use our API or library, with names of changed functions and options
Existing notes to match
CHANGELOG.md

Follow-ups to send Claude

  • Write a short announcement version of these notes for the changelog page: three highlights and a link to the full list.
  • For each breaking change, add a before and after code snippet showing how to migrate.
  • Check the notes against the diff once more and remove any item that is not actually in this release.

Common mistakes

  • Comparing the wrong refs, for example the release branch against an old main. Check the two refs and the number of commits Claude found before reading the notes.
  • Publishing the draft unchanged. Claude can misjudge which changes matter to readers; read every breaking change entry yourself.
  • Using developer wording for end users. Choose the readers setting for the people who will actually read the notes.
  • Summarize a document: Turn a long document into a faithful summary: main point first, key points by importance, then decisions and open questions.
  • Code review prompt: Ask Claude to review a diff for supported issues, ordered by severity, with a location, impact and suggested fix for each finding.
  • Edit a draft for clarity: Make a draft clearer for a named reader while keeping your meaning and voice, with a short list of what changed and why.

See all templates

Sources