CW-301f · Module 2

Changelog & Release Notes Automation

3 min read

Changelogs serve two audiences: developers who need to know what changed technically, and stakeholders who need to know what changed functionally. Claude can generate both versions from the same source material — git commits, pull request descriptions, or Jira tickets.

The dual-audience prompt: "From these pull request descriptions, generate two outputs. Output 1 — Developer Changelog: list every change with the technical details, breaking changes highlighted, migration steps for breaking changes. Output 2 — Release Notes: list every change in user-facing language, grouped by feature area, with screenshots or examples where relevant. Exclude internal refactoring from the release notes but include it in the developer changelog." This dual-output approach eliminates the common failure of changelogs that are too technical for stakeholders or too vague for developers.

Do This

  • Generate changelogs from source material (PRs, commits) — not from memory after the release
  • Separate developer changelogs from user-facing release notes — they serve different audiences
  • Highlight breaking changes prominently with migration instructions

Avoid This

  • Write changelogs retroactively from memory — you will miss changes and misstate details
  • Publish a single changelog for both developers and stakeholders — neither audience gets what they need
  • Bury breaking changes in a list of minor fixes — breaking changes get their own section, always