jeremylongworth-source Release Notes
Core Workflow
- Identify version, date, audience, release type, source changes, and publication channel.
- Group changes by user impact: highlights, new features, improvements, fixes, breaking changes, deprecations, docs, and validation.
- Lead with what users can do now or what changed for them.
- Call out migration, compatibility, security, or action-required notes clearly.
- Keep internal implementation detail out unless it affects users or operators.
- 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.mdwhen drafting or reviewing release notes.