Create a customer-facing changelog entry for [PRODUCT AND AUDIENCE] using the release information below. Release information: [RELEASE NOTES] Context and terminology customers already know: [PRODUCT CONTEXT] Publishing channel and length limit:
[CHANNEL AND LENGTH]
Write the entry in this order:
1. A specific title that names the capability or outcome, not an internal ticket or component.
2. A 1-2 sentence summary explaining what changed and why it matters to this audience.
3. “What’s new” bullets. Each bullet must describe an observable user action, result, or corrected behavior.
4. “Who it affects” and any rollout, plan, platform, permission, migration, or compatibility conditions.
5. “How to use it” only when the notes support concrete steps.
6. A short known-limits or next-steps note only when it is material to using the release correctly.
Translate internal terms into familiar product language, but retain exact names for UI labels, plans, APIs, and settings. Distinguish a new capability from a bug fix, performance improvement, and interface change. Do not claim availability, speed, reliability, security, or outcomes that the release notes do not establish. Do not describe implementation details unless they help customers act.
Before answering, check that every claim is supported by the release information and flag unsupported or ambiguous claims in a separate “Questions before publishing” section. Also check that a customer could tell whether this applies to them. Output only the changelog entry and that questions section. Ask up to 3 clarifying questions only if a required input is missing.Fill in
| Placeholder | What to enter | Example |
|---|---|---|
| [PRODUCT AND AUDIENCE] | Name the product area and the customers who will read the changelog. | Acme Analytics dashboard; workspace admins at mid-market SaaS companies |
| [RELEASE NOTES] | Paste approved release notes, tickets, test results, and rollout details. | Added CSV export to Saved Reports. Admins can export up to 50,000 rows; exports omit deleted users. Available on Pro and Enterprise. Rolled out to 25% of workspaces today. |
| [PRODUCT CONTEXT] | Add the customer terms, existing workflow, and UI names relevant to the change. | Customers call these saved reports “views.” The button is labeled Export CSV in the report’s three-dot menu. |
| [CHANNEL AND LENGTH] | State where this will appear and its maximum length, such as an in-app modal or release page. | Public release notes; 120 words maximum |
How to use
- Paste approved release notes rather than a developer’s memory of the change.
- Add rollout and entitlement details, since these are often the facts customers need most.
- Check the draft against the shipped UI, especially button names and access conditions.
- Follow up with: “Make a 55-word in-app version that preserves the eligibility and rollout details.”
Variations
Technical release notes
Use this when developers need an API or SDK changelog.
Write technical release notes for [API OR SDK] from [CHANGE DETAILS]. Produce: a one-line summary, affected endpoints or versions, breaking-change status, migration steps, request/response examples only from the supplied material, and rollout timing. Preserve exact parameter and field names. Mark any behavior, version, or limit not confirmed by the input as “needs confirmation.” Do not invent code, deprecation dates, or performance claims. Ask up to 3 questions only if a required input is missing.
Internal launch note
Use this when support and sales need to understand a release.
Turn [RELEASE NOTES] into an internal launch brief for [TEAMS]. Include customer problem, released behavior, eligibility and rollout, exact customer-facing language, likely questions with approved answers, and escalation conditions. Separate confirmed facts from assumptions. Add a “do not promise” list for anything not fully launched or not supported by the notes. Do not create policy or commitments. Ask up to 3 questions only if a required input is missing.
Bug fix update
Use this for a brief update on a resolved customer issue.
Write a customer-facing bug-fix update about [ISSUE] using [CONFIRMED FIX DETAILS] for [AUDIENCE]. State the prior observable symptom, what is now corrected, who was affected, and whether customers need to do anything. Avoid assigning blame, exposing internal incident details, or claiming root cause unless confirmed. Add a short note for customers still seeing the issue. Flag unsupported claims before the draft. Ask up to 3 questions only if a required input is missing.
Tips
- Treat eligibility, rollout percentage, and platform support as release content, not fine print; leaving them out creates avoidable support tickets.
- Use the UI label customers see, even when the underlying feature has a different engineering name.
- Do not turn a bug fix into a feature claim; “fixed an error when exporting” is safer than implying a new export capability.
- If a change alters a workflow, test the “How to use it” steps in the live product before publishing.
FAQ
Should a changelog mention bugs customers may not have noticed?
Usually mention a fix when it changes a visible behavior, affected a meaningful group, or helps customers know a problem is resolved. Omit low-impact internal maintenance unless transparency is needed.
Can AI write changelogs from a pull request?
It can draft one, but a pull request often lacks confirmed rollout, entitlement, and customer impact details. Supply approved release notes before publishing.
How long should a customer changelog entry be?
Most single changes fit in 60-150 words. Use more space only for migration steps, constraints, or a behavior change customers must act on.