GitHub PR Workflow

• У вас есть локальные изменения, готовые к отправке, и вы хотите создать ветку, зафиксировать коммиты и открыть PR со структурированным описанием в рамках одного процесса.
• Вам нужно отслеживать запуски CI-проверок в открытом PR и хотите, чтобы логи упавших проверок отображались автоматически, без необходимости следить за интерфейсом GitHub.
• Вы хотите организовать цикл автоматического исправления: обнаружить упавшую проверку lint или тестов, применить исправление, выполнить push и повторять опрос до тех пор, пока все проверки не станут зелёными.
• Вы готовы к слиянию и хотите применить определённую стратегию (squash, rebase или merge commit) с последующим удалением исходной ветки.

• Вы не работаете в git-репозитории с GitHub в качестве удалённого сервера — этот навык предполагает такую конфигурацию на протяжении всей работы.
• У вас не выполнена аутентификация gh CLI или отсутствует GitHub PAT; без одного из этих вариантов вызовы API будут завершаться ошибкой.
• Вам необходимо управлять удалёнными серверами GitLab, Bitbucket или другими сервисами, не являющимися GitHub, — этот навык специфичен для GitHub.

Автоматически создаёт ветку для новой функциональности с именем-слагом в соответствии с принятыми соглашениями и фиксирует ваши изменения с автоматически сгенерированным сообщением коммита. Поддерживает чистоту истории коммитов без необходимости писать сообщения вручную.

Отправляет ветку в origin и открывает pull request, используя встроенный шаблон описания (references/pr-template.md). Поддерживает запросы на проверку, назначение меток и привязку задач в одном шаге.

Опрашивает запуски проверок GitHub через scripts/watch_ci.sh и выводит логи всех упавших проверок прямо в вашу сессию. Больше никаких кликов по интерфейсу Actions в поисках ошибки.

Когда проверка завершается с ошибкой, навык может применить исправление, отправить новый коммит и повторно опросить результаты проверок — повторяя цикл до тех пор, пока все обязательные проверки не будут пройдены. Это избавляет от необходимости делать множество последовательных пушей при работе с ошибками линтинга или форматирования.

Поддерживает слияние с объединением коммитов (squash merge), перебазирование (rebase merge) и стандартные коммиты слияния. После слияния исходная ветка удаляется, чтобы поддерживать порядок в удалённом репозитории.

Использует CLI gh в качестве основного инструмента при наличии аутентификации. Если gh недоступен, файл references/api-fallback.md и скрипты на основе curl выполняют все операции с GitHub REST API с использованием $GITHUB_TOKEN.

У разработчика есть локальные изменения, и он просит: «Открой PR с названием "Add rate limiting to /api/search", нацеленный на main». Навык создаёт ветку, фиксирует коммиты, выполняет push и открывает PR с описанием — без единой команды git вручную.

После открытия PR разработчик просит: «Следи за проверками PR и, если линтер завершится с ошибкой, исправь её и снова отправь изменения.» Навык периодически опрашивает статусы проверок, обнаруживает сбой линтера, применяет исправления, отправляет коммит и повторно проверяет результат — до тех пор, пока все проверки не станут успешными.

Когда проверка одобрена, разработчик спрашивает: «Выполни squash-слияние PR #142 и удали ветку.» Навык выполняет squash-слияние и удаляет удалённую ветку в одно действие.

Разработчик спрашивает: «Проверь мою ветку — какие проверки не прошли и кто ещё не одобрил?» Навык получает актуальный статус CI и список ожидающих одобрений от ревьюеров через GitHub API.