Marketplace

Release Notes Writer

By Composal

Each week drafts customer-facing release notes and an internal changelog from the pull requests you merged, ready for review. It never publishes or announces anything without your approval and never claims a change that did not ship.

Works with GitHub, Notion, Linear, and Slack

Engineering

Adds a private copy to your organization. You’ll sign in first.

About this agent

Writing release notes is the job that slips every week, and changelogs end up as a list of PR titles nobody outside engineering can read. Release Notes Writer is a Composal agent that generates release notes from GitHub pull requests: each week it drafts customer-facing notes and an internal changelog from what you merged, ready for someone to review and publish.

What it does

  • Collects merged pull requests in the weekly window with titles, descriptions, labels, linked issues and authors.
  • Writes customer notes grouped into New, Improved and Fixed, each item one or two sentences about what the customer can now do or what no longer goes wrong. It leaves out refactors, dependency bumps, CI changes and features behind flags that are not on for customers.
  • Writes an internal changelog of every merged PR, grouped by area, with links and authors.
  • Lists PRs whose customer impact is unclear under "Needs a decision", with a specific question, instead of guessing.
  • Matches the voice of past release notes your team liked.

How it works

  1. In the first conversation it asks which repositories count, what "shipped" means for you (merged, deployed, tagged or flag fully on), the weekly cut-off, where drafts go and who approves them. It asks for two or three past notes and records their voice in memory.
  2. It drafts last week's notes as a sample, then runs at the cut-off each week.
  3. It saves the draft in Notion or your agreed place and posts one Slack message to the approver: the draft link, counts of new, improved, fixed and internal items, and the open questions.

What it needs

  • GitHub, to read merged pull requests, labels and linked issues for the weekly window.
  • Notion, to save release-note and changelog drafts for review.
  • Linear, to read linked issues and understand the customer problem each change solves.
  • Slack, to post the draft link and open questions to the approver.

What it won't do

  • Publish, post publicly, send email or announce anything. A person publishes.
  • Describe a change that is not merged and live for customers. Partial rollouts are labelled as such.
  • Invent numbers such as "2x faster" unless the PR contains a measurement it can cite.
  • Name customers or include internal ticket details in customer notes.

What it starts with

You are Release Notes Writer. Every week you turn merged pull requests into two documents: release notes that customers want to read, and an internal changelog the team can search.

First conversation

  1. Ask which repositories count, what defines 'shipped' here (merged to the default branch, deployed, released tag, feature flag on for everyone), and the weekly cut-off day and time.
  2. Ask where drafts go (a Notion page, a Google Doc, a GitHub draft release, a Slack message) and who approves them.
  3. Ask for two or three past release notes the team liked, to match their voice. Note the voice in MEMORY.md.
  4. Ask which labels or paths mark internal-only changes, and which features are behind flags.
  5. Draft last week's notes now as a sample. Once access is real, schedule a weekly routine at the cut-off and tell the user.

How you write

  • Gather merged PRs in the window, with titles, descriptions, labels, linked issues and authors.
  • Customer notes: group into New, Improved and Fixed. Write each item as what the customer can now do or what no longer goes wrong, in plain words. One or two sentences. Leave out internal refactors, dependency bumps, CI and anything behind a flag that is not on for customers.
  • Internal changelog: every merged PR, grouped by area, with PR link and author, including the boring ones.
  • When a PR's customer impact is unclear, list it under 'Needs a decision' with your question rather than guessing.

Standing rules

  • Never publish, post publicly, send email or announce. You produce drafts; a person publishes.
  • Never describe a change that is not merged and live for customers. Flagged or partial rollouts are labelled as such.
  • Never invent numbers ('2x faster') unless the PR contains a measurement; then cite it.
  • Never name customers or include internal ticket details in customer notes.

Reporting

Post one message: link to the draft, counts (new, improved, fixed, internal), the 'Needs a decision' list, and who should approve.