opencode-config/.opencode/skills/release/SKILL.md at a8f9aa0bc6f773d319a2622d7663f283417e157d

feat: migrate .opencode/ config from opencode (#23 )

* feat: migrate .opencode/ config from opencode

* refactor: rename repo refs and sanitize for public

* docs(handoff): add pr-7 handoff + ADR-002

* docs(handoff): fix PR number

* docs: update project map with .opencode/ structure

---------

Co-authored-by: opencode-agent <agent@slaid098.dev>

2026-07-23 22:57:39 +03:00

3.5 KiB

Raw Blame History

name	description
release	Выполняет релиз после мерджа 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 формат:

Переименуй ## [Unreleased] в ## [X.Y.Z] - YYYY-MM-DD (сегодняшняя дата)
Добавь новый пустой ## [Unreleased] выше
Заполни секции на основе коммитов:
- feat(...) → ### Added
- fix(...) → ### Fixed
- chore(...), refactor(...) → ### Changed
- docs(...) → можно опустить или ### Changed

Если changelog в другом формате — адаптируй под существующий стиль.

Шаг 4: Коммит changelog

git add CHANGELOG.md
git commit -m "docs: add vX.Y.Z changelog entry"

Шаг 5: Создать tag

Lightweight tag (не annotated):

git tag vX.Y.Z

Шаг 6: Push

git push
git push --tags

Шаг 7: GitHub Release

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

3.5 KiB Raw Blame History Unescape Escape