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

docs(memory): reindex + update SKILL.md (#104 )

* feat(memory): add OPENAI_EMBEDDING_BATCH_DELAY support

* docs(memory): update SKILL.md for progressive enhancement and auto-setup

* docs(memory): update AGENTS.md tool usage policy

* docs(memory): fix stale snake_case tool references in skills, agents, tools

* docs(handoff): add handoff + ADR for reindex-skill-update

* docs(handoff): set PR number

* refactor(memory): extract _embed_in_batches to satisfy xenon rank A

---------

Co-authored-by: opencode-agent <agent@opencode.local>

2026-07-27 02:08:35 +03:00

4.1 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 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

4.1 KiB Raw Blame History Unescape Escape