Release notes writer

Release notes tell users what changed in the product, why it matters to them, and what they need to do. Engineering records describe the same changes from the inside: ticket IDs, refactors, branch names, and internal jargon. This skill turns those records into accurate notes a user can scan in under a minute.

Every entry must be traceable to a source. If a change's user impact is unclear from the sources, ask or flag it; do not guess.

Gather the inputs

Confirm the range first: two tags, two versions, a date range, or a milestone. Then collect every change in that range.

• Commits: git log v1.4.0..v1.5.0 --no-merges --pretty=format:'%h %s'
• Merged pull requests: gh pr list --state merged --base main --search "merged:2026-10-01..2026-10-30" --json number,title,body,labels,url --limit 200
• Pull requests in a release: gh release view v1.5.0 or gh api repos/{owner}/{repo}/compare/v1.4.0...v1.5.0
• Tickets: issues or Linear and Jira tickets linked from PR bodies, or filtered by release, milestone, or cycle.
• Diffs: read the diff when a title is vague ("fix bug", "update handler") and the impact is not stated elsewhere.

Read PR descriptions and labels, not only titles. Labels such as breaking, feature, bug, internal, or skip-changelog often decide where an entry goes.

Match the existing changelog