changeloglisted

# Changelog References: <https://keepachangelog.com/en/1.1.0/>, <https://semver.org/>, <https://pvp.haskell.org/>. This skill maintains a hand-curated KAC. It detects auto-managed setups and steps aside; it never proposes adopting tooling. Cutting a release (tagging, version-file edits) is out of scope — bootstrap and review-against-commits only. ## Defer to auto-tooling If any are present the changelog is auto-managed — surface the detection and stop unless the user overrides: - `.changeset/` — changesets - `.release-please-manifest.json` / `release-please-config.json` — release-please - `cliff.toml` / `.cliff.toml` — git-cliff - `package.json` `"release"` / `"semantic-release"`, or `.releaserc*` / `release.config.*` — semantic-release - `pyproject.toml` `[tool.towncrier]`, or `newsfragments/` — towncrier Treat any clearly auto-managed CHANGELOG the same way. ## What to include Entries describe changes visible to consumers of the deliverable — users of the library / CLI / service, not contributors to the repo. Include: public API changes (additions, removals, renames, signatures), observable behavior changes (output, errors, defaults), user-facing bug fixes, perceptible performance changes, security fixes, breaking deprecations, and supported-platform / runtime / dependency changes users must adapt to. Skip: typos, comment-only changes, internal refactors, test changes, build/CI tweaks, dependency bumps users don't perceive, doc fixes (unless docs are the deliverab