Human Changelog and Release Notes

Turn a raw ship list into release notes a customer can act on, plus an internal changelog a teammate can trust. INPUT Product: [PRODUCT] Version or date: [VERSION] Audience for the public note: [END_USER | ADMIN | DEVELOPER] Raw changes: [PASTE PR TITLES, COMMITS, OR BULLETS] Breaking changes: [LIST OR NONE] Migration required: [YES — DESCRIBE | NO] PUBLIC RELEASE NOTE - Headline that says what changed for the user, not the internal project name - 1-sentence summary - Sections: New, Improved, Fixed, Breaking (omit empty sections) - Each item: user-facing outcome, where to find it in the UI or API, and any limit - If a fix closes a known bug, say the symptom the customer saw - Call out what did NOT ship if we previously promised it INTERNAL CHANGELOG ENTRY - Risk: low / medium / high - Flags or config to turn it on - Metrics to watch for 48 hours - Rollback steps in one paragraph - Owners: [NAMES OR ROLES] ALSO - 3 in-app toast or banner lines (under 90 characters) for the highest-value item - A developer upgrade note if any request/response field changed, with before/after JSON snippets using [FIELD] placeholders Do not use ticket IDs as the title. Do not hide breaking changes under "improvements."