writing-changelogslisted

# Writing Changelogs Write changelog entries and release notes that humans actually want to read. This skill activates when writing changelog entries, preparing GitHub releases, or reviewing release notes quality. **Sources**: [Keep a Changelog](https://keepachangelog.com/en/1.0.0/), [Common Changelog](https://github.com/vweevers/common-changelog) ## When to Use - Writing a changelog fragment for a change - Preparing GitHub release notes via `/system:release` - Reviewing changelog entries before release - Transforming commit messages into user-friendly descriptions ## Where entries live: fragments Unreleased entries do **not** go in `CHANGELOG.md`. Each change adds one **fragment** file under `changelog/unreleased/` — a coordination-free scheme that keeps parallel worktrees from colliding on a shared `[Unreleased]` block (ADR `260707-231641`; full guide in `changelog/README.md`). The workflow: - **Filename** — `<YYMMDD-HHMMSS>-<kebab-slug>.md`: a timestamp id from `.claude/scripts/id.ts` followed by a short slug. The post-commit hook names it from your commit subject. - **Body** — optional `covers:` frontmatter (which commits this fragment covers; the post-commit hook fills it in, and the PR check reads it so your prose stays free to be rewritten for a human), then one or more `### Category` headings (Added, Changed, Deprecated, Removed, Fixed, Security) with bullets written per the principles below. One fragment may carry multiple categories. - **Creation**