OPENLOG·AI RELEASE MANAGER
Changelogs are editorial, but the first draft should not be manual.
OpenLog turns a Git commit range into a polished release note. It selects commits, asks Groq to write a first draft, lets you edit in a rich BlockNote workstation, and publishes straight to GitHub Releases.
Role
Sole author
Language
TypeScript
Model
Groq (Llama 3)
APIs
GitHub REST + GraphQL
Architecture
How the system fits together
Commit selection → Groq draft → BlockNote editor → GitHub Releases API
The problem
Release notes are either lazy or late
Most projects either auto-generate a dump of commit messages or leave the release note empty. Neither helps a user decide whether to upgrade. A good changelog is written by a human, but a human should not have to start from a blank page.
The ideal workflow: machine draft, human edit, one-click publish.
Competitive gap
What existing release tools get wrong
GitHub’s auto-generated release notes dump every commit. Copilot-style tools can write summaries, but they often invent changes that are not in the diff. Manual changelogs are accurate but slow.
OpenLog keeps the human in the loop while automating the blank-page stage: grounded draft, editable, one-click publish.
The split
Let the model summarize, not invent
OpenLog fetches commits between two refs, filters out noisy ones like “wip” and “fix typo,” and passes the rest to Groq with a strict prompt: group by type, write user-facing summaries, and never invent a change that is not in the diff.
The draft is a starting point, not a final product. The editor is where the real work happens.
Grounding
The prompt is the safety layer
The model is only allowed to summarize diffs it can see. The prompt includes the commit hash, message, and changed files, and explicitly forbids adding external context. If a change is not in the diff, it does not go in the draft.
const prompt = `You are writing a changelog draft.
Rules:
- Group into Features, Fixes, Breaking.
- Write user-facing summaries.
- Only describe changes present in the commits below.
- Never mention internal refactoring unless it affects users.
Commits:
${commits.map(c => `- ${c.hash} ${c.message}`).join('\n')}`;
const draft = await groq.chat.completions.create({ model: 'llama3-70b', messages: [{ role: 'user', content: prompt }] });How it fits together
The release loop
1. Select a tag range. OpenLog pulls commits from GitHub. 2. Groq drafts categories: features, fixes, breaking changes. 3. BlockNote lets you rewrite, reorder, and add context. 4. One click publishes the rendered markdown to GitHub Releases.
Results
What the draft saves
On a mid-sized repo with ~80 commits between releases, OpenLog cuts the time from “tag pushed” to “release published” from roughly 25 minutes to under 5. The editor stage is still required, but the blank-page problem is gone.
~5m
Release time
WITH OPENLOG
80+
Commits handled
PER RELEASE
0
Invented changes
WITH DIFF GROUNDING
Source · timed releases on a sample repository
Lessons
What building it taught me
LLMs are reliable at compression but dangerous at prioritization. They will happily list twelve minor fixes before the one breaking change that actually matters. The editor stage is not optional — it is the safety layer.
The best AI-assisted workflow is one where the human only has to say “yes, but differently.”
A generated changelog that skips the editor is just a slower way to write bad release notes.
Still open
Where it is still rough
Commit quality matters
If the team writes “fix” for every commit, the draft is still bad. The tool cannot rescue poor input.
No multi-repo releases
A release that spans several repositories has to be done one repo at a time.
Model choice is a cost knob
Groq is fast and cheap, but larger models produce better summaries. The right trade-off depends on repo size.
In short
What OpenLog came down to
01
Draft, do not publish
The model writes the first pass. A human decides what ships.
02
Ground the summary in the diff
If the model cannot see it in the commits, it cannot write about it.
03
Editor is the safety layer
Prioritization and tone are editorial, not generative.
