changelog-releaselisted

# Cut a version + generate CHANGELOG.md This is the **release** counterpart to `commit-push-sync`. Where that skill keeps everyday commit *messages* clean, this skill is the explicit moment you turn that clean history into a **version bump** and a **CHANGELOG.md** entry. Only run it when the user clearly asks to release / bump / update the changelog. Never trigger it from a routine commit or push. ## 1. Establish the range and read the history - Last release tag: `git describe --tags --abbrev=0` (no tag → the full history). - Commits since then: `git log <lastTag>..HEAD --oneline`. - Parse them as Conventional Commits (`type(scope): subject`, `type!:`, `BREAKING CHANGE:` footers). Commits that don't follow the convention won't produce clean entries — surface them to the user rather than silently dropping anything significant. If there are no releasable commits since the last tag, say so and stop — don't cut an empty release. ## 2. Determine the version bump Read `${CLAUDE_PLUGIN_ROOT}/references/versioning.md` and apply it. That file is the single source of truth for the tag format, the bump table, the mandatory `0.x` drop-a-level rule, and where to read the current version from. Do not restate or re-derive those rules here — `commit-push-sync` reads the same file, and the two must never disagree about what version a given range implies. Propose the computed next version and let the user confirm or override (they may want to force a major, or a pre-release like