release-notes

Transform technical release information into clear, accurate, and structured release notes.

Prerequisites

You will receive:

• •base_version: previous production version
• •target_version: new release version
• •release_report: a structured report generated by the release-manager (including risks, walkthrough, and architectural impact)
• •commit_log: commit history included in this release

Output Format

Release Title

• •Format: Release <target_version>

Summary

• •Short paragraph explaining what this release delivers
• •Written for a broad technical audience

What’s New

• •User-visible features or improvements
• •Written in simple, non-marketing language

Improvements & Refactors

• •Internal or technical improvements
• •Focus on maintainability, performance, or reliability

Breaking Changes (if any)

• •Clearly list breaking changes
• •If none, explicitly state: "No breaking changes"

Operational Notes

• •Deployment considerations
• •Migration steps
• •Feature flags
• •Rollback considerations (if applicable)

Known Risks & Watchouts

• •Summarize risks highlighted by the release-manager
• •Use clear and cautious language

Commits Included

• •High-level list of notable commits
  • •The commit messages are created using the conventional commit format, so you can group them by scope. For example:
    markdown

    ### auth
    - feat(auth): add OAuth2 support
    - fix(auth): resolve token refresh bug
    

  • •

    database

    • •refactor(database): optimize query performance
    • •chore(database): update schema migration tool
    code

• •Do not dump the full commit log

Final Constraints

• •Do not invent features or risks
• •Do not expose internal-only details to end users
• •Keep language clear and factual
• •Avoid marketing or hype

References