Engineering

Changelog Prompt — User-Readable Change Logs

Added, Changed, Fixed, Removed, Security — changelog entries written as user-visible changes, not commit messages.

Overview

Changelogs written from commits read like commits: "refactor auth flow" tells users nothing. This setup generates changelog entries in the five standard sections under Strict consistency — the categories never drift — with the two rules that make changelogs readable: write each entry as a user-visible change, and one change per bullet, never bundled. The Security section is pinned so security-relevant changes can't be quietly filed under "Changed".

Workflow

Draft below, structure above
Paste the raw release notes under the prompt; the entry comes back categorized and user-phrased.
Check the phrasing rule
"User-visible change, not a commit message" — the single rule that makes changelogs worth publishing.
Keep Security pinned
Strict mode means the section appears even when empty-ish releases tempt you to drop it.

Why This Works

The five-category convention is what changelog readers already expect
User-visible phrasing reframes every entry around impact
One-change-per-bullet keeps entries scannable and linkable

Best for

Teams shipping regular releases
Public changelogs read by non-developers
Release managers tired of commit-message changelogs

Not for

Generating the changes themselves from a git log — feed it the draft, it shapes the document
Diffing two prompt versions — that's the Prompt Version Diff

Use cases

Turning release notes drafts into clean changelog entries
Keeping the same categories across every release
Making security changes visible instead of buried

Customize This Resource

Opens this setup in Markdown Output Builder. Generate to get the full markdown prompt — then adjust the sections, table rules, and consistency level.

Open in Markdown Output Builder

Prompt Template

TASK
Write release changelog entries users can actually read.
Produce a new markdown document — there is no source text to summarize.

DOCUMENT
The document is a changelog entry.
- Write each entry as a user-visible change, not a commit message.
- One change per bullet — never bundle unrelated changes.

DOCUMENT STRUCTURE
Start with one "# " title line, then use exactly these sections, in this order:
## Added
New capabilities.
## Changed
Behavior changes to existing features.
## Fixed
Bug fixes.
## Removed
Features taken away.
## Security
Security-relevant changes.

MARKDOWN RULES
- One "# " title at the top; every section below it is a "## " heading.
- Use markdown lists for enumerations — no walls of prose.
- No HTML tags — pure markdown.

TABLE RULES
- Do not use tables — present comparisons as nested bullet lists.

CODE RULES
- Do not include code blocks.

CONSISTENCY RULES
- Use every section defined above.
- Keep the section order exactly as given.
- Do not omit headings, even when a section is short.
- Do not merge sections.
- Use the exact heading text as defined — no rewording.

OUTPUT RULES
- Return only the markdown document — no preamble, no closing commentary.
- Start directly with the "# " title line.
- Do not wrap the document in code fences.

Related Resources

Explore more resources that work well with this one.

Used in Playbooks

Complete workflows that include this resource as a step.

AI Production Incident Workflow Workflow · 4 steps

Tip: Save time by exploring related resources and tools that integrate with this workflow.

Explore all resources