What the agent does
The agent clones the library into its sandbox. On a repository like colinhacks/zod it finds a Nub workspace (packageManager: "nub@0.8.3") with packages under packages/*, the published library at packages/zod (currently version 4.6.7 in packages/zod/package.json), Vitest configs at vitest.config.ts and vitest.compile.config.ts, and source under packages/zod/src with v3, v4, v4-mini and mini trees. It does not install or publish; it only needs git history and the source tree.
It resolves the last two release tags (for example v4.6.6 and v4.6.7, or a wider pair you name in the prompt such as v4.6.0..v4.6.7). Between those tags it lists merged pull requests and their commits: features such as z.currencyCode(), z.iban(), .validate() / .validateAsync(), and z.withParser; fixes such as array/set/map size bounds before parsing elements (#6652), keeping prefault outputs that resolve to no value (#6587), and unique tags with defaulted discriminators (#6582); and docs or CI-only commits it keeps out of the user-facing sections. Each item is grouped into features, fixes or breaking changes from the PR title and the files touched under packages/zod/src.
For every change that looks breaking, it opens the migration material already in the repo when it exists (packages/docs/content/v4/changelog.mdx for the Zod 3→4 guide, and the 4.6 announcement docs under packages/docs) and the implementation files the PR touched. It writes an upgrade guide entry with a before and after TypeScript sample, then checks that the after sample matches APIs that still exist in the tagged source (for example error instead of message, or a new string format helper). Samples that cannot be verified against the tree are marked as needing a human check rather than invented.
Output is two Markdown files in the sandbox: release-notes.md and the upgrade guide (as a section of that file or a sibling upgrade-guide.md when the breaking list is long). No tag is created, no npm publish runs, and no pull request is opened.
Start it with one API call
POST https://api.prix.dev/o/{org}/sessions with this body:
{
"agent": "claude",
"input": "Read the commits and merged pull requests in https://github.com/colinhacks/zod between the last two release tags. Write release-notes.md grouped into features, fixes and breaking changes, and an upgrade guide for each breaking change with a before and after code sample checked against the source."
}- Get an API key. In the console, open Settings, then API keys, and create a key for your org. Send it in the Authorization header as a Bearer token.
- Send the request. POST the body in request.json to https://api.prix.dev/o/{org}/sessions, with your repository as the resources URL. The run starts in its own cloud sandbox.
- Read what came back. Follow the run on its live stream or wait for the run.completed webhook, then read the result and its trajectory.
What comes back
What comes back is release-notes.md (and an upgrade guide section or file) as session artifacts. The notes list features, fixes and breaking changes with PR numbers where they exist; the upgrade guide gives a before/after sample per breaking item, checked against packages/zod/src.
A maintainer pastes the notes into the GitHub release body and keeps the upgrade guide for the docs site. Before publishing, they confirm the tag pair is the one they meant, drop any internal CI commits that slipped into features, and verify each before/after sample in a scratch file.
Run it on every new library release tag
On a create webhook for tags matching v*, your server sends this request with the new tag and its predecessor in the prompt. The agent writes the notes from the merged PR list between those tags while the release is still a draft.
When the run completes, the API key webhook delivers the session URL; attach release-notes.md to the draft GitHub release so the published text matches the commits.
The use case this job follows, with its automation and trigger: Produce a report or file, no repo.
Why run it on Rush?
Writing release notes by hand means scrolling merged PRs and hoping you remember which API rename matters to users. The agent walks the tag range, reads the source those PRs touched and drafts notes and upgrade samples in one pass, with every git and file read kept in the transcript.
The work stays in a sandbox clone: your laptop checkout, your npm tokens and your tags are untouched. Several libraries can get notes in parallel, each run naming its own repository URL in the prompt.
Frequently asked questions
Will it create a git tag or publish to npm?
No. It only reads history and source and writes Markdown artifacts. Tagging and npm publish stay on your release workflow.
What if the last two tags are only a patch apart?
You get a short notes file for that patch. To cover a minor, name the tag range in the prompt (for example v4.6.0 to v4.6.7) so features landed across several patches are included.
Does it work on a private TypeScript library?
Yes. Install the Rush GitHub App, put the repo in resources as {"url": "https://github.com/your-org/your-lib"}, and adjust the prompt to use that clone instead of a public URL.
How does it know something is breaking?
From PR labels and titles when present, from removals or renames in packages/zod/src, and from existing migration docs in the repo. Ambiguous cases are listed under breaking with a note that a human should confirm.