git-releaselisted

# GitHub Version Release Use this skill to publish the current local changes from `dev` as a new semantic version on GitHub and promote them to `prod`. ## Principles - Work conservatively and inspect state before every operation that changes branch, history, remote state, tags, or releases. - Never use `git push --force`, `git push --force-with-lease`, history rewrites, destructive cleanup, or broad file deletion unless the user explicitly asks for it and the risk is explained first. - Stop and report a concrete recommendation when a required branch, remote, permission, version decision, test command, merge, tag, or release step is unclear or fails. - Preserve user changes. Do not revert unrelated work unless the user explicitly requests it. - Prefer existing repository conventions over generic assumptions, especially for changelog format, release notes, version files, test commands, and branch names. ## Required Starting State Before making changes, verify all of the following: 1. Run `git status --short --branch`. 2. Confirm the current branch is exactly `dev`. If not, stop and tell the user the current branch and that the release workflow must start from `dev`. 3. Confirm the working tree contains the local changes that should be released. If there are no changes and no new commits on `dev` relative to `prod`, stop and ask whether an empty release is intended. 4. Run `git remote -v` and confirm a GitHub remote exists, normally `origin`. 5. Run `git branch --list dev