Pull request titles are convenient changelog inputs because your team already writes them. They are also uneven: one describes a user benefit, another names an internal ticket, and a third says only “cleanup.” Current good practice is to treat titles as structured source material, not finished release notes. This sprint sets up a lightweight path from merged work to a readable, trustworthy changelog.
Set a PR title contract before collecting entries
A useful title names the change and the affected behavior. Prefer “Preserve dashboard filters after refreshing” to “Fix state handling.” You do not need marketing copy in every pull request, but you do need enough context for someone outside the implementation to understand what changed.
If your team uses Conventional Commits, a title such as “fix(search): retain filters after refresh” can support consistent parsing. Keep the prefix vocabulary small and documented. Treat a breaking-change marker as a signal to inspect the change, not as a substitute for migration instructions.
- Describe observable behavior: identify what users can now do or what no longer fails.
- Name the affected area: distinguish dashboard search from API search.
- Keep private details out: exclude customer names, credentials, and sensitive incident context.
- Fix the title before merging: make editorial quality part of the review checklist.
Use release labels to separate audience from implementation
A title explains the change; labels decide where it belongs. Establish categories such as Added, Changed, Fixed, Deprecated, Removed, and Security. Add an explicit exclusion label for changes that do not warrant a public entry, such as test-only maintenance.
Do not map every dependency update to “Fixed” or publish every refactor. Ask whether the change affects supported behavior, compatibility, deployment, or an action readers must take. Internal work can still deserve an entry when it changes an operational requirement.
Keep change category and release impact separate. A bug fix can introduce a compatibility break, and a feature does not automatically require a particular version increment. Record breaking impact explicitly and review it against your versioning policy.
Generate the draft from the actual release boundary
Collect merged pull requests between the previous release tag and the intended release commit. Filtering only by merge date can include work that has not shipped or miss changes carried across branches. Check the destination branch and account for backports, cherry-picks, and reverted work.
GitHub-generated release notes can provide a starting inventory. Release Drafter can maintain a categorized draft using pull request metadata and configured labels. Whichever approach you choose, verify its inclusion rules against your branching and release process.
If semantic-release drives publication, remember that its standard analysis operates on commit messages. Pull request titles influence that flow only when your merge strategy or configuration carries them into the analyzed commits. Check the final squash message rather than assuming the title survives unchanged.
Rewrite PR titles into useful release entries
Strip routing prefixes and implementation noise, then preserve the specific outcome. “fix(search): retain filters after refresh” becomes “Dashboard search now preserves selected filters after a page refresh.” Add migration steps, limitations, or configuration requirements when the title alone cannot explain the impact.
Group related pull requests into one entry when they deliver one user-facing change. Keep traceability to the source pull requests in your release tooling, and remove entries for changes that were fully reverted before shipping.
Use model assistance without inventing release facts
A model can normalize phrasing and suggest categories, but give it a bounded input: approved titles, labels, and relevant descriptions. Instruct it to flag missing context instead of inventing benefits, compatibility promises, or migration steps. Treat repository text as data, not instructions.
If you want to automate this editorial pass, SwiftRelay works with OpenAI-compatible SDKs through https://api.fastapirelay.com/v1 and bills per token. Sign up for SwiftRelay to try the workflow with the small gift credit available to new accounts. Send only repository material your organization permits sharing.
Run the changelog checklist before publishing
Have a release owner confirm that every entry shipped, breaking changes include actionable guidance, security wording follows your disclosure policy, and excluded work is intentional. Automation should assemble the evidence; a human should approve the promises your changelog makes.