# Release note automation with coding agents > Release note automation needs verified scope, audience-aware language, and links to evidence. Learn how coding agents can draft notes without inventing impact. URL: https://factory.com/articles/release-note-automation-coding-agents Published: 2026-09-24 Updated: 2026-09-24 Release note automation converts merged changes into an explanation of what a user or operator needs to know. Coding agents can search pull requests, issues, commits, and documentation faster than a manual pass, but those records often describe implementation rather than impact. A reliable draft keeps every statement traceable to shipped evidence. GitHub can [automatically generate release notes](https://docs.github.com/en/repositories/releasing-projects-on-github/automatically-generated-release-notes) from merged pull requests and contributors, with categories controlled by labels and a repository configuration file. That creates a dependable change set. It does not decide which details matter to each audience or verify that a feature reached the release artifact. ## Establish the release note automation scope Start with immutable boundaries. Name the previous and current tags, release branch, build identifier, included repositories, and cutoff time. Generate the commit and pull request range from those boundaries rather than from a date query. Date windows can miss backports or include changes that never entered the release. Define audiences and categories before drafting. End users need changed behavior and migration steps. Operators need configuration, rollout, and rollback details. API consumers need compatibility and deprecation information. Security notes may require a coordinated disclosure process and should not be inferred from private issue titles. Ask the coding agent to cite the source pull request, issue, or documentation for each entry. Factory’s [remote delegation guidance](https://docs.factory.com/remote-delegations) recommends a desired outcome, acceptance criteria, verification commands, and relevant links. For release notes, require the exact tag range and forbid claims that lack a merged source. ## Turn implementation records into verified impact Read the merged diff and its tests, not only the pull request title. A title such as “refactor token refresh” may hide a user-visible fix, or it may have no external effect. Check configuration defaults, command output, API schemas, migration files, feature flags, and documentation changes. Write the narrowest supported statement. “The CLI now retries one failed upload” is stronger than “uploads are more reliable” when the code proves only one retry path. Preserve product names and command spelling from current documentation. Do not invent performance gains, adoption numbers, quotes, or availability. Group related implementation pull requests into one entry when they ship one outcome. Keep breaking changes, deprecations, security fixes, and required operator actions easy to find. Link the canonical documentation once, near the first useful mention. ## Review the notes against the artifact Compare the draft with the final tag or release candidate. Verify referenced commands, settings, endpoints, and migration steps in that revision. Check that reverted changes and disabled features are absent. Ask a subject owner to review entries with operational, security, legal, or compatibility implications. Factory [Custom Automations](https://docs.factory.com/software-factory/automations) can start from GitHub events or a schedule and run with a stable service-account identity. The automation can assemble the release range, draft categorized notes, and report missing evidence. Keep publication behind the team’s normal approval because drafting and publishing have different consequences. The review packet should include the release boundaries, source list, uncategorized changes, unresolved claims, and draft notes. Stop when tags disagree across repositories or the release artifact cannot be tied to a commit. A short blocked report is more useful than notes for software that did not ship. ## Frequently asked questions ### What does release note automation need beyond a change list? GitHub can generate notes from merged pull requests, but that does not decide which details matter to each audience or verify that a feature reached the release artifact. Each statement should trace to shipped evidence. ### How should the release scope be set? From immutable boundaries, such as the previous and current tags, release branch, build identifier, included repositories, and cutoff time, rather than a date query. ### How specific should a release note be? Write the narrowest supported statement. A note that the CLI now retries one failed upload is stronger than a claim that uploads are more reliable when the code proves only one retry path. ### Should a release notes automation publish on its own? No. Factory Custom Automations can assemble the release range and draft categorized notes, but publication stays behind the team's normal approval. ## Further reading - [Software factory architecture and pattern, stage by stage](https://factory.com/articles/what-is-a-software-factory-architecture) - [SBOM automation for coding agent changes](https://factory.com/articles/sbom-automation-coding-agents) - [Custom Automations](https://docs.factory.com/software-factory/automations) - [Automatically generated release notes](https://docs.github.com/en/repositories/releasing-projects-on-github/automatically-generated-release-notes)