A changelog answers one question for the person upgrading: what changes for me? A list of commit subjects usually answers a different one (what did the team do?). The fix is mostly editorial: keep what changes behaviour, say it from the user's side, and put anything that can break them first.
| Section | Include? | Why |
|---|---|---|
| Breaking changes | Always, first | The only section a cautious upgrader must read |
| Features, Fixes, Performance, Security | Yes | User-visible behaviour |
| Docs | If notable | New guides help adopters |
| Refactor, tests, CI, chores | Usually skip | No change for the user (the CLI has --skip) |
Write each subject as type(scope): description, with ! after the type or a BREAKING CHANGE: footer when behaviour breaks. Then the changelog is a grouping problem, not a writing problem, and the generator can also suggest the version.
The tool's suggestion comes from commit messages, so it is only as honest as they are. A fix that changes documented behaviour is breaking whatever its prefix says.
Paste it anyway. Subjects that start with Add, Fix, Update, Refactor and similar verbs are sorted into sections, everything else lands under "Other changes", and the page tells you how many were guessed. Edit the result by hand: a human pass of five minutes beats a perfect convention nobody follows.
Paste commits into the tool or run node cli.mjs --from v1.2.0 in your repository, review the output, and commit it to CHANGELOG.md. For GitHub, choose the GitHub style and paste it into the release description.