Release manager

Skill goldenprofile/llm-skills/release-manager

LLM Skills

Install

npx -y skills add goldenprofile/llm-skills --skill release-manager

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

1 stars1 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

What its author says it does

Copied from the file, not written here

Дисциплина релизов соло-проекта: определение версии по semver из диффа (major/minor/patch), генерация CHANGELOG из Conventional Commits, git-теги и GitHub Releases, пре-релизный чеклист (миграции, зависимости, конфиги) и smoke-проверка после деплоя git pull. Используй когда пользователь говорит «сделай релиз», «выпусти версию», «подними версию», «обнови changelog», «затегируй релиз», спрашивает «какая версия должна быть», или готовит версионированный деплой. План атомарных коммитов — git-commit-planner; сам деплой на сервер — vps-deploy-auditor.

SKILL.md

7.4 KB, ~1.9k tokens by cl100k_base, as published. Nobody here has run it

Release Manager

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

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

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

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

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

Процесс

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

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. Коммит, тег, публикация

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-deploy-auditor.

Первый релиз

Нет тегов → предложи 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-deploy-auditor — выкатка релиза на сервер.
dependency-auditor — обновление зависимостей отдельным релизом/коммитом, не вперемешку с фичами.