{{ summaryTitle }}
{{ computation.ok ? `${computation.values.row_count} release rows` : 'Needs input' }}

{{ summaryLine }}

Source{{ sourceModeSummary }} Major{{ computation.ok ? computation.values.major_signal_count : '—' }} Review{{ computation.ok ? computation.values.review_signal_count : '—' }}
{{ fileStatus || 'Drop TXT, MD, or LOG onto the textarea.' }}
Auto chooses the strongest repeated cue; pin a format when mixed input should follow one parser.
Optional product or repository name for exported artifacts.
Optional previous tag for a full changelog comparison.
Leave blank when the notes should not include an external compare link.
Each non-empty line becomes a Known Issues row.
Concise is the neutral default; technical retains Conventional Commit scope context.
The neutral default preserves traceable issue and PR references.
{{ include_issue_refs ? 'Included' : 'Removed' }}
The neutral default omits sections that have no generated changes.
{{ include_empty_sections ? 'Included' : 'Omitted' }}
{{ computation.values.markdown }}

The chart renderer is unavailable. Category counts remain available in the ledgers.

SectionRelease noteAudience signalRelease signalSourceCopy
{{ row.section }}{{ row.note }}{{ row.audience }}{{ row.signal }}{{ row.source }}
GateStatusEvidenceNext actionCopy
{{ row.gate }}{{ row.status }}{{ row.evidence }}{{ row.action }}
Changelog Generator Turn release notes, changelog sections, or Conventional Commit subjects into grouped Markdown with SemVer signals and pre-publish checks.
Regex Sample Matches Checker Test a JavaScript regex against lines that should match or fail with whole-line checks plus match evidence, input caps and backtracking guards.
SemVer Bump Required Checker Check release notes and commit subjects for the required SemVer bump, then verify whether a planned version covers the strongest change signal.
Meeting Minutes Generator Turn rough meeting notes into structured Markdown minutes with decisions, accountable action items, and circulation-readiness checks.

Release notes translate a set of software changes into decisions for customers, developers, or an internal rollout team. A useful note names the release, summarizes its effect, separates new work from fixes, and makes breaking changes, upgrade work, security changes, and known problems hard to miss.

Raw commit messages and pull request titles are valuable evidence, but they are rarely ready to publish. They may use internal scope names, mix several audiences, repeat the same change, or hide required action behind a short technical phrase. Editing should preserve traceability while replacing repository shorthand with consequences the intended reader can understand.

  • Customers need outcomes, behavior changes, limitations, and any action they must take.
  • Developers need compatibility details, migration steps, security implications, and references to relevant changes.
  • Internal teams need rollout status, ownership, known risk, and follow-up work.

Version syntax can help classify change, but it does not prove that the note is complete. A valid version and date can still accompany missing migration guidance or an unclear breaking change. Publication readiness requires a human review of both the grouped draft and the source changes it represents.

How to Use This Tool:

Start with one change per line and choose the reader before polishing the wording.

  1. Paste release changes or load a text file under 512 KiB. Choose Auto detect when the lines consistently resemble categorized entries, Conventional Commits, GitHub pull requests, or plain bullets; pin a format when the input is mixed.
  2. Enter the release title, version, date, audience, status, and publication format. Add a short reader-facing summary rather than repeating the section list.
  3. Put migration steps in Upgrade or compatibility notes and unresolved problems in Known issues. Those lines are added to their own sections even when the main source contains no matching category.
  4. Review Release draft for wording and Change ledger for how each source line was classified. Correct ignored lines or unexpected categories at the source.
  5. Resolve every Blocker and relevant Review item in Readiness review, then compare the final note with the actual release before publishing it.

Interpreting Results:

The grouped Markdown is a draft, not an authoritative changelog. Check that Breaking Changes, Upgrade Notes, Security, and Known Issues match the release and use language suited to the chosen audience.

Ready means a specific automated check found its expected evidence. Review asks for human confirmation or missing optional context. Blocker is reserved for no parsed changes or a yanked release that lacks replacement, rollback, and impact guidance. Parser warnings also deserve review because ignored headings, malformed lines, or collapsed duplicates can hide information.

Technical Details:

Release-note generation is a text transformation rather than a numeric calculation. The central mechanism detects or accepts a source grammar, converts each valid line into a normalized change record, groups records in a fixed publication order, and builds both Markdown and review evidence from the same records.

Transformation Core:

Source formatRecognized shapeResult
CategorizedMarkdown headings or labels such as added, fixed, security, or upgradeLines inherit the recognized heading or prefix; uncategorized lines become Improvements with a warning.
Conventional Commitstype(scope): summary, optional breaking marker, or BREAKING CHANGE footerTypes map to release sections; technical voice retains the scope in brackets.
GitHub pull requestsPull request number followed by a summary and optional authorThe summary is parsed again as a conventional message when possible; otherwise it becomes an Improvement.
Plain bulletsOne change per nonblank lineEvery line becomes a Highlight.

Auto detection checks for pull request rows first, then Conventional Commits, then categorized headings or prefixes; anything else is plain text. Mixed input can therefore follow the first strong repeated cue rather than the intent of every line, which is why a pinned source format is safer for irregular data.

After parsing, upgrade and known-issue lines are appended. Duplicate records are collapsed only when their section and normalized note text match case-insensitively. Sections then appear in this order when populated: Breaking Changes, Highlights, What is New, Improvements, Fixes, Security, Upgrade Notes, Known Issues, Deprecated, Removed, Documentation, and Other Notes.

Rule Core:

CheckRuleMeaning
VersionPresent and shaped like MAJOR.MINOR.PATCH, with optional pre-release or build metadataA missing or nonmatching value is a review item, not an automatic rewrite.
DateA real calendar date in YYYY-MM-DD formAn invalid or missing date is flagged before publication.
Change coverageAt least one parsed recordZero records creates a blocker.
Yanked statusRelease status equals YankedCreates a blocker and asks for replacement, rollback, and impact guidance.
High-attention sectionsBreaking, upgrade, security, or known-issue records are presentCreates targeted review actions rather than silently treating the draft as complete.

A repository URL plus current version produces a release link; adding a previous version produces a comparison link. These links are assembled from the entered values and still need to be opened and checked. Empty sections are omitted unless explicitly requested.

Privacy and Accuracy Notes:

Pasted text and loaded files are processed in the browser. Do not include secrets, private vulnerability details, customer data, or internal references in a draft intended for public release. Classification follows visible text patterns and cannot determine whether a source claim is true, complete, approved, or safe to disclose.

Worked Examples:

Breaking developer release

The line feat(api)!: require export.read scope becomes a Breaking Changes entry. With technical voice, its scope is retained as [api]; separate upgrade and known-issue lines appear in their own sections. The readiness review asks for explicit migration wording and security or compatibility confirmation before publication.

References: