gh-fix-ci

gh-fix-ci — навык для расследования падающих проверок pull request, которые выполняются в GitHub Actions. Он использует GitHub CLI, чтобы найти неуспешные checks, получить контекст workflow и журналы, выделить полезный фрагмент ошибки, а затем подготовить краткий план исправления. Область работы ограничена GitHub Actions: проверки внешних провайдеров вроде Buildkite не отлаживаются, для них навык предлагает сообщить только ссылку details URL. Перед началом требуется стандартная авторизация gh и проверка gh auth status с правами репозитория и workflow. Если номер или URL PR не передан, навык предпочитает pull request текущей ветки и получает его через gh pr view. Затем он просматривает checks с именем, состоянием, ссылкой, временем и workflow. Для обычного случая предлагается bundled-скрипт inspect_pr_checks.py; у него есть режим --json для машинно читаемого результата. Скрипт учитывает изменения полей gh и умеет переходить к журналу job, поэтому его можно использовать как основной диагностический путь. Ручной fallback сохраняет тот же порядок. Сначала вызывается gh pr checks с доступными полями. Для каждого падающего GitHub Actions check из details URL извлекается run id, после чего gh run view показывает имя, workflow, conclusion, status, URL, событие, ветку и SHA. Полный лог запуска можно получить через gh run view --log. Если запуск ещё выполняется, журнал берётся напрямую для job через gh api. Когда logs отсутствуют или внешний provider не поддерживает GitHub Actions, это нужно явно отметить, а не выдавать предположение за причину. Результат работы — имя падающей проверки, ссылка на запуск и короткий фрагмент лога с контекстом, достаточным для следующего решения. После сводки составляется план. Важное ограничение безопасности процесса: навык диагностирует и планирует, но не должен реализовывать исправление без явного разрешения пользователя. После одобрения можно внести согласованный патч, повторно проверить локальные тесты и предложить ещё один запуск gh pr checks. Поэтому gh-fix-ci подходит для узкого цикла «check → log → причина → план → разрешённое исправление → повторная проверка», но не является автономным деплоем, универсальным CI-клиентом или инструментом для скрытого изменения pull request. Его полезно применять как входную точку для triage, когда название проверки само по себе не объясняет сбой. Сначала фиксируется, какая проверка и какой запуск действительно упали, затем к результату добавляется конкретный логовый фрагмент, а не пересказ без доказательств. Для продолжающегося run важен статус выполнения: незавершённый workflow нельзя трактовать как окончательный failure. Для job-логов нужен доступ к GitHub API, а для стандартного сценария — рабочая авторизация gh; без этого навык должен сообщить о недостающем доступе. Номер PR, ссылка запуска, имя workflow, ветка и SHA сохраняют связь между наблюдением и тем изменением, которое будет проверено повторно.