tag-releaselisted

# Tag Release ## Core Question Is the repository in a verified release-ready state for the requested Git tag action, and what confirmation is required before local or remote tag mutation? ## When To Use Use this skill when the user asks to: - inspect release tag readiness, - choose or validate a tag name, - create a local annotated or signed Git tag, - verify an existing tag, - push a Git tag after explicit confirmation. ## When Not To Use Do not use this skill for version-file edits, changelog edits, release-note drafting, package publication, hosted release publication, or tag recovery. Route to: - `version-bump` for version decisions or local version file edits. - `changelog-maintenance` for changelog file changes. - `release-notes` for release-note text. - `undo-recover` for deleting, replacing, retagging, or recovering tags. - a future `publish-release` skill or manual workflow for package or hosted release publication. ## Required Evidence Before tag mutation, inspect or establish: - `git status --short --branch`, - current branch and target commit SHA, - version files and expected tag name, - changelog or release notes when relevant, - existing local and remote tags, - latest tag and release range, - project tag policy for annotated, lightweight, or signed tags, - CI/build/test status when available, - remote configuration when push is requested. ## Operating Contract You MAY: - inspect release readiness and tag state, - propose a tag name from evidenced