github-release

github-release — официальный навык из GitHub awesome-copilot для выпуска новой версии однопакетной GitHub-библиотеки от анализа изменений до release pull request. Он рассчитан на workflow с GitHub CLI и git: сначала читает состояние репозитория и публичного исходного пути, затем определяет SemVer-изменение, предлагает версию, подготавливает changelog, release-ветку и PR. Навык не является универсальным релизным сервером и не подменяет правила конкретного проекта, CI или ручное решение владельца библиотеки. До записи в репозиторий выполняются read-only шаги. Требуются действующая авторизация gh, доступ к просмотру репозитория и чистое рабочее дерево; затем навык спрашивает, где находится публичный код библиотеки, либо сканирует корень. Из анализа исключаются tests, test, spec, __tests__, docs, lock-файлы, lock JSON, sum-файлы, сгенерированные артефакты и файлы с запретом редактирования. Это позволяет отделить изменения, видимые потребителям, от тестов, документации и служебного шума, но не отменяет необходимости проверить полный diff, если проект имеет необычную раскладку. Надёжным источником предыдущей версии навык считает git tags: он получает теги, сортирует их по версии, проверяет наличие выбранного тега на remote и использует commit как базу сравнения. При отсутствии тегов предлагается начать с 1.0.0, а при orphaned tag — вернуться к корневому commit с предупреждением. Основным сигналом для SemVer служит diff публичного кода: удаление или изменение публичного API ведёт к MAJOR, новый экспорт без breaking change — к MINOR, исправление логики, производительности, безопасности, документации или внутренний рефакторинг — к PATCH. Commit log используется как дополнительный контекст; при конфликте приоритет остаётся за кодовым diff. После анализа навык показывает предлагаемую версию и ждёт подтверждения. Только после подтверждения создаётся release-ветка вида release/vX.Y.Z. Changelog оформляется в формате Keep a Changelog: секции Added, Changed, Deprecated, Removed, Fixed и Security добавляются только при наличии пользовательского результата, а diff link обновляется внизу файла. Перед записью changelog также показывается пользователю, чтобы можно было поправить классификацию или формулировки. Такой порядок защищает от релиза, основанного только на названии commit или ошибочном предположении о совместимости. Завершение workflow включает commit и push changelog, открытие PR через gh и handoff владельцу. PR содержит описание версии, включённые изменения и checklist; после merge навык прямо оставляет создание и push git tag пользователю на merge commit, после чего релиз можно оформить в GitHub Releases. Следовательно, подготовленный PR не равен опубликованному релизу, а CI и review остаются обязательными. Навык также требует использовать body-file или эквивалентный многострочный ввод для корректной разметки PR. Практические сценарии — выпуск новой версии библиотеки, проверка SemVer перед PR, подготовка человеческого changelog и безопасная передача последнего шага после merge. Ограничения проверяемы: без gh auth или git-репозитория процесс останавливается, dirty working tree считается blocker, отсутствие тегов меняет базовый сценарий, а отсутствие изменений публичного пути требует отдельного решения. Навык не публикует секреты, не придумывает API-изменения и не гарантирует, что автоматически предложенная версия соответствует политике проекта без проверки владельца.