glossaryAn automatically generated changelog derived from Conventional Commits history, categorising changes into sections like Features, Bug Fixes, and Breaking Changes per release.
Conventional Changelog is both a concept and a family of tooling (the conventional-changelog npm packages) that reads a git log, parses Conventional Commits messages, and produces a formatted CHANGELOG.md. Tools like semantic-release, release-please, and changesets use the same approach under the hood. The generated changelog groups commits by type and scope under each release tag. feat commits appear under a "Features" heading, fix commits under "Bug Fixes", and breaking changes under "BREAKING CHANGES". Commit types like chore, docs, and style are typically omitted from public changelogs unless configured otherwise. The quality of a generated changelog is directly proportional to the quality of commit messages. Vague messages like "fix stuff" produce useless changelog entries; precise Conventional Commits messages like fix(auth): prevent session fixation on login produce entries that communicate meaningful information to release consumers.
feat(api): add cursor-based pagination to /users endpointfix(notifications): de-duplicate email sends on retryfeat!: migrate authentication to OAuth2; drop legacy session APIperf(search): replace full-text scan with indexed trigram searchgit-agent produces detailed, specific commit messages with accurate types and scopes. When changelog tools process your history, every entry reflects genuine information about what changed and why, rather than placeholder or vague descriptions.
brew install gitagenthq/tap/git-agentDoes git-agent generate the CHANGELOG.md file?Which commit types appear in a generated changelog?Can I use conventional changelog tooling without semantic-release?