Build Changelog: Release in 60 Seconds
The build-changelog ClawFlows workflow generates release notes from Git history in under a minute. Here's how it works and why it's my favorite dev workflow.
Release notes are a weird kind of work. They're essential — users need to know what changed. They're also mechanical — the information is all in your Git history, you're just reformatting it. And they're tedious — you do this every release, forever, and nobody thanks you for it.
The build-changelog workflow from ClawFlows turns this chore into a 60-second task. You invoke the workflow, review the output, paste it into your release. That's it. No more scrolling through commits. No more writing "updated dependencies" for the fifteenth time. No more forgetting a commit that actually mattered.
Key Takeaways
- build-changelog is a ClawFlows workflow in the Dev Tools category that generates release notes from Git history.
- It groups commits by type — features, fixes, docs, refactors — automatically.
- It produces markdown ready to paste into a GitHub release or CHANGELOG.md file.
- It's part of nikilster/clawflows alongside 11 other dev workflows.
- Running it takes 60 seconds and produces better notes than manual effort.
What the Workflow Does
When you invoke build-changelog, the workflow:
- Determines the version range — typically from the last tag to HEAD
- Reads commit messages in that range
- Parses conventional commit prefixes (feat, fix, docs, chore, etc.) to group commits
- Extracts PR and issue references for cross-linking
- Summarizes commit clusters that are too small to call out individually
- Produces formatted markdown in your preferred changelog style
- Optionally appends to CHANGELOG.md or posts to a release draft
The whole pass takes about 60 seconds. The output is usually good enough to ship as-is, though I typically edit one or two lines for clarity.
What About Non-Conventional Commits?
The workflow handles non-conventional commits too — it just uses heuristics to categorize them based on message content. You get a slightly less tidy changelog, but it still works. Teams that adopt conventional commits get better output, but it's not a hard requirement.
Why It's Better Than Manual Effort
The counterintuitive thing is that automated changelogs are often better than hand-written ones. A few reasons:
Completeness. A human writes changelogs from memory and misses things. The workflow reads every commit and misses nothing.
Consistency. A human writes "Fixed bug where..." and "Bug fix:" and "Resolved issue..." in the same changelog. The workflow uses one format.
Structure. A human produces unstructured prose. The workflow produces grouped markdown with clear sections.
Speed. A human takes 15 minutes. The workflow takes 60 seconds.
Scaling. A human's changelog quality degrades with release size. The workflow handles 500-commit releases as easily as 50-commit ones.
The Output Format
The default output looks something like:
## v1.4.0 - 2026-04-28
### Features
- Added dark mode support (#234)
- New export format for CSV (#241)
- Bulk delete for admin users (#247)
### Bug Fixes
- Fix pagination edge case (#236)
- Resolve memory leak in cache layer (#242)
- Correct timezone handling in scheduled reports (#245)
### Documentation
- Update API reference for new endpoints (#237)
### Internal
- 3 dependency updates
- 2 refactors
Notice the "Internal" section. Small changes that don't deserve individual callouts get summarized rather than listed. This keeps the changelog focused on what users care about.
A Release Routine
Here's the routine I use when shipping a release:
- Run tests via
run-tests-before-committo verify clean state - Run
check-dependenciesto make sure no new vulnerabilities (see Check-Dependencies: NPM Security Automation) - Tag the release in Git
- Run
build-changelogto generate the notes - Review and edit the output
- Create the GitHub release with the generated notes
- Announce in whatever channels are appropriate
Total time: about 5 minutes for a typical release. Before build-changelog, this was closer to 30 minutes because writing changelogs manually was the bottleneck.
Customization Examples
Ways people have customized build-changelog:
- A team added a "breaking changes" section with extra emphasis
- An open source maintainer added automatic contributor attribution ("thanks to @user for X")
- A security-conscious project added CVE linking for security-related commits
- A startup added a "highlights" section that the workflow auto-populates with the top three changes
- A game studio added screenshots for certain feature commits
The workflow is a template. Customize it to match your project's style.
We cover authoring changes in Writing Your First Custom ClawFlow.
Integration With CI/CD
build-changelog can run in CI as part of your release pipeline. Many teams wire it up so that creating a Git tag automatically generates a draft release with the changelog populated.
The workflow composes well with other release workflows:
create-prfor the release PRrun-tests-before-commitfor verificationbuild-changelogfor the notestag-releasefor the actual tag
These four together are a complete release routine. Covered in 12 Dev Tool Workflows Every Engineer Needs.
Comparison to Existing Tools
There are existing tools for this — conventional-changelog, release-it, semantic-release, standard-version. They all work. What's different about build-changelog is:
- It's part of a broader workflow ecosystem. Installing it means you also get 112 other workflows for free.
- It's not opinionated about your release process. It generates the notes; you decide what to do with them.
- It's customizable via workflow editing, not plugin development.
- It composes with other ClawFlows workflows for full release routines.
If you're happy with an existing tool, keep using it. If you're new to changelog automation or already invested in ClawFlows, this is the natural choice.
FAQ
Do I need to use conventional commits?
It helps, but it's not required. The workflow has fallback heuristics for non-conventional messages. Conventional commits produce tidier output.
Can it handle squashed PRs?
Yes. It reads commit messages, so squashed PRs appear as single commits with the squash message. That's usually fine.
What about monorepos?
The workflow supports scoping to a specific subdirectory or package. You run it per-package and get a changelog for each.
Can it skip certain commits?
Yes. You can configure patterns to exclude (e.g., "chore:" commits, WIP commits, dependabot commits, etc.).
What formats does it support?
Markdown by default. You can customize the template to produce RST, AsciiDoc, HTML, or plain text. Most projects stick with markdown.
Stop Writing Changelogs By Hand
If you ship releases regularly, build-changelog will save you hours per year. Install ClawFlows (see How to Install ClawFlows in One Command), run build-changelog before your next release, and watch the changelog write itself.
Explore all 113 workflows at aiskill.market/workflows or submit your own.