Automate Release Notes From Linear With AI

Short answer. The shortest path is Linear's own Releases. On the Business and Enterprise plans, Linear's agent writes release notes from the issues in a release, to a template you control, and can generate them each time a release reaches production. If you are on a lower plan or need a different format, the options are a script that sends shipped issues to an LLM, Zapier into one specific notes app, or GitHub's own generated notes if you work from pull requests. Linear's Release CLI and GitHub Action build accurate releases from CI, but they feed Releases, so check your plan before you set them up. Modem (our product) covers a different slice. Its opt-in weekly changelog drafts notes from merged GitHub PRs, plus the titles of linked Linear issues, and posts the draft to an internal destination. Its instructions tell it not to name customers (read the first draft to confirm), and it has no hosted changelog page. On request, it can also draft notes aimed at the customers who asked. Whichever you pick, have a person read the draft before customers do.

Your Linear issues already describe what shipped, so release notes are mostly a formatting and filtering problem. What changes between tools is the trigger (what counts as shipped), who the notes are for (developers, the wider team, or customers), and how much a person still assembles by hand.

Decide these five things before you pick a tool

You can settle all of these without buying anything, and most failed setups skip at least one.

What counts as shipped? Pick one event: a release reaching production, a tag, a deploy, or a weekly schedule. A merged pull request is not a release. It may sit behind a deploy, a feature flag or a staged rollout, and telling customers something is live when it is not is worse than silence.
Make the source text readable. Automation is only as good as the issue and PR text it reads. A common fix is to add a short "release note" field to the PR template so the engineer writes one customer-readable sentence while the work is fresh. Failing that, write issue titles for the person who will read the changelog, not for the person who triaged the bug.
Decide what is customer-visible. Internal refactors, test changes and invisible performance work should not appear. Pick a rule you can apply mechanically, such as a label or a project, and tell the drafting step to use it.

Draft with a prompt you control. If a tool lets you edit the template, start with something like this:

You are writing release notes for customers, not engineers.
Input: the issues included in this release (title, description, labels).
Skip anything labeled internal, refactor, test, or infra.
Group what remains under New, Improved, and Fixed.
One sentence per item, starting with what the user can now do.
Do not mention customer or company names.

Put a person between the draft and the audience. The sources we found on this, from engineering threads to vendor posts, converge on the same point: AI drafts, a person reviews before publishing.

Then pick the tool that fits your trigger and audience.

The short version

Tool	What it does	Needs	Audience
Linear Releases	Linear's agent writes notes from the issues in a release	Linear Business or Enterprise	Team and changelog
Modem	Weekly draft from merged GitHub PRs and linked Linear issue titles; per-requester drafts on request	GitHub for the weekly template	Internal team; customers on request
Linear Release CLI and GitHub Action	Builds accurate releases from commits and PRs in CI; the Action attaches notes you produce	CI; Releases for the notes feature	Developers
Automated-release-notes (open source)	Script: Linear cards plus an LLM, written to markdown	An engineer to maintain it	Whoever you send it to
Zapier with the ReleaseNotes app	Adds a note per Linear issue update	A ReleaseNotes account	Changelog readers
GitHub generated notes or Release Drafter	Notes from merged PRs, grouped by label	PRs with consistent labels	Developers and public changelogs

1. Linear Releases

Start with the built-in. Linear Releases, launched in the April 30, 2026 changelog, connects your CI/CD tool to Linear so it knows which issues shipped in each release and environment. Pipelines are continuous or scheduled. Release notes can be written by hand or generated: the Linear agent analyzes the issues in a release (scheduled pipelines) or a range of releases (continuous pipelines), formatted by a Template field in the pipeline settings. You can also turn on auto-generation each time a release hits production, and every pipeline has a changelog tab that assembles its notes in order.

The plan gate matters. Releases is available on Business and Enterprise, with Business capped at 15 pipelines. That means "zero new vendors" can still mean a plan upgrade, so check Linear's pricing page before you count it as free.

Two things we did not find in Linear's docs: a way to publish the changelog tab outside your workspace, and any use of customer-request data inside generated notes. Linear does store who asked (Customer Requests), and it updates the synced Slack thread or reopens a linked Intercom or Zendesk conversation when an issue completes. That is a status notification to the source thread, not a release note.

Where it fits: teams already tracking work in Linear on Business or Enterprise who want team and changelog notes generated from the issues in a release. Try it before buying anything.

2. Modem

Modem's weekly changelog is a template in its Automations library, off until you install it. It runs on a schedule you can edit (Monday mornings UTC by default), reads the pull requests merged in the last seven days, and drafts a customer-readable changelog. It uses PR titles and descriptions, plus the titles of linked Linear issues where a link exists. It keeps user-facing changes only, caps the draft at around ten to twelve items, groups them into New, Improved and Fixed, and posts the draft to the internal destination you choose, by default Slack. The weekly draft is written for all customers, and the template's current instructions tell it not to name any; read the first few drafts to confirm before you rely on that.

On request, a different job. Ask the agent in the dashboard or Slack, for example "draft release notes for the top requesters of what we shipped, referencing their original feedback" (an illustrative prompt), and it drafts notes aimed at specific customers. It can do that because Modem has already grouped customer conversations into topics with the people and companies who raised them. That is the case the weekly template does not cover. Replies can go only through Slack, Discord, Intercom or Pylon (once an admin enables them), and Plain. In Slack and, by default, in the dashboard, a customer-facing send shows an Approve or Deny card first. Keep customer names out of anything public unless those customers agreed.

