--- name: release description: Выполняет релиз после мерджа PR — обновляет CHANGELOG, создаёт git tag и GitHub Release. Используй когда пользователь говорит "сделай релиз", "выпусти версию", "опубликуй", "release", "затегай". Also when user says "сделай релиз", "выпусти версию". --- ## Релиз Выполняй релиз строго по шагам. НЕ пропускай шаги. ### Шаг 1: Проверки перед релизом - Убедись, что мы на основной ветке (`main` или `master` — проверь какая основная) - `git status` — working tree должен быть чистым - Если нет → **СТОП**, сообщи пользователю ### Шаг 2: Определить версию - Получи последний тег: `git tag --sort=-version:refname | head -1` (например `v2.7.6`) - Покажи коммиты с последнего тега: `git log vLAST..HEAD --oneline` - Предложи версию на основе коммитов: - `feat(...)` → minor bump (например `v2.7.6` → `v2.8.0`) - `fix(...)`, `docs(...)`, `chore(...)` → patch bump (`v2.7.6` → `v2.7.7`) - Если коммитов с последнего тега нет → **СТОП**, нечего релизить - Спроси подтверждение версии у пользователя (через question tool или текстом) ### Шаг 3: Обновить CHANGELOG.md Проверь формат changelog. Если файл существует и использует [Keep a Changelog](https://keepachangelog.com/) формат: 1. Переименуй `## [Unreleased]` в `## [X.Y.Z] - YYYY-MM-DD` (сегодняшняя дата) 2. Добавь новый пустой `## [Unreleased]` выше 3. Заполни секции на основе коммитов: - `feat(...)` → `### Added` - `fix(...)` → `### Fixed` - `chore(...)`, `refactor(...)` → `### Changed` - `docs(...)` → можно опустить или `### Changed` Если changelog в другом формате — адаптируй под существующий стиль. ### Шаг 4: Коммит changelog ```bash git add CHANGELOG.md git commit -m "docs: add vX.Y.Z changelog entry" ``` ### Шаг 5: Создать tag Lightweight tag (не annotated): ```bash git tag vX.Y.Z ``` ### Шаг 6: Push ```bash git push git push --tags ``` ### Шаг 7: GitHub Release ```bash gh release create vX.Y.Z --title "vX.Y.Z" --notes "<содержание секции из changelog>" ``` ### Шаг 8: Отчёт Сообщи пользователю: - Версию релиза - Ссылку на GitHub Release - Количество коммитов в релизе ## Safety rules - НИКОГДА не делай релиз, если working tree не чистый - НИКОГДА не делай релиз, если нет новых коммитов с последнего тега - НИКОГДА не создавай тег с существующим именем - ВСЕГДА спрашивай подтверждение версии у пользователя перед коммитом - НЕ обновляй `pyproject.toml` version (в некоторых репо версионирование через tags) - НЕ делай `git push --force`