Skip to content
DEV Community

DEV Community

Generate CHANGELOG.md Automatically 🤖

#ai #typescript #ci #opensource
14 reactions
Comments Add Comment
3 min read

But there were still some problems.

In particular, even though users could choose an AI provider, there was still no strong way to adjust the language or writing style of the generated CHANGELOG.md for each project.

For example, there was no good way to pass project-specific rules such as:

So the customization experience was still weak.

🚀 v0.2: Gemini provider support

In v0.2, I added Gemini as a new LLM provider.

Changelog-bot power up

Now changelog-bot supports these three providers:

You can specify Gemini from the CLI like this:

changelog-bot \
 --provider gemini \
 --release-tag HEAD \
 --release-name 0.2.0 \
 --dry-run
Enter fullscreen mode Exit fullscreen mode

You can also use it from GitHub Actions:

with:
 provider: gemini
env:
 GEMINI_API_KEY: ${{ secrets.GEMINI_API_KEY }}
Enter fullscreen mode Exit fullscreen mode

I also added dry-run diagnostics.

Provider: gemini
Model: gemini-3.5-flash
AI used: true
Fallback reasons: none
Enter fullscreen mode Exit fullscreen mode

This makes it easier to check whether the AI provider was actually used, or whether changelog-bot fell back to the heuristic mode.

It is a small feature, but I think this kind of observability is very important for CI tools.

When something runs in CI, you want to quickly understand what actually happened.

🚀 v0.3: Changelog customization

In v0.3, I added customization support for changelog generation.

Changelog-bot note

The newly added options are:

Option Description
--language Specifies the language of the generated CHANGELOG.md
--instructions Passes inline instructions to the AI
--instructions-file Passes instructions to the AI from a file

For example, if you want to generate a changelog in Dutch, you can write:

changelog-bot \
 --provider gemini \
 --release-tag HEAD \
 --release-name 0.3.0 \
 --language nl \
 --instructions "Schrijf kort en duidelijk in het Nederlands. Groepeer interne wijzigingen onder Chore." \
 --dry-run
Enter fullscreen mode Exit fullscreen mode

You can also define project-specific rules in a file.

changelog-bot \
 --provider openai \
 --release-tag HEAD \
 --release-name 0.3.0 \
 --language nl \
 --instructions-file .github/changelog-instructions.md \
 --dry-run
Enter fullscreen mode Exit fullscreen mode

For example, .github/changelog-instructions.md can contain rules like this:

Write concise release notes in Dutch.
Rules:

- Focus on user-facing changes.
- Group internal refactors under Chore.
- Group dependency updates together.
- Avoid mentioning commit hashes.
Enter fullscreen mode Exit fullscreen mode

With this, changelog-bot is no longer just "a tool that generates changelogs with AI."

It is moving toward:

A tool that can generate a CHANGELOG.md that feels right for each project.

Also, when customization is enabled, changelog-bot does not simply use GitHub Release Notes as-is, even if they exist.

Instead, it passes them to the model and lets the model rewrite them.

This means GitHub Release Notes can still be used as source material, while the final output reflects the specified language and instructions.

🥌 Roadmap toward v1

With customization added in v0.3, the shape of v1 is becoming much clearer.

Here are the main things I want to add before v1.

1. Config file support

Passing CLI options every time is annoying, so I want to support config files.

{"provider":"gemini","language":"nl","instructionsFile":".github/changelog-instructions.md"}
Enter fullscreen mode Exit fullscreen mode

The goal is to make the same configuration usable from the CLI, GitHub Actions, and reusable workflows.

2. Choosing behavior when an AI provider fails

Right now, changelog-bot falls back when an AI provider fails.

This is convenient, but some projects may want the workflow to fail if AI generation fails.

So I am considering options like:

Since changelog-bot is intended to be used in CI, users should be able to choose between:

Both behaviors are valid depending on the project.

3. JSON report output

Dry-run diagnostics already exist, but I also want to add a JSON report.

changelog-bot --dry-run --report-json
Enter fullscreen mode Exit fullscreen mode

For example, it would be useful to output machine-readable information such as:

This should make it easier to integrate changelog-bot with other CI tools and bots.

4. Better changelog quality

I also want to keep improving the quality of the generated changelog.

Some areas I want to improve are:

Especially in OSS, what should be included in a changelog differs from project to project.

I want changelog-bot to handle those differences better.

🎯 Summary

CHANGELOG.md is a very plain file, but for users, it is an important document.

Recently, it is also becoming more common to let AI read it and use it as input for dependency update decisions.

That is why CHANGELOG.md should not just be generated somehow.

