Engineering

The changelog, drafted from what your board says shipped

Drafts the changelog in your voice from the work your board marked done, cites every line, and posts it to Slack after you approve.

Join the waitlist See what it produces

Twice a week, already cited

Write the changelog

Who it is for: Engineering leads who own the release notes and keep writing them last.
What starts it: Tuesdays and Fridays at 16:00, on a schedule you set. Also on demand.; On a schedule

Turn it on in Aestus

A team that ships continuously loses the changelog first. Somebody has to scroll the merged pull requests, guess which of them a customer would notice, rewrite commit messages into product English, and then do it again on Friday. It is the kind of work that is never urgent on the day and always overdue by the quarter.

This use case starts somewhere a tool reading only your repository cannot. A merge says code changed. A ticket moving into a column you marked terminal says a person decided the work was done — who produced it, what the run cost, which artifacts it left behind. That decision is the spine of the entry, and the pull requests are read afterwards, for the detail of what actually changed.

Each line is written as what is different now for a person using the product, not as what changed in the code. "Memory pages open as a short list and expand one record at a time" is a changelog line. "Refactored the memory list to lazy-render rows" is a commit message with better grammar. A line that needs a file name to make sense is describing the wrong thing, and the check that runs before you see the draft rejects it.

The counting is not done by the model. Every number the draft prints is recomputed from the rows it was built from, and a figure the model wrote that disagrees is replaced and the disagreement noted where the reviewer can see it. Every link is built by the product from the ticket's own short id rather than typed out, because a model asked for a route will eventually write a plausible one that leads nowhere.

The work it leaves out is as visible as the work it keeps. Every excluded ticket is listed with the label, the changed path or the pull request title that excluded it — never the bare word "internal", which is what a tool says when it has no reason at all. A window in which nothing a customer would notice shipped produces no entry, says so, and explains each omission.

Nothing leaves Aestus until you approve. The draft lands as a document on the ticket you anchored it to, and then the run asks before posting. Approve and the entry is posted to the Slack channel you chose, with a link back to the full cited draft. Decline and it stays where it is, ready to copy.

What you get

The artifact this use case produces, in the product view you would read it in.

Example — fictional team and data. Not a live run or customer result.

Worked example

document

Changelog draft — 2 September to 5 September 2026

Produced by: Run EXAMPLE-CL-01 · read-only · document artifact

Scope: One window, stated as two instants and treated as half-open, so a ticket closed at the moment it ends belongs to the next entry rather than to both. 8 tickets reached a terminal column inside it, carrying 8 merged pull requests.
Draft entry: 4 change lines under 2 change types, each saying what is different now for a person using the product and each citing the ticket it came from. The links are built from the ticket's own short id by the product, never written by the model.
Kept out of this entry: The 4 tickets that closed and were left out, each with the label, changed path or pull request title that excluded it. A reason that says only "internal" is thrown away before anybody reads it.
Evidence: One row per closed ticket: title, close date, who produced it, the outcome and the pull request. Every number printed anywhere in the draft is recomputed from this table, and a figure the model wrote that disagrees is replaced and the disagreement noted here.
What the run did not see: How many tickets sat on teams the run could not read, how many pull requests were in repositories that are not connected, and whether any list was truncated. A run that cannot report this says so, rather than printing a confident zero.

How it runs

Each step is one node in the workflow graph the interpreter runs. Nothing here is a prompt chain hidden in a route handler.

Workflow steps

01Input
The window is worked out in code before anything reads anything: the week you name, or the number of days back you chose. The run covers that window and nothing else, and the checks that follow hold it to exactly those two instants.
02Agent
It reads the tickets your board moved into a column you marked terminal in that window — with the owner, the outcome and the artifacts — then opens the merged pull requests behind them to see what actually changed.
03Branch
It sorts the changes a person using the product would notice from the ones they would not. If none of them would be noticed, it says so and writes no entry. A quiet window does not get a padded one.
04Eval checkpoint
A judge checks the draft against eight rules before you see it. A line citing a ticket that was not in the evidence, a count the evidence does not support, or a sentence naming a file instead of saying what is different — each sends the draft back to be rewritten. Two attempts, then the run fails and writes nothing.
05Approval
The draft is saved on the ticket you anchored it to, with the evidence table it was built from. Then it asks before posting. Approve and a short form of the entry, linking the full draft, is posted to the Slack channel you chose. Decline and it stays in Aestus.

