github-issue-creator

Этот скилл задаёт последовательность подготовки качественного GitHub issue с учётом правил конкретного репозитория. Он применяется, когда нужно создать issue, и сначала требует определить тип запроса: bug report, feature request или другую категорию. Затем нужно найти шаблон в .github/ISSUE_TEMPLATE/. В официальной инструкции явно перечислены YAML-шаблоны bug_report.yml, feature_request.yml и website_issue.yml; если подходящего YAML нет, предлагается проверить Markdown-шаблоны в той же директории. Такой порядок связывает текст issue с реальными полями репозитория и не позволяет подменить форму универсальным описанием, которое может не пройти локальные требования. После выбора файла скилл требует прочитать шаблон и извлечь обязательные поля. Для YAML issue form нужно подготовить значения каждого id, а для Markdown-шаблона — соблюдать его структуру. В исходнике отдельно закреплено правило для labels: по умолчанию следует добавлять label "🔒 maintainer only", если пользователь явно не попросил другое. Это не означает, что label существует в каждом репозитории автоматически: команда должна проверить контекст целевого репозитория и права текущего GitHub-пользователя. Содержание issue должно быть ясным, с коротким описательным заголовком и полями, которые отвечают выбранному шаблону. Создание выполняется через GitHub CLI gh. Для Markdown-шаблона или простого body инструкция рекомендует сначала сохранить подготовленный многострочный текст во временный файл, затем вызвать gh issue create с --title, --body-file и нужным --label. Такой способ сохраняет переводы строк, Markdown и специальные символы и уменьшает риск ошибок shell-экранирования. Для YAML forms исходник отмечает, что gh issue create поддерживает --body-file, но для полей формы могут потребоваться --field-флаги; если форма уже преобразована в обычное тело, допустим --body или --body-file. В отдельной заметке для gemini-cli сказано, что иногда можно передать форму одним body, однако надежность зависит от конкретного репозитория. Практический сценарий состоит из пяти этапов: классифицировать запрос, найти и прочитать шаблон, подготовить поля, создать issue через gh и проверить результат. После команды нужно подтвердить успешное создание и получить ссылку на issue. Скилл не является анализатором кода и не определяет сам по себе, является ли сообщение дефектом: это решение принимается по запросу пользователя и структуре шаблона. Он также не обещает обход авторизации, отсутствие обязательных полей или автоматическое назначение исполнителя. Для работы нужен установленный и аутентифицированный gh с доступом к целевому репозиторию; если CLI не может обратиться к GitHub, issue не считается созданным. Карточка особенно полезна в проектах, где разные типы обращений имеют разные поля и labels: bug report может требовать воспроизведение и окружение, feature request — обоснование и ожидаемое поведение, а website issue — данные о странице. Проверка результата нужна даже после выхода gh с нулевым кодом: следует убедиться, что ссылка ведёт в ожидаемый репозиторий, заголовок и body сохранились, а label применился. Временный файл содержит пользовательский текст и должен жить только на время команды; его не следует добавлять в репозиторий. Официальный SKILL.md описывает процесс подготовки и проверки GitHub issue, поэтому ограничения репозитория, политика maintainer-only и доступность выбранного шаблона остаются источником истины для конкретного запуска.