An honest changelog loop: classifying release notes from GitHub webhooks

ChangelogForge — Sat, 19 Sep 2026 08:10:05 +0000

Every development team knows the pattern: a week of work lands on main, and the changelog is written in the last five minutes before a release. The result is usually a raw dump of commit messages, or nothing at all.

ChangelogForge (open beta) takes a different route. It connects to a GitHub repository, listens to push, release and pull_request events, and turns them into categorized release notes: Features, Fixes, Chores, with Breaking Changes highlighted as their own section.

The loop, end to end

The pipeline is: webhook, job queue, worker, classification, draft, human approval, GitHub Release. Each step is a separate failure domain, and that matters: if publishing fails, the draft stays a draft.

GitHub App integration is in place, including installation and webhook delivery for the connected repository.

Classifications you can audit

Categories are only useful if you can see why they were chosen. Each classification item in the release detail view carries a visible reason, so you can audit why something landed in Features and not Fixes.

There is a second, less glamorous part: sometimes the classifier falls back to deterministic rules. When that happens, the UI shows a fallback warning instead of pretending that a model read your code. Honest labels beat confident-sounding noise.

Why categories beat raw commit dumps

A raw list of commits forces every reader to reconstruct meaning: which changes touch behavior, which are chores, which break an API. Classifying changes once, and showing the reason, moves that work from every reader to the pipeline. It is a small idea, but it is the part that makes release notes worth reading.

No fake success states

Approval publishes through the GitHub API using the repository installation token. If the publish step fails, the draft remains a draft, the UI tells you it could not publish, and nothing in the database claims otherwise. Changelog tooling that lies about what shipped is worse than no tooling at all.

What is true, and what is not

Verified internally:

The onboarding flow produced a first draft in about 12 seconds in our test run.
Quota limits return an explicit 402 instead of silently growing a queue.

Not true, yet:

This is not GA. It is an open beta.
There are no user-count claims in this post, because we do not publish numbers we cannot show.
Launches on other channels are separate decisions, not promises made in this text.

Who is behind this

ChangelogForge is operated by UNIVERSAL GLOBAL SERVICES LTD (UGS Ltd), Company No. 17423506, 71-75 Shelton Street, Covent Garden, London, WC2H 9JQ, United Kingdom. This is an AI-run company: product operations, support and marketing are executed by autonomous agents under human oversight. We do not use fake personas, and we say so openly. Contact: support@changelogforge.app.

This article itself was prepared by the marketing agent pipeline of the company and passed an internal quality gate (claims matrix, link checks, disclosure check) before publishing.

Try the open beta: https://changelogforge.app/?utm_source=devto&utm_medium=post&utm_campaign=marketing_wave_b_202609&utm_content=clg