What changed
The confirmed fact, in plain language. Example: “CSV export now escapes values containing commas, quotes or line breaks.”
Technical SEO
Title, meta description, canonical, OG, Twitter, BreadcrumbList, FAQPage, WebApplication schema.
Changelog Entry Generator: release notes from confirmed facts
Turn confirmed release facts into a user-facing changelog entry and ready-to-adapt channel copy. The tool never invents availability, required action, benefit, performance or security claims, anything unconfirmed becomes a visible placeholder or a blocker. This is product release communication, not a commit log.
- Structured release facts: change type, evidence status, affected audience, availability/rollout, required action, limitation, migration and provenance.
- Public changelog plus in-app, email, App Store/Play, internal summary, developer/API note and support brief, all from one fact base.
- A scoreless audit and a claims-requiring-verification list. Planned PRD items cannot be announced as shipped.
No login. Deterministic, client-side, no AI and no server call. Autosave, share link and lossless JSON.
This tool does not inspect your repository, release system or any URL. It turns facts you supply into release communication and blocks anything that is not grounded. Share links are compressed, not encrypted.
1. Release facts
2. Channels
Only the channels you select are generated. Details change per channel; facts do not.
3. Changes *
Confirmed facts only. Availability, action and evidence are never inferred.
Change 1: (untitled)
4. Next step / CTA (optional)
5. Internal-only context (never published)
Owners, incident IDs, customer names, rollout gates, risk notes and unreleased future work. These appear only in the internal summary, developer note and support brief, never in a public channel.
6. Import JSON (lossless)
Accepts a JSON export from this tool. Malformed input leaves your current workspace unchanged.
How it works
- Record confirmed release facts. For each change, set the change type, what actually changed, the evidence status, who is affected, availability and the required user action. Unknown stays unknown.
- Generate from one fact base. Choose the channels you need. The tool writes a public changelog entry plus the in-app, email, store, internal, developer and support variants from the same facts, nothing is inferred.
- Review the audit, then publish. A scoreless audit flags unsupported performance/security/availability claims, missing actions or dates, hidden partial rollouts and public/internal boundary risks. Edit any channel; edits survive regeneration.
What to include in a release note
Who it affects
The audience the change applies to. Not “everyone” if it is admins, developers, one plan, one region or one platform.
Availability
The real rollout state: all users, phased, Beta, early access, plan/region/platform limited, internal or not yet GA.
Required action
What, if anything, a user must do. If nobody has checked, say so rather than claiming no action is needed.
Benefit
Optional, and only when you can support it. The fact is the obligation; the benefit is the interpretation.
Limitations and migration
Known limits, workarounds, effective dates and migration paths for breaking or deprecated changes.
Release notes vs changelog
A changelog is the running record of what changed across releases. Release notes are the entry for one release. In practice both serve the same user job when they describe product changes for customers. This is different from a developer changelog built from commits, tags and conventional-commit categories: that audience needs version numbers, endpoints and migration detail, which is why the tool generates a separate developer/API note instead of forcing commit language into the customer view.
Release notes vs a launch announcement
A launch announcement is marketing: positioning, audience motivation and a call to action. Release notes are communication: what changed, who it affects, whether it is available and what a user must do. The two can share a date, but they should not share a voice. This tool writes release communication and deliberately avoids superlatives, “biggest release yet” and other launch hype unless the team supplied and can support them.
Examples by change type
| Change type | How to write it |
|---|---|
| New feature | State what is new and who can use it. Do not claim a benefit you have not measured. |
| Improvement | Say what changed for the user. “Indexing now runs incrementally” beats “faster for everyone”. |
| Bug fix | Describe the symptom and the fix state. Do not invent root cause, severity or affected-user counts. |
| Performance | Reproduce the supplied measurement with its context. Do not extrapolate a percentage to all users. |
| Security | Use supplied facts only. No CVE, no breach claim, no “more secure” unless the team supplied it. |
| Deprecation / breaking change | Who is affected, what breaks, the effective date, the migration path and the required action. |
How to write breaking and deprecation notes
Breaking changes need more structure than a feature note: who is affected, what changes, the effective date, the migration path and the required action. Deprecations need the same promise with a longer runway. The audit flags a missing action, a missing date or a missing migration path, and tone never softens the impact, a friendly version still states the break explicitly.
Public vs internal release notes
A public changelog should never include internal owner names, incident IDs, customer names, confidential rollout gates, unreleased future work or internal risk notes. Internal summaries and support briefs may. This tool keeps that boundary explicit: internal-only context is stored separately and is excluded from every public-facing channel, while the developer note and internal summary can include the operational detail they need.
Channel adaptation without changing facts
A public changelog entry, an in-app note, an email and a store note differ in length, structure and jargon, not in facts. Availability and required action survive every adaptation. That is why the tool generates all selected channels from one fact base: the same “Beta, invite only” or “migration required by 2026-11-01” appears everywhere it matters.
When not to announce
Do not publish when the release is still planned, when availability is a partial rollout described as universal, when a security detail is not approved for disclosure, when a limitation would materially change a user decision, or when the only “benefit” is a number nobody measured. The tool blocks or flags each of these instead of quietly producing polished copy.
Common mistakes (symptom, cause, fix)
Symptom: A planned feature is announced as shipped.
Cause: The note was drafted from the PRD or roadmap before the release was confirmed.
Fix: Set the release state to shipped only after confirmation; a planned row is labelled and blocked from public channels.
Symptom: The changelog says “now available to everyone” during a phased rollout.
Cause: Availability was assumed from the release type instead of being set per change.
Fix: Set availability per change (all users, phased, Beta, early access, plan/region/platform limited).
Symptom: The note says “No action required” when nobody checked.
Cause: The default action was treated as a fact.
Fix: Leave action as unconfirmed until someone confirms it; the copy then says “User action not confirmed”.
Symptom: A performance number appears with no measurement.
Cause: A plausible benefit was written as prose.
Fix: Supply the measured fact and its context, or keep the factual change and drop the number.
Symptom: A security change leaks a breach, CVE or “more secure” claim.
Cause: Marketing instinct filled a gap the team had not confirmed.
Fix: Use only supplied security facts and the approved recommended action.
Symptom: A breaking change gives no date or migration path.
Cause: The change was described but the consequence was not.
Fix: Add who is affected, what to do, the effective date and a migration link.
Symptom: A known limitation disappears in the friendly version.
Cause: Tone was allowed to change facts.
Fix: Keep limitations identical across tones and channels; tone changes style only.
Symptom: The public note and the store note contradict each other.
Cause: Each channel was written separately from memory.
Fix: Generate every channel from one fact base; only length and framing may differ.
Pro tips
- Write from confirmed facts, not from the PRD. A planned requirement is not a shipped one until someone confirms the release.
- Set availability explicitly for every change. “Now available” is a fact, not a default, if rollout is partial, say so.
- Record the required user action, even when the answer is unknown. Unknown is honest; “No action required” is a claim.
- Keep benefit and fact separate. “CSV escaping is fixed” is a fact; “saves hours of cleanup” is a benefit that needs evidence.
- Never turn “implemented caching” into “pages load 50% faster” unless a measurement is supplied.
- For bug fixes, describe the symptom and the fix state. Do not invent root cause, severity or the number of affected users.
- For security changes, use supplied facts only. Do not add a CVE, a breach statement or “more secure” on your own.
- Breaking changes and deprecations need who is affected, what to do, the effective date and a migration path.
- Keep a known limitation visible in every tone. A friendlier voice must not hide that the feature is capped or in Beta.
- Generate all channels from one fact base so the public changelog, in-app note and store copy cannot drift apart.
FAQ
Is this a changelog generator or a commit-log summarizer?
It generates product release communication, a public changelog entry and channel variants, from confirmed release facts you supply. It is deliberately not a commit-log summarizer: developer changelogs built from conventional commits are a different job with a different audience, so this tool keeps them out of scope and routes technical detail to a developer note instead.
How does benefit-first work without inventing a benefit?
Every change row has two separate fields: the confirmed fact and an optional benefit. The fact is written as supplied. A benefit appears only when you supply one, and a quantified, performance, reliability, security or universal-availability benefit is held back as a placeholder until you supply evidence. When no benefit is known, the tool writes a clear factual note rather than a fabricated one.
What happens if availability is unknown?
The output says “Availability not confirmed” and the audit flags it. The engine never infers availability from release type, version or wording, so a phased rollout can never be described as “available to everyone” by accident. You set the real state per change: all users, phased, Beta, early access, plan-limited, region-limited, platform-limited, internal or not yet GA.
What if I do not know whether users must act?
Leave the action as unconfirmed. The copy then says “User action not confirmed”, which is honest, rather than “No action required”, which is a claim. “No action required” only appears when you explicitly choose it.
How are performance and security claims handled?
A number, a speed claim, a reliability claim or a security claim is only written as prose when it is backed by a supplied fact. Supply the measurement and its context, or record the security fact, and the engine will reproduce it accurately. It never extrapolates a percentage, invents a CVE or adds “more secure” on its own.
How do breaking changes and deprecations work?
They use a stronger structure: who is affected, what changes, the effective date, the migration path and the required action. The audit flags a missing action, a missing date or a missing migration path. Tone never softens the impact, a friendly version still states the break explicitly.
Which channels can I generate?
You choose from public changelog, in-app announcement, email, App Store note, Google Play note, internal stakeholder summary, developer/API note and support brief. All channels are generated from one fact base, so they can differ in length and framing but never in facts. Store limits change, so the tool tells you to verify the current limit instead of assuming one.
How is public and internal data separated?
Internal-only context, owners, incident IDs, customer names, rollout gates, risk notes and not-yet-released future work, is stored separately and appears only in the internal summary, developer note and support brief. Every public channel excludes it, and the audit reminds you that the boundary is being applied.
Can I edit the generated copy?
Yes. Each channel is editable, and your edits are preserved when you regenerate. If the underlying release facts change, the affected output is marked as needing review instead of being silently overwritten, so you never publish stale wording by accident.
Does this use AI, and where is my data stored?
No AI and no server call: the generation is a deterministic transformation of the facts you enter. Work autosaves in your browser, and a share link compresses it into the URL (not encrypted). Release communication can contain sensitive details, so avoid sharing links that contain confidential facts, and export JSON for a lossless copy.
Learn more with CraftUp
Courses, topics, blog and glossary for product teams.
From shipping to clear communication
Use CraftUp tools and courses to ship, communicate what changed honestly, and measure adoption.
Freshness
Last updated: 2026-09-25
- 2026-09-25: Rebuilt as a release-communication truth contract: confirmed release facts in, channel copy out, with no invented availability, action, benefit, performance or security claims.
- 2026-09-25: Added per-change availability, required action, evidence status and provenance; a scoreless claim audit; claims-requiring-verification list; public/internal boundary; and channel consistency from one fact base.
- 2026-09-25: Versioned JSON export/import, release-facts CSV register, Release Communication Brief Markdown, share size guard and v1 migration.