How do you ship release notes without writing them from scratch?
A release notes AI Employee that, on each release, reads every PR merged since the last one, groups them by area, writes human readable notes, and opens a changelog PR for a named human to review and merge.
×
Writing release notes means reading back through everything that merged since the last release, deciding what a reader cares about, and phrasing it for someone who wasn't in the PRs. It's the kind of task that's easy to defer, so the changelog falls behind or gets a one line summary that helps no one. The common fixes are incomplete. An auto generated list of PR titles is accurate but unreadable: internal wording, no grouping, every dependency bump included. Writing them by hand is better but slow, and it competes with actually shipping. Either way the notes arrive after the release, if they arrive at all.
The release notes AI Employee is triggered on each release. When a tag is pushed, it starts an isolated run inside your own environment with permissions you set for the repository. It finds the previous release, reads every PR merged in between, groups them by area, writes notes in plain language, and opens a PR to the changelog. A named human reviews and merges. It never publishes, tags, or announces.
See exactly how the work gets done.
Triggered on every release
A signed GitHub webhook points at the project. A pushed tag or published release fires it, and each firing starts a fresh run inside your own environment, seeded with the new tag. One release maps to one run, so nothing carries over between releases.
Carries the notes playbook
How you write release notes travels with the AI Employee as skills and memory: how to group changes by area, which labels mark internal only work to drop, the voice the changelog is written in, and the format the file expects. When you adjust how a section reads, you write it down and it follows on the next release.
Connects to the repository with permissions you set
It locates the previous release tag and the commit range to the new one; reads the titles, descriptions, labels, and authors for every PR merged in that range; and opens a changelog PR on GitHub with the drafted notes. Credentials stay in memory, never written to disk, never exposed to the model.
Groups and writes, dropping the noise
It clusters the merged PRs by area and writes plain language notes, dropping internal churn and dependency bump noise so the result reads for someone who wasn't in the PRs.
Stops at a changelog PR
Its output is a pull request against the changelog and nothing more. It does not publish, tag, or announce. A named human reviews the wording and merges.
Runs in your environment
Every release runs isolated inside your own infrastructure. It reads the PR history and drafts the notes; only the changelog branch leaves it, and your data never leaves your environment.
Drafts a PR, never publishes
It opens a pull request against the changelog and stops. It never publishes or announces the release. A named human reviews the wording and merges.
Read on the repo, write only the draft
It reads PR titles, descriptions, labels, and authors, and its only write is the changelog branch it opens for review. It changes nothing else in the repository.
Credentials stay protected
The GitHub credentials connect with permissions you set, stay in memory, never written to disk, never exposed to the model or the logs.
You own every rule
The grouping rules, the labels to drop, the changelog voice, and its permissions are yours, versioned and changed on your terms, not in a vendor dashboard.
The changelog stops falling behind, and the notes that reach review are already grouped and readable instead of a raw list of PR titles. Reviewers edit wording rather than reconstructing what shipped from the git history.
Every release
Notes drafted from the PR history automatically
Grouped
Changes clustered by area with internal churn dropped
Human review
The AI Employee drafts; the team owns the wording
Our free AI audit shows you where AI fits, what your security risks are, and gets your first AI employee working.
How do AI Employees keep your docs in sync with the code?
Sweeps the code merged each day, rewrites the docs those changes touched, and opens one reviewable pull request. Publishing waits for a human merge.
×How do AI Employees test every pull request before a human reviews it?
Checks out every pull request, runs the suite, exercises the change through the edge on a test deploy, and posts the result. It stays off production, leaving the merge to a person.
×How do you get a postmortem drafted the moment an incident resolves?
Reconstructs the incident timeline, correlates it against deploys and log spikes, and opens a structured postmortem as a doc PR. It drafts, and the team finalizes.
×