By hand, and on Aestus

The same job, on either side.

By hand
Scroll forty merged pull requests and guess which ones a customer would notice.
On Aestus
Starts from the tickets your board marked done, then reads their pull requests for detail.
By hand
Rewrite commit messages into product English, twice a week, forever.
On Aestus
Drafts each line as what is different now for a person using the product, grouped by change type.
By hand
Internal refactors and dependency bumps leak into the notes.
On Aestus
Every excluded ticket is listed with the label, path or pull request title that excluded it.
By hand
Three weeks later nobody can say where a line came from.
On Aestus
Every line links the ticket and the pull request it came from, and the links are built by the product, not typed by a model.
By hand
A quiet week still produces a padded entry.
On Aestus
A quiet week produces no entry, and lists why each closed ticket was left out.
By hand
Somebody pastes the entry into the team channel by hand, late, and typos it.
On Aestus
Once you approve, it posts the entry to the Slack channel you chose, with a link to the full cited draft.
By hand
Nobody knows what the changelog cost or how long it took.
On Aestus
Every run is recorded with its cost, its tokens and its outcome.

What Aestus records

Every run is auditable after the fact, which is what makes handing the job over survivable.

The draft
A document on the ticket you anchored it to, kept with its revisions, so the entry you published in week one can be reread in week six.
The evidence
The table it worked from: ticket, title, closed date, who produced it, the outcome and the pull request. Every number in the draft is recomputed from this table rather than taken from the model.
The run
Cost, tokens, how long it took and whether it succeeded, on the same ledger as every other run in the workspace.
What it could not see
How many tickets sat on teams the run could not read and how many pull requests were in repositories that are not connected — reported as a number rather than left out.

What it connects to

Only the tools this workflow actually uses. Each one has a setup guide.

slackOptional

Questions teams ask

Does it publish anything on its own?

No. It stops and asks before posting. Until you approve, nothing leaves Aestus. It never writes to your repository: there is no branch and no pull request.

What if nothing a customer would notice shipped?

It says so, and lists each closed ticket with the reason it was left out. It does not pad the entry. That branch is a path in the workflow rather than a rule in a prompt, so a model cannot write its way out of it.

Can it see work my team cannot see?

No. It reads what the account running it can read, and it reports how many rows it could not see rather than hiding the gap.

Does it need the board, or just GitHub?

It needs the board. A merge tells it code changed. A move into a column you marked terminal tells it the team decided the work is done, and that is the difference between a commit log and a changelog. It needs no GitHub connection of your own, and Slack only if you want the entry posted.

All use cases How access is governed

Sources

https://keepachangelog.com/en/1.1.0/
https://docs.github.com/en/repositories/releasing-projects-on-github/automatically-generated-release-notes
https://github.com/release-drafter/release-drafter

Hand over Write the changelog.

Tell us how your team does this today and we will set it up with you.

Talk to us

Questions teams ask

Does it publish anything on its own?

No. It stops and asks before posting. Until you approve, nothing leaves Aestus. It never writes to your repository: there is no branch and no pull request.

What if nothing a customer would notice shipped?

Can it see work my team cannot see?

No. It reads what the account running it can read, and it reports how many rows it could not see rather than hiding the gap.

Does it need the board, or just GitHub?

Sources

https://keepachangelog.com/en/1.1.0/

https://docs.github.com/en/repositories/releasing-projects-on-github/automatically-generated-release-notes

https://github.com/release-drafter/release-drafter

The changelog, drafted from what your board says shipped

Write the changelog

What you get

Changelog draft — 2 September to 5 September 2026

How it runs

By hand, and on Aestus

What Aestus records

The draft

The evidence

The run

What it could not see

What it connects to

Questions teams ask

Hand over Write the changelog.

The changelog, drafted from what your board says shipped

Write the changelog

What you get

Changelog draft — 2 September to 5 September 2026

How it runs

By hand, and on Aestus

What Aestus records

The draft

The evidence

The run

What it could not see

What it connects to

Questions teams ask

Hand over Write the changelog.