Publish your changelog from Claude Code or Cursor

The agent that wrote the change already knows what changed. Writing the release note is the step that gets skipped, because it means leaving the editor, opening a dashboard and remembering what you did on Tuesday. Moving that step into the coding session is the whole idea.

What you need

1. A changelog tool with an MCP server, so the agent can call it as a tool.
2. A coding agent that speaks MCP: Claude Code, Cursor, VS Code with Copilot, Claude Desktop.
3. A repository with a git history.

Several changelog tools have an MCP server now; the table above shows which, as read from their own sites. What follows uses Nordva Launch, because its server ships a prompt written for exactly this job, but the workflow is the same with any of them.

Setup, once

npx nordva@latest init

It signs you in through the browser (or signs you up; the free plan has 25 changelog entries), writes your keys to the env file your framework reads, and installs the MCP server for the coding tools it finds. Nothing to copy or paste. Setup by hand is on the Claude Code and Cursor pages.

The prompt

In Claude Code the server’s prompts are slash commands:

/mcp__nordva__draft_changelog_from_commits

In other clients, pick draft_changelog_from_commits from the prompt list, or paste the short version:

Draft a changelog entry from what changed in this repository since my last published entry. Do not publish until I say so.

What the agent then does:

1. Calls list_changelog_entries to find your last published entry: its date, its version, and how you write.
2. Runs git log since that date, and checks for a new version tag. It looks at a diff only when a commit message does not say what it did.
3. Keeps what a user would notice. Refactors, dependency bumps, CI and tests are left out unless they fix something visible. No file names, function names or people.
4. Writes one entry: a title in the user’s words, two to six lines, a category (feature, improvement, fix, security, breaking), and the version if there is a tag.
5. Shows you the draft and asks: publish now, schedule, or change something.

Only after your answer does it call publish_changelog_entry. The entry appears on your hosted page at launch.nordva.dev/log/<your-slug>, in the embeddable widget, and in the RSS, Atom and JSON feeds.

Making the drafts good

• Write commit messages for a reader. “fix export for lists over 2,000 rows” drafts itself. “wip” does not.
• Tag releases. The agent uses the newest tag as the version.
• Publish your first two entries by hand. The agent copies the tone and length of what is already there. If there is nothing, it has nothing to copy.
• Say what to leave out. “Skip anything about the admin panel” is a fine instruction.
• Use since for a catch-up. The prompt takes a date or a git ref: everything since v1.3.0, or since 2026-09-01.

Editing, scheduling and telling people

A scheduled entry can be changed with update_changelog_entry: fix the typo, move the time, or publish now. A published entry cannot be edited; archive it and publish the corrected one.

If you want the entry to reach people beyond the page, add a webhook for changelog.entry.published pointing at a Slack or Discord incoming-webhook URL. Launch recognises those and sends a readable line instead of JSON.

When this is the wrong approach

If a product marketer owns your release communication, wants segmentation, popups and in-app tours, and works from a dashboard, an announcement tool built for that job will serve them better than an agent in a terminal. This workflow is for the case where the person shipping the change is also the person who has to tell users about it.