A Customer-Facing Release Notes Prompt That Drops the Jargon

A customer-facing release notes prompt has one job the engineering changelog never had: talk to someone who doesn't read code. "Refactored the auth middleware" means nothing to a user. "Sign-in is faster and stays logged in longer" means something. Same change, different audience, and the gap between them is where most release notes fail.

Plenty of tools generate notes straight from your git log. They're accurate and they read like a diff. The round-up posts compare ten of them on features and pricing, then stop. None of them give you the one thing you actually reuse: a prompt that takes that raw changelog and rewrites it for the person clicking "what's new."

This covers a prompt that produces several audience-tuned versions from one input, the model behavior that trips it up, and the rule that keeps it honest.

What you can do with this prompt

• Turn a list of merged PRs into release notes a non-technical user understands
• Produce an 80-word in-app "what's new" panel and full notes from one run
• Generate an email subject line that doesn't sound like a commit message
• Group changes by user outcome instead of by code area
• Strip internal jargon, ticket numbers, and service names automatically
• Keep a developer changelog and a user changelog in sync from one source

Why one input should produce several outputs

The same release reaches users through different surfaces. An in-app panel needs to be short and skimmable. The email subject line gets one sentence. The full notes page can run longer. Writing those three by hand from the same changelog is busywork, and doing them separately is how they drift out of sync.

A good prompt produces all three from one input with a locked contract for each. That's the part the model-agnostic skeletons online gesture at but don't lock down.

Anatomy of the prompt

Variables
  {{changelog}}     — raw merged PR titles or changelog lines
  {{product_name}}  — what users call the product
  {{tone}}          — "plain" or "playful"

Prompt
  Role: product communications writer for {{product_name}}.
  Rule: describe only changes present in {{changelog}}. Do not
  infer or invent features. Lead every item with the user outcome,
  not the implementation. Drop ticket IDs and service names.

Output contract (return all three, in this order)
  IN-APP (max 80 words, 3 bullets, outcome-first):
  EMAIL SUBJECT (one line, under 60 chars):
  FULL NOTES (grouped under New / Improved / Fixed):

The "describe only changes present in the input" line is the guardrail. Without it, a sparse changelog tempts the model to pad with plausible-sounding features. With it, the model stays inside the facts you fed it.

How models behave on this specific job

Behavior on rewriting a changelog for users, not on writing in general:

Neither model invents wildly when you feed real PR titles and add the no-inference rule. Strip the rule and both will help themselves to features that don't exist. The word cap is the other reliable failure: GPT-4o treats "max 80 words" as a polite suggestion, so restate it.

1. Pull the raw changelog

Export merged PR titles or your CHANGELOG.md delta since the last release. Don't summarize it first. The prompt wants the raw list so it can group by outcome itself.

2. Set the product name and tone

{{product_name}} is what users call it, not the repo name. {{tone}} defaults to plain. Playful is fine for consumer apps and wrong for anything an admin reads under deadline.

3. Run and read against the source

Put the three outputs next to the changelog. Every claim in the notes should trace to a line in the input. If something doesn't, the model invented it. Cut it.

4. Trim the in-app panel

Even with the cap, the panel often wants trimming. Three bullets, outcome-first, no filler. Users read this one mid-task, so every word costs attention.

5. Reuse across the release

The full notes feed the docs page, the email line feeds the campaign, the panel feeds the app. One run, three surfaces, no drift.

Variables you'll set

An opinion worth holding

Don't generate user release notes from commit messages alone. Commits describe code; they're written for the next engineer, not the user, and rewriting them into outcomes means the model is guessing at intent it can't see. Feed it the merged PR titles plus a one-line "what shipped" note per item, and the output gets sharply better. The extra thirty seconds of input beats an hour of editing hallucinated benefits later. Garbage in, confident garbage out.

The deeper point: the developer changelog and the user changelog are two products of one release, and they should come from one source. Keep them separate and they diverge by the second release.

Getting started

1. Copy the prompt skeleton into your model.
2. Paste real merged PR titles into {{changelog}}.
3. Set {{product_name}} and leave {{tone}} on plain.
4. Run it, then check every line against the changelog for invented features.
5. Trim the in-app panel to three tight bullets.
6. For a repeatable workflow that ships the developer and user versions from one source, use a pack built for it, like the Release Communications Agent Pack.

If you'd rather keep the developer changelog separate and tightly automated, the Automated Changelog Harness Pack handles the CHANGELOG.md side with audience-tuned highlights. For the upstream piece, the writeup on an AI release notes prompt from git commits covers the developer-facing version, and the PRD prompt walkthrough shows where a release starts.