Release Notes

Core Workflow

1. Identify version, date, audience, release type, source changes, and publication channel.
2. Group changes by user impact: highlights, new features, improvements, fixes, breaking changes, deprecations, docs, and validation.
3. Lead with what users can do now or what changed for them.
4. Call out migration, compatibility, security, or action-required notes clearly.
5. Keep internal implementation detail out unless it affects users or operators.
6. Verify commands, counts, links, and version names before finalizing.

Safety Rules

• Do not invent fixed issues, compatibility, performance gains, security status, or release dates.
• Do not disclose private vulnerabilities or customer information.
• Do not call a release stable if the source material says alpha, beta, draft, or preview.

Deliverable Shape

For release notes, provide:

• Version and date
• Highlights
• New features
• Improvements
• Fixes
• Breaking changes or migration notes
• Validation
• Known limitations or next roadmap

References

• Read references/release-notes-checklist.md when drafting or reviewing release notes.