ci

CI Replicate & Status — skill Gemini CLI для мониторинга GitHub Actions, быстрого разбора неуспешных workflow и локальной проверки причины сбоя. Его основной режим replicate автоматически ищет последний активный или недавний запуск для указанной ветки, наблюдает за параллельными workflow и при обнаружении failure запускает рекомендованные локальные команды тестирования или lint. Источник описывает fail-fast поведение: обработка останавливается на первом job, который завершился ошибкой, чтобы сначала дать структурированный отчёт по главной причине, а не смешивать её с последующими каскадными сбоями. Для режима replicate достаточно передать имя ветки: node .gemini/skills/ci/scripts/ci.mjs [branch]. Skill сам выполняет discovery и отдельно предупреждает не искать run ID вручную через gh run list, если не запрошена конкретная историческая запись. При ошибке он извлекает из результата предложенные npm test или npm run lint команды, помеченные символом 🚀, и воспроизводит их локально. Такой порядок связывает удалённый failure с проверкой в рабочем каталоге, но не подменяет анализ ожидаемого результата: локальная команда только подтверждает или уточняет проблему. Режим status предназначен для ситуации после push. Его можно запустить с веткой и, при необходимости, конкретным run_id: node .gemini/skills/ci/scripts/ci.mjs [branch] [run_id]. По описанию skill он также периодически опрашивает состояние и после failure переходит к извлечению команд для локального воспроизведения. Категории ошибок разделены на test failures, lint errors, build errors и job errors. Для тестов предлагается выполнить точную команду из отчёта, для lint — npm run lint:all или пакетную команду, для build — проверить tsc или вывод сборки, а для инфраструктурной job-ошибки — посмотреть gh run view --job <job_id> --log. Важное свойство workflow — фильтрация шума: скрипт старается убрать из итогового отчёта Git-логи, лишний npm-шум и объёмные stack trace, оставляя Structured Failure Report. При этом автоматическая репликация действительно может запускать команды локально, поэтому ветка и рабочий каталог должны быть выбраны осознанно, а предложенные проверки нужно читать как команды для диагностики конкретного CI-сбоя. Skill ускоряет путь от GitHub Actions к локальному воспроизведению, но не гарантирует исправление кода, не выбирает бизнес-ожидаемый результат и не превращает успешный локальный тест в доказательство того, что удалённый workflow уже исправлен.