Why it works this way. The template is a tested format that keeps improving unless you edit its prompt, and editing the prompt stops those updates. It drafts and stops because a changelog goes out in your company's name, so a person decides what is sent. The weekly output is generic and the personalized version is a separate request, because a broadcast and a reply to one customer are different messages. Modem sees merges, not releases, so time anything customer-facing to your own release.

Limits.

The weekly template requires GitHub. A team that tracks work only in Linear, or uses GitLab or Jira, cannot install it as written. The agent can still draft notes from Linear issues on request in chat.
It drafts only. It does not publish, email customers on its own, or host a changelog page.
Quality follows your PR titles and descriptions. Modem does not read source code.
Security fixes, refactors and invisible performance work are dropped by default, so edit the prompt if you want them.

Where it fits: teams that merge to GitHub weekly, want a first draft waiting for them without collating anything, and sometimes want a note aimed at the people who asked. Where it doesn't: a hosted public changelog, or Linear-only release notes. Linear Releases is the better tool there.

3. Linear Release CLI and GitHub Action

For CI-driven pipelines, the Linear Release CLI scans the commits since the last release for Linear issue identifiers in branch names and commit messages, detects pull request numbers, and creates or updates the release. Its commands are sync, complete and update. The GitHub Action wraps the CLI and can attach a release notes file and supporting documents. It attaches notes your workflow already produced. It does not write them.

This is plumbing, not prose, and it keeps releases accurate so whatever writes the notes has correct inputs. One known limitation: squash-merged release PRs can hide issue identifiers in the commit body (see issue 147). We checked the CLI's feature description but not its own plan requirements. It feeds Releases, which is Business and Enterprise.

Where it fits: teams that cut releases from CI and want Linear's release objects maintained without manual curation.

4. Automated-release-notes (open source)

If you want full control of tone and format, Automated-release-notes is a small TypeScript script that reads Linear cards, has an OpenAI model summarize and categorize each, and assembles categorized notes. You run it with your Linear and OpenAI API keys. Its README calls it "not a ready-to-use package, but a simple, readable script."

Check before adopting. It reads a specific "Deployed (this week)" column, which is one team's workflow, it used an older OpenAI model when we last looked, and we could not confirm it is still maintained. Treat it as a starting point you own.

Where it fits: teams with a strong opinion on format and someone willing to maintain a script.

5. Zapier with the ReleaseNotes app

The no-code route is Zapier's Linear and ReleaseNotes integration. It adds a note to the ReleaseNotes app whenever a Linear issue is updated, appending to that app's activity feed. This is one specific app, not any hosted changelog tool. Zapier also lists other release-notes automation templates if you use something else.

Because the trigger is a per-issue update, you get fragments that a person still assembles into a release. It needs no engineering time, though we did not check Zapier plan limits for this flow.

Where it fits: non-technical owners of a changelog who cannot wait on an engineer.

6. GitHub generated notes and Release Drafter

If your changelog comes from pull requests rather than Linear issues, two GitHub-native options do the grouping for you. GitHub's generated release notes build notes from merged PRs, categorized by label and author in a .github/release.yml file. Release Drafter is an open-source Action that drafts your next release notes as PRs merge, categorized by labels, paths or conventional commits. Neither is Linear-aware, so Linear details reach the notes only if your PRs carry them in labels or titles.

Where it fits: PR-label-driven repositories where Linear is not the source of truth for what shipped.

How to choose

On Linear Business or Enterprise, notes for the team or changelog: Linear Releases.
Cutting releases from CI, need accurate release objects: the Release CLI and Action, with notes from Releases or your own step.
Not on Business and unwilling to upgrade: the open-source script, or GitHub-native notes if PRs are your source.
A non-technical owner, one notes app: Zapier with ReleaseNotes.
Merging to GitHub weekly and want a draft in Slack, or notes for the customers who asked: Modem.

These combine. A team can use Linear Releases for the changelog and ask Modem for the version aimed at specific requesters. For the customer-facing side, see how to notify customers when their feature ships and how to close the feedback loop with customers. To get the requests into Linear in the first place, see the best tools to turn customer feedback into Linear issues.

FAQ

How do I automate release notes from Linear issues with AI?

Pick one shipped event, make your issue or PR text readable, decide what is customer-visible, then let an LLM draft and a person review. In Linear itself, the built-in route is Releases, where the agent writes notes from the issues in a release and can generate them each time a release reaches production. It needs the Business or Enterprise plan.

Does Linear generate release notes automatically?

Yes, on Business and Enterprise. Linear Releases uses the Linear agent to analyze the issues in a release and writes notes to a template you set in the pipeline settings. Auto-generation on production is an option. We did not find documentation that generated notes use customer-request data.

Can release notes say which customers asked for a feature?

Linear stores who asked through Customer Requests, but we found no documented use of that data in generated notes. Modem can draft notes aimed at specific requesters when you ask, because it groups customer conversations into topics with the people behind them. A person reviews the draft, and in Slack and, by default, in the dashboard customer-facing sends wait for approval. The weekly changelog template names no customers.

Does Modem publish a changelog?

No. It drafts, and the draft goes to an internal destination such as Slack. Modem has no hosted changelog page, and it does not email customers on its own.

Does Modem's weekly changelog need GitHub?

Yes. The template reads merged GitHub pull requests from the last seven days and adds the titles of linked Linear issues where a link exists. A Linear-only team can ask the agent for a draft in chat, or use Linear Releases.

Can Zapier send Linear updates to any changelog tool?

The integration we found is specific to the ReleaseNotes app. It adds a note to that app when a Linear issue is updated. Other tools would need their own Zapier integration or a webhook.