It should be generated in a readable way that fits each project’s context.

But writing it carefully by hand every time is honestly a pain.

changelog-bot is a tool for automating that process with Git history, Pull Requests, GitHub Release Notes, and AI.

In v0.2, I added Gemini support.

In v0.3, I added customization through language, instructions, and instructions file.

With these changes, changelog-bot is moving from:

Just generating a changelog automatically

to:

Generating a changelog that fits each project

v1 is getting closer.

If you are interested, please give the repository a ⭐ and watch over it warmly!

GitHub logo nyaomaru / changelog-bot

Automatic create changelog with AI. 🤖 It provides CLI and github actions. 🚀 https://www.npmjs.com/package/@nyaomaru/changelog-bot

changelog-bot type logo

changelog-bot logo

Releases should feel exciting, not tedious @nyaomaru/changelog-bot 🤖 turns your Git history and release notes into a polished changelog entry (and optional PR) in a single run. Drop it into CI, run it locally, or hand it to your release captain—either way, you ship with a crisp changelog and zero copy-paste fatigue.

Why changelog-bot?

  • Automated storytelling: Combines commit history, PR titles, and release notes to produce human-ready changelog sections.
  • LLM superpowers (optional): Connect OpenAI or Anthropic for tone-aware summaries or skip API keys entirely and rely on a robust heuristic fallback.
  • PR-ready output: Can open a pull request with updated changelog, compare links, and release notes already wired up.
  • Safe defaults: Detects duplicate versions, keeps compare links current, and won’t fail a release if AI is down.
  • CI-native: Works as a GitHub Action, reusable workflow, or plain CLI—no fragile scripting required.

Important

This project is currently in its early stages...

View on GitHub

Now let’s auto-generate our CHANGELOG.md files and use the saved time to play some games! 🧟🍀

Top comments (3)

Subscribe
pic
Create template

Templates let you quickly answer FAQs or store snippets for re-use.

Dismiss
Collapse Expand
txdesk profile image
TxDesk
18yo solo founder building TxDesk, an AI assistant for crypto wallet-holders. Read the chain, verify before you trust. 46 chains. txdesk.io
  • Location
    London
  • Joined
•

changelog-bot solves the downstream half well. The upstream half is where the AI-triage value compounds: whether the input PR descriptions contain the "why."

What changed is easy to derive from git. Why it changed (the alternative considered, the constraint that ruled out the obvious approach, the failure mode being defended against) lives in PR descriptions, and even good projects let those decay over time. The auto-generator preserves what's in the inputs, no more.

The ceiling for the Dependabot + Claude Code use case you opened with isn't set by how well the tool rewrites sections. It's set by PR description discipline upstream. Possibly a v1 angle: detect releases whose PR descriptions are thin and downgrade the AI-triage confidence on those entries.

Collapse Expand
nyaomaru profile image
nyaomaru
React / Vue / TypeScript / OSS Frontend engineer with 7+ years of experience. Building code simpler and more understandable architecture.
  • Email
  • Location
    Heerlen, the Netherlands
  • Education
    Ritsumeikan University
  • Joined
•

Thank you for your comment! 😺

I agree that extracting the "why" is the hard part.

In my experience, that context is often not fully written in PR descriptions. It may live in code comments, review discussions, issue threads, or only in the author’s head.

So I really like your point about treating input quality as part of the AI-triage confidence.

Instead of only rewriting changelog sections, changelog-bot could detect when the upstream context is thin and mark those entries as lower confidence.

The main concern I have is token usage. If a release has many PRs, pulling in descriptions, comments, linked issues, and code context can become expensive quickly.

But I think this is a very interesting v1 direction.

Thanks a lot for your thoughtful feedback. I’ll explore this for the v1 roadmap 🚀

Collapse Expand
nyaomaru profile image
nyaomaru
React / Vue / TypeScript / OSS Frontend engineer with 7+ years of experience. Building code simpler and more understandable architecture.
  • Email
  • Location
    Heerlen, the Netherlands
  • Education
    Ritsumeikan University
  • Joined
•

Hey! 😸

I support WHY extraction from v0.6.0 🚀
github.com/nyaomaru/changelog-bot

Below is real OSS project sample.
github.com/nyaomaru/is-kit/pull/21...

Let's try 👍

Are you sure you want to hide this comment? It will become hidden in your post, but will still be visible via the comment's permalink.

For further actions, you may consider blocking this person and/or reporting abuse

DEV Community

We're a place where coders share, stay up-to-date and grow their careers.

Log in Create account

AltStyle によって変換されたページ (->オリジナル) /