# Release Manager

> Выпуск версии проекта: определить semver из диффа, собрать CHANGELOG из Conventional Commits, проставить git-тег и GitHub Release, пройти пре-релизный чеклист (миграции, зависимости, конфиги) и smoke-проверку после `git pull` на сервере. Используй когда пользователь говорит «сделай релиз», «подними версию», «обнови changelog», «затегируй», «проверь мои коммиты за неделю и поправь деплой гайд», спрашивает «какая версия должна быть». Разложить изменения на коммиты — git-commit-planner; сама выкатка и конфиги сервера — vps-ops.

- Skill: `goldenprofile/release-manager` (Agent Skill)
- Install (CLI): `npx skillmds@latest add goldenprofile/release-manager`
- Raw SKILL.md: https://api.skillmd.com/api/skills/goldenprofile/release-manager/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: goldenprofile (https://skillmd.com/u/goldenprofile)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/goldenprofile/release-manager

---


# Release Manager

Превращает «накопились коммиты» в оформленный релиз: версия по semver,
CHANGELOG, аннотированный тег, GitHub Release, чеклист перед выкаткой.
Деплой-модель владельца: git pull на VPS + рестарт systemd-сервиса.

## Когда применять

- Накопились изменения, пора выпускать: нужна версия, changelog, тег.
- Спор с самим собой «это minor или patch».
- Настроить релизный процесс в проекте с нуля (первый тег, CHANGELOG.md).

## Контекст — установить ПЕРВЫМ делом

1. **Источник версии** — где она живёт: `pyproject.toml` (`project.version`),
   `__version__`, `plugin.json`, нигде (тогда только теги). Если версия
   продублирована в нескольких файлах — все места обновляются одним коммитом;
   предложи единый источник.
2. **История** — `git describe --tags --abbrev=0` (последний тег);
   его нет → это первый релиз (см. «Первый релиз»).
3. **Конвенция коммитов** — Conventional Commits или вольная. Вольная →
   классифицируй изменения по диффу и смыслу, не по префиксам.
4. **Remote** — GitHub есть? `gh` доступен? Иначе — только локальный тег.

## Процесс

### 1. Собрать изменения с последнего релиза

```bash
git log <last-tag>..HEAD --oneline
git diff <last-tag>..HEAD --stat
```

### 2. Решить версию (semver)

| В диффе есть… | Бамп |
|---|---|
| Ломающее изменение: API/CLI/формат данных/схема БД несовместимы, `BREAKING CHANGE:` в коммитах | **major** |
| Новая функциональность (`feat:`), новые эндпоинты/команды/навыки | **minor** |
| Только фиксы, доки, рефакторинг без смены поведения (`fix:`, `docs:`, `chore:`) | **patch** |

- Версия `0.x.y`: ломающие изменения допустимы в minor (`0.x` → `0.(x+1)`) —
  но скажи пользователю, если проект «дорос» до 1.0.0.
- Сомнение major/minor → покажи конкретные ломающие места и спроси: решение
  о breaking change принимает владелец.

### 3. CHANGELOG.md (формат Keep a Changelog)

- Секция `## [X.Y.Z] — YYYY-MM-DD` со списками `Added / Changed / Fixed /
  Removed / Security` (только непустые).
- Пиши **для пользователя проекта, не пересказ коммитов**: «Добавлен экспорт в
  CSV», а не «feat(export): add csv writer».
- Мелкие внутренние правки агрегируй одной строкой; ломающие изменения — с
  инструкцией миграции.
- Файла нет → создай с текущим релизом (историю задним числом не выдумывай).

### 4. Пре-релизный чеклист (гейт — не пожелание)

- [ ] CI зелёный на релизном коммите (тесты/линт/типы).
- [ ] Непримененных миграций нет или они идут в этот релиз — прогнаны через
      `migration-safety-auditor`, порядок «код совместим со старой схемой» соблюдён.
- [ ] Зависимости запинены (lockfile обновлён и закоммичен).
- [ ] Новые переменные окружения отражены в `.env.example` и заметках релиза.
- [ ] Версия обновлена во всех местах-источниках.

### 5. Коммит, тег, публикация

```bash
git commit -m "chore(release): v1.4.0"
git tag -a v1.4.0 -m "v1.4.0 — краткая суть релиза"
git push && git push origin v1.4.0
gh release create v1.4.0 --title "v1.4.0" --notes-file <(секция из CHANGELOG)
```

Тег — всегда аннотированный (`-a`); префикс `v` — по существующей конвенции
проекта (посмотри прошлые теги, не меняй стиль).

### 6. После деплоя — smoke

На сервере после `git pull` + рестарта: сервис active (`systemctl status`),
`/healthz` отвечает 200 (или бот отвечает на команду), в `journalctl -u app
-n 50` нет трейсбеков, версия в приложении = тегу (если экспонируется).
Полный runbook живого деплоя — `vps-ops`.

## Первый релиз

Нет тегов → предложи `0.1.0` (или `1.0.0`, если API стабилен и им пользуются),
создай CHANGELOG.md с одной секцией, теги начинай сразу аннотированные.

## Быстрый чеклист

- [ ] Версия обоснована содержимым диффа (могу назвать, что дало bump).
- [ ] CHANGELOG написан для читателя, ломающие изменения — с миграцией.
- [ ] Пре-релизный гейт пройден (CI, миграции, lockfile, env).
- [ ] Аннотированный тег запушен, GitHub Release создан.
- [ ] Smoke после деплоя зафиксирован.

## Связь с библиотекой навыков

- `git-commit-planner` — навести порядок в коммитах ДО релиза (атомарность
  упрощает и semver-решение, и changelog).
- `migration-safety-auditor` — гейт на миграции, уходящие в релиз.
- `vps-ops` — выкатка релиза на сервер.
- `dependency-auditor` — обновление зависимостей отдельным релизом/коммитом,
  не вперемешку с фичами.