Changelog For Humans Skill

Commit lists are what happened; changelogs are what it means for you — and most teams publish the former with headers. The human version translates each change into its so-what ("Faster search" → "Search results now return in under a second on large workspaces"), orders by reader impact — breaking changes first with migration steps, improvements second, internal plumbing compressed to a line — and never buries the one thing users must do behind twelve things the team is proud of. When audiences diverge (end users vs. developers), the changelog splits rather than serving both badly.

What This Skill Produces

• The impact-grouped changelog — ⚠ breaking/action-needed → ✨ new & improved → 🔧 fixes → (plumbing, one line)
• The so-what translations — each entry: what changed for the reader, not what the team did
• The breaking block — who's affected, what breaks, the migration steps, the deadline if one exists
• The audience split — the user-facing notes and the developer/API notes, separated when their so-whats differ

Required Inputs

Ask for these if not provided:

• The raw changes — commits, PR titles, the team's list; translation needs the source material and the actual user-visible effect of each (ask when a commit's impact is unclear — guessing so-whats manufactures lies)
• The readers — end users? admins? API consumers? Their vocabulary and their stakes decide the grouping and whether the split applies
• The action items — anything readers must do (migrate, re-auth, update configs) — these outrank everything and need deadlines
• The channel — in-app note (three lines), email (skimmable), docs page (complete) — the same release ships different depths