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

name	description
release	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 формат:

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

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

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

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):

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