releaselisted

# Release Reply in Russian. This skill is maintainer-only tooling for this repository — it is deliberately NOT part of `plugin/`, so it never ships to plugin users and never changes codex manifests digests. Run it on `dev`, before opening the `dev → main` PR. CI does the rest: on push to `main` `.github/workflows/publish.yml` publishes to PyPI, then the `release` job cuts tag `vX.Y.Z` and creates a GitHub Release whose body is the `CHANGELOG.md` section for that version. ## 1. Determine the range ```bash git fetch --tags origin git describe --tags --abbrev=0 --match 'v*' # last released version git log --no-merges --pretty='%h %s' v<last>..HEAD git diff --stat v<last>..HEAD ``` If there are no commits since the last tag, say so and stop — there is nothing to release. ## 2. Gather what actually changed Commit subjects alone are NOT enough. For each cluster of related commits, find out what the user gains or stops suffering from: - `gh pr list --state merged --base dev --limit 30 --json number,title,body,mergedAt` — PR bodies usually carry the "why". - Task keys in commit messages (`PRI-NNN`) — read the task via `get_task` if the reviewer MCP server is available. - `docs/superpowers/specs/` and `docs/plans/` — briefs written when the work started. - Read the diff of anything you cannot explain. Never guess at a change's purpose. ## 3. Decide the version Semver against the previous release: breaking change to a CLI flag, MCP tool contract, `.review.yml` schema or