---
name: release
description: Performs a release after PR merge — updates CHANGELOG, creates git tag and GitHub Release. Use when the user says "сделай релиз", "выпусти версию", "опубликуй", "release", "затегай".
---

## Релиз

Выполняй релиз строго по шагам. НЕ пропускай шаги.

### Шаг 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 status  # проверь staged set — только CHANGELOG.md, без лишнего
```

> `commit` tool НЕ делает `git add` — коммитит только уже staged файлы. Если
> в индексе лишнее (например `memory-save` stage'нул всё через `git add -A`)
> — не коммить: сначала `git restore --staged <file>` или не stage'и его
> изначально. Используй `git add <конкретные-пути>`, НЕ `git add -A`.

Затем через `commit` tool (НЕ raw `git commit` — заблокирован deny):

```
commit({ message: "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`