Changelog Writer Skill

Raw commit logs are written for the author; a changelog is written for the user. This skill turns a pile of commits/PRs/changes into a clean release entry — grouped by type, in plain user-facing language, with breaking changes and upgrade steps surfaced first so nobody gets surprised.

Required Inputs

Ask for these only if they aren't already provided:

• The changes — commit messages, PR titles, or a bullet list of what changed.
• Version & date — the release number (or help pick per semver) and date.
• Audience — end users, API consumers, library developers (sets the voice).
• Conventions (optional) — Keep a Changelog, an existing style, links to issues/PRs.

Output Format

Follow Keep a Changelog conventions:

[version] — [date]

⚠️ Breaking changes (only if any) — each breaking change + the exact migration step to fix it. This goes first.

Added — new features/capabilities, in user terms. Changed — changes to existing behavior. Deprecated — soon-to-be-removed features (and what to use instead). Fixed — bug fixes (what was broken, from the user's view). Security — any security-relevant fixes.

(Omit empty sections.) Each line: user-facing outcome first, with an issue/PR reference if available — not the raw commit message.

Upgrade notes (if needed) — anything to do when upgrading beyond the breaking-changes steps.

Semver note — if the version was inferred, one line on why (breaking → major, feature → minor, fix → patch).