Engineering

Changelog Prompt — User-Readable Change Logs

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

Open in Markdown Output Builder

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".

How to use this resource

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

FAQ

How does the changelog prompt stop security fixes from getting buried under 'Changed'?

Security is pinned as its own fixed section under the CONSISTENCY RULES, so the prompt forces a '## Security' heading in every release and forbids merging sections or rewording headings. A security-relevant change lands under Security by name instead of being quietly filed under '## Changed', even on a light release where you would be tempted to drop it.

Can this changelog prompt write the release notes for me straight from a git log?

It shapes a draft, it does not invent the changes. The TASK line states 'there is no source text to summarize' — you paste your raw release notes beneath the prompt and it returns them categorized into the five sections and rephrased as user-visible changes. Feeding it only a git log leaves it guessing, which is what the 'not a commit message' rule fights.

Where does the changelog markdown go after markdown-output-builder assembles it?

markdown-output-builder formats the prompt into clean markdown, but the actual changelog text comes from running that prompt in your own assistant, and the OUTPUT RULES make it copy-ready — 'return only the markdown document', no preamble, no code fences, starting at the '# ' title line. You paste the result into your CHANGELOG file or release page yourself; nothing auto-publishes.

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

Copy it as-is, or use Open in Markdown Output Builder to load it pre-filled and customize it with your own context.

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.

More resources from Markdown Output Builder

Resource

Markdown Output Prompt — Lock the Document Structure

The contract that stops AI documents from restructuring themselves: a pinned section skeleton, forced tables, and strict consistency rules.

Prompt Engineering

Resource

README Prompt Template

Overview, Installation, Usage, Examples, Configuration — the README skeleton with required, runnable code examples.

Engineering

Resource

API Documentation Prompt

Overview, Authentication, Endpoints, Error Handling, Rate Limits — endpoint docs in an identical structure, with parameter tables and runnable examples forced.

Engineering

Resources that pair well

Resource

Executive Summary Prompt

Summary, Why It Matters, What Happens Next — the executive summary contract for readers who will never open the source.

Operations

Resource

Force JSON Output from AI

Stop getting 'Sure, here is the JSON…' — the output-contract pattern that forces models to return only parseable JSON: schema, example, and a strict rule block.

Prompt Engineering

Resource

Fix Invalid JSON from AI

The JSON won't parse and you can't see why. Deterministic cause-sniffing — trailing commas, single quotes, unclosed brackets — and the repair prompt that fixes it.

Engineering

Related tools

Tool

Markdown Output Builder

Build prompts that produce documents in a fixed structure — headings, sections, and tables.

Structured Output

Workflows that use this resource

Workflow

AI Production Incident Workflow

Work a live production incident in the right order — triage and stabilize first, then find the cause, then write the summary and postmortem — so the fire is out before the writeup begins.

4 steps varies with the incident

Guides for this resource

Guide

How to Generate a Changelog With AI From Your Merged Changes

The changelog gets written last, from a list of PR titles someone else wrote for a reviewer who has moved on. Here is how to generate a changelog with AI that records what shipped for the people upgrading — and parks what nobody can stand behind yet.

Software Development with AI

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