Release Notes Compiler

The problem

A commit log is written by authors, for authors, at the moment of writing. Release notes are read by users, after the fact, to answer one question: does this change anything for me?

Conventional-commit generators transform the first thing into a formatted version of the first thing. They cannot produce the second, because the consequence was never in the commit subject. That is why nobody reads your changelog.

What you get

Paste the log. You get three separate documents, not one list with the prefixes stripped:

• For users — plain language, no component names, no ticket numbers. Ordered by how many people it affects, not by commit date.
• For integrators — exact endpoint, field, parameter or config key. Every breaking entry carries the before, the after, and the migration step.
• For the team — operational changes, dependency bumps that matter, and everything it could not classify.

What it does that a generator will not

• Breaking changes go to the top of every document, under their own heading. Never as one bullet among twelve. A reader who skims and misses a breaking change has been failed by the notes.
• Collapses commit chains. A feature built over eleven commits is one line.
• Drops internal churn entirely rather than filing it under Miscellaneous, which is where release notes go to die.
• Rewrites fixes from the symptom. The user recognises "the export button did nothing on Safari", not "null guard added to the blob handler".

What it refuses to do

It never invents a change that is not in your input — no "various improvements and bug fixes", no filler line to balance a section. Commits whose effect cannot be determined from the subject are named in an Unclassified list, not silently dropped and not guessed at.

It works from a fragment: a log pasted into chat is the whole input and it is enough. It asks for the diff at the end, after the notes are already in your hands.