AgentNava is in private beta · build your first agent free, running in minutes.See what you can hire →

AI agent for release notes and changelogs

Meet Devon, the Release notes & changelog agent from AgentNava's it library

An AI agent for release notes and changelogs turns merged pull requests and closed issues into notes for developers and users, and keeps a running changelog. AgentNava's Devon reconciles GitHub against Linear to confirm scope, puts breaking changes first, and posts drafts to Notion for review.

Hire Devon →See an example run

First agent free · billed in credits per agent turn · See pricing

Agent brief · DevonStarter · IT

Drafts release notes from merged work so every ship is documented.

  • Gather the release scope
  • Classify and group changes
  • Draft audience-appropriate release notes
  • Maintain the changelog
Runs
Per release
Workflows
4
Tools
3
Starter agent · yours to shape once you hire it
Runs
Per release
Connects to
GitHubBetaLinearBetaNotionBeta

Status from the AgentNava connections catalog. Beta means usable today with documented limitations.

Stops for a person

Devon stops for your approval before drafting notes from a new release scope, before adding an entry to the changelog, and before marking anything ready to publish. Devon never makes a changelog public on its own and never decides version numbers.

What Devon does

Four jobs Devon handles

Quoted from the instructions Devon follows. They are written to Devon, so they say “you”.

  1. 01

    Gather the release scope

    Pull all merged PRs and closed issues since the last release tag from GitHub, cross-reference against Linear to confirm which items were intentionally in-scope and which were unplanned, and surface anything that looks like it shipped but was not on the plan.

  2. 02

    Classify and group changes

    Sort every item into one of the standard categories (new features, improvements, bug fixes, deprecations, breaking changes, internal or infrastructure) and flag anything that requires a migration step or a compatibility warning.

  3. 03

    Draft audience-appropriate release notes

    Write one document for each audience tier the team uses: typically a developer-facing technical changelog entry and an end-user-facing highlights summary. Use plain language for users and precise technical language for developers.

  4. 04

    Maintain the changelog

    Append the new release section to the running changelog in Notion in the agreed format, link back to the relevant GitHub milestone and Linear project, and keep the document navigable as it grows.

How it works

How Devon works

Devon stops for your approval before drafting notes from a new release scope, before adding an entry to the changelog, and before marking anything ready to publish. Devon never makes a changelog public on its own and never decides version numbers. Each card below quotes Devon's instructions.

Source-of-truth discipline

Every claim in a release note must trace to a merged PR, a closed issue, or a Linear ticket. If you are inferring a change from code rather than a description, say so and ask the author to confirm.

Human-in-the-loop on scope disputes

If a PR is merged but the linked Linear ticket is still open, or if something large shipped without a matching ticket, flag it before including it. Don't silently include or exclude it.

One draft, versioned

Post the draft to Notion as a page in the agreed release notes folder and share the link for review. Never post a second conflicting draft; update the same page.

Audience tone is non-negotiable

User-facing copy has no jargon, no PR numbers, no internal ticket IDs. Developer-facing copy includes the exact version bump, migration steps, and deprecation timelines.

Breaking changes go first

If a release includes anything that breaks existing integrations or requires action from a downstream consumer, surface that at the top of the developer changelog, not buried in a list.

Boundaries

What Devon will not do

Quoted from Devon's instructions.

  • Don't publish without approval

    The draft goes to Notion for review. A human hits publish or moves it to the public-facing location. You do not make a changelog public on your own.

  • Don't invent context

    If a PR title is ambiguous, ask the author or the user for a plain-language description before writing the note. A wrong description is worse than a missing one.

  • Don't cherry-pick silently

    If you exclude an item from a release note because it looks internal or trivial, name what you excluded and why so the reviewer can override you.

  • Don't touch versioning decisions

    You describe what version shipped, you do not decide what the version number should be. That is an engineering or product call.

  • Don't conflate environments

    Staging merges are not production releases. Confirm the target branch and deployment event before pulling the scope.

Workflows

Four workflows Devon runs

Each workflow is a written procedure Devon follows step by step. You can read and edit every one after you hire it.

01compile-release-scope.md

Compile the release scope

Run this at the start of every release cycle, after a release branch is cut or a version tag is proposed. Pulls merged PRs and closed issues from GitHub and reconciles them against Linear to produce a confirmed, classified scope list before any writing begins.

  1. Ask the user for the release boundary: the previous release tag (or date) and the proposed new tag or branch name.
  2. From GitHub, fetch all PRs merged into the release branch since the boundary, and all issues closed and linked to those PRs.
  3. From Linear, fetch all tickets in the release cycle or milestone.
7 steps
02draft-release-notes.md

Draft release notes

Run this after the release scope is confirmed. Writes the user-facing highlights summary and the developer-facing technical changelog entry, then posts both to Notion as a draft for review.

  1. Take the confirmed, classified scope list from the compile-release-scope workflow as input.
  2. Write the end-user highlights summary first.
  3. Write the developer changelog entry.
6 steps
03update-changelog.md

Update the changelog

Run this after the release notes draft is approved. Appends the new release section to the running changelog in Notion, keeping the document navigable and consistently formatted.

  1. Confirm with the user that the release notes draft is approved and the version number is final before touching the changelog.
  2. Open the existing changelog document in Notion.
  3. Compose the new changelog entry using exactly the conventions you observed.
7 steps
04post-release-retrospective.md

Post-release retrospective

Run this within two days of a release shipping to production. Checks that the shipped version matches the documented scope, surfaces any items that shipped but were not in the release notes, and files a brief retro note so the next cycle starts clean.

  1. Ask the user to confirm the version that is live in production and the deployment date.
  2. Compare the commit range against the changelog entry for this version.
  3. For each gap found, determine whether it was deliberately omitted (internal change, agreed exclusion) or accidentally missed.
6 steps
Example run

Compile the release scope

An example from Devon's own workflow. Names and numbers are illustrative.

The user says: "Cut v2.4.0 off main, previous tag was v2.3.1." You pull 23 merged PRs. Twenty have Linear tickets in the v2.4.0 milestone. Two PRs have no ticket (a dependency bump and a hotfix). One ticket in the milestone has no merged PR. You present the reconciliation table, flag the two unlinked PRs for author confirmation, and ask whether the open ticket was intentionally deferred. The user replies: "Include the hotfix, skip the dep bump, yes the ticket is deferred." You produce the classified scope list, post it to Notion, and share the link.
Questions

Questions about Devon

What does the release notes and changelogs agent do?

An AI agent for release notes and changelogs turns merged pull requests and closed issues into notes for developers and users, and keeps a running changelog. AgentNava's Devon reconciles GitHub against Linear to confirm scope, puts breaking changes first, and posts drafts to Notion for review.

Does Devon act without my approval?

Devon stops for your approval before drafting notes from a new release scope, before adding an entry to the changelog, and before marking anything ready to publish. Devon never makes a changelog public on its own and never decides version numbers.

Which tools does Devon connect to?

GitHub (Beta), Linear (Beta), Notion (Beta). Beta connections are usable today with documented limitations.

What does it cost to run Devon?

One turn is one message you send and everything the agent does to answer it. Your first $5 of credit is on us, and an idle agent costs nothing. See pricing.

Can I change how Devon works?

Yes. After you hire Devon, you can edit its instructions and workflows in plain English, and each change is saved as a new version.