Product
You shipped twenty-three things and announced four
A draft built from what actually merged, plus a list of the changes nobody described.
What the worker does
Release notes from an AI worker are assembled from merged pull requests since the last tag. The worker reads each pull request and its linked issue through the GitHub and Linear connections, separates user-visible changes from internal work, drafts notes in your house format, and returns a question list for the changes whose descriptions explain nothing. A person edits and publishes; the worker never publishes anything.
- Trigger
- Each release cut
- Connections
- GitHub, Linear, Notion
- Output
- Draft plus a question list
Release notes lose to everything
They are written after the release, by the person most relieved that the release is over, for an audience whose reaction nobody measures. So they get written for the three changes somebody remembered and skipped for the rest, and customers learn about improvements six weeks later by accident.
The raw material is complete and sitting in the repository. Every merged pull request has a title, a description of some quality, and usually a linked issue explaining why the work happened.
How the draft gets built
- 1
Find the boundary
Everything merged since the previous tag. The worker states the range it used at the top of the delivery, so you can tell immediately if it started in the wrong place.
- 2
Split user-visible from internal
A refactor and a new export button both merged. Only one belongs in the notes. Where the split is ambiguous, the change appears in a third list rather than being silently sorted.
- 3
Follow the link to the issue
Pull request descriptions explain what changed. Linked issues explain why it mattered, which is what a customer-facing note needs. The worker reads both.
- 4
Write in your format
Grouping, heading style, whether you name contributors, whether you link the issue. These live in the worker's SKILL.md as rules, so the draft arrives in your shape rather than a generic one.
- 5
Ask about the rest
Pull requests titled fix stuff get listed as questions with links, not guessed at. That list is usually short and takes two minutes to answer.
What the worker can tell, and what it has to ask
| From the repository | Only from you |
|---|---|
| What files changed and when it merged | Whether the change is worth announcing |
| The pull request title and description | How to describe it to a non-technical customer |
| The linked issue and its labels | Whether it closes a promise made to a specific account |
| Who wrote it and who reviewed it | Whether this release deserves a headline at all |
The side effect worth having
Bad pull request descriptions become visible
The question list is a weekly report on which changes shipped without an explanation. Teams that read it tend to write better descriptions within a month, which is a bigger win than the notes.
The gap between shipped and announced closes
Once a draft exists on every release cut, publishing becomes an edit rather than a writing task, and edits actually get done.
Questions people ask
+Does the worker need write access to the repository?
No. It reads merged pull requests and linked issues through the GitHub connection and delivers the draft as a comment on a Polaris task. Publishing is a human action taken wherever your changelog actually lives.
+What if our pull request descriptions are useless?
Then the question list will be long, which is the honest result. The worker is briefed to ask rather than to invent, so a change it cannot interpret appears as a link and a question instead of a confident sentence that turns out to be wrong.
+Can it write notes for a mobile release too?
Yes, if the changes are in a repository the GitHub connection can reach. Store-listing text has its own constraints, so most teams write that rule into the skill file rather than reusing the web format.
+How long does a release notes job take?
Long enough to read every merged pull request in the range, which the work log records job by job. Billing is about $2 per human-hour delivered, estimated from observable effort including the prose produced, and every line can be challenged from the log.
Related
Product management with an AI worker on the roster
Five jobs a product team can hand to an AI teammate, and the ones it should never hand over.
The README describes a version of the code that no longer exists
A monthly list of statements in your docs that the code no longer supports.
Six open pull requests and nobody knows whose turn it is
The review queue, ordered by age and named by who is blocking it, posted every morning.
Connect GitHub to Polaris
Fine-grained tokens let you hand over three repositories instead of an account, which is the whole reason to use them here.
Hire an AI technical writer
The documentation debt on your team is not a writing problem, it is a nobody-has-two-free-hours problem, and this is the worker for those two hours.
Delivery comment
Work arrives where the task already lives, attributed and reviewable, and the task stays open.
Agents deliver, humans close
One rule holds the whole product together, and it is a rule about who is allowed to say finished.