release-noteslisted

# Release Notes Draft a release changelog by summarizing the commits since the last release, then suggest the next semver version and prepend the entry to `CHANGELOG.md` at the project root. ## Steps 1. **Find the commit range and version baseline.** Determine the last released tag: ```bash git describe --tags --abbrev=0 2>/dev/null ``` - If a tag exists, the range is `<tag>..HEAD`, and the tag itself is the version baseline. - If no tag exists (fresh repo), use the full history and **ask the developer** for the current version — do not infer it from any manifest, lockfile, or config file belonging to the project. This skill only reads git; it never inspects a project's toolchain. 2. **Collect the commits** in the range: ```bash # with a tag: git log <tag>..HEAD --oneline --no-merges # without a tag: git log --oneline --no-merges ``` 3. **Group the commits** by type, inferring the type from the message (Conventional Commits prefix if present, otherwise from the wording): - **Features** — new functionality (`feat`, "Add", "Support") - **Fixes** — bug fixes (`fix`, "Fix", "Correct") - **Chores / Maintenance** — `chore`, `refactor`, `docs`, deps, tooling - Drop noise (pure formatting/typo commits) or fold them into a related entry. 4. **Suggest the next version** from the baseline established in Step 1 (the tag, or the version the developer gave you), using semver: - Breaking changes → **major** - Any ne