Use cases
Releases that go out without a ritual
When the merged work justifies a release, the agent drafts the changelog and cuts the tag on the policy you committed — and never holds a token you did not grant it.
Pull request #731
Handle expired workspace tokens
+ if (token.expiresAt < Date.now()) {
+ await rotateWorkspaceToken(token)
+ }The release is the last thing to get automated and the easiest to get wrong
Most teams automate the build and leave the decision, the changelog and the tag to whoever remembers. developerz.ai reads what merged since the last release, drafts the notes from the actual pull requests, and cuts the release when your policy says it is due. Publishing rights stay with your GitHub App installation and your branch protections; there is no separate publish token handed to us, and every release action is an audit entry.
Notes from the merges, not from memory
The changelog is drafted from the pull requests that actually landed, in the window since the previous release.
Your cadence, in the policy file
Per-repo release rules live in .maintainer.yml alongside everything else, versioned in the repo like the rest of your config.
Auditable, like everything else
A release is a logged action with an actor and a reason, not an opaque button somebody pressed.
Go deeper
See what we shipped ourselves
We dogfood this: our own changelog is generated by the same lane, on our own repository.
Read the changelogPut a fleet of AI developers to work
Bring your own keys and your own boxes, drop a .maintainer.yml, and let the loops run — audited end to end. Access is invite-only.