unblock-pr

unblock-pr предназначен для расследования падающего CI у pull request. Его задача — разобрать каждый сбой конвейера, отнести его к flaky-тесту, инфраструктуре или регрессии, предложить точное действие и отдельно показать состояние покрытия и качественных или security-проверок. Навык не обещает исправить код сам по себе: он формирует проверяемый triage brief, в котором для каждой job указаны классификация, одно ключевое доказательство, уверенность и рекомендуемый следующий шаг. Для работы нужны ветка PR и репозиторий; идентификатор репозитория нормализуется в нижний регистр и передаётся без схемы, а default branch определяется из git с запасным значением main. В начале invocation навык выбирает backend в строгом порядке. Явный параметр --backend pup имеет приоритет. Иначе проверяется доступность Datadog MCP-инструмента поиска событий CI, затем наличие исполняемого pup CLI. Если недоступны и MCP, и pup, workflow останавливается с понятным сообщением о необходимости подключить сервер или установить CLI. Для pup предусмотрены дополнительные правила: JSON читается напрямую, repository ID передаётся в нижнем регистре, а ошибки 401/403 означают необходимость обновить или выполнить вход. Это важное ограничение: без доступного источника событий нельзя достоверно приписать причину падению. Сначала собирается сводка pipeline events за последние 24 часа для ветки и репозитория. Если среди результатов есть jobs тестового runner, дополнительно ищутся test events; если есть только build, lint или deploy jobs, лишний тестовый поиск пропускается. Параллельно запрашивается покрытие ветки. В MCP-режиме при найденном открытом PR можно получить quality и security из PR insights; в pup-режиме или при отсутствии номера PR эти поля должны быть обозначены как недоступные. Для каждого job, которому ещё нужна классификация, workflow сравнивает ошибки default branch и проверяет blast radius по другим веткам. Если в событиях уже присутствуют домен и тип error classification, они имеют приоритет над косвенными признаками. Правило классификации явно фиксировано. Если job уже падает на default branch, это infra; если она не падает на default branch и не встречается минимум на трёх других ветках, это regression; если на default branch её нет, но она широко появляется на других ветках, это flaky. При недостатке данных используется unknown. Активный flaky-тест из отдельного flaky-tests источника также получает классификацию flaky. В brief нужно сохранить evidence, а не делать вывод только по названию job. В итоге отчёт содержит ветку, репозиторий, строки по всем сбоям и сводку количества flaky, infra, regression или unknown, затем обязательные строки Coverage, Quality и Security. Рекомендации зависят от класса. Для regression предлагается исследовать изменения текущего PR. Для flaky подключается отдельный workflow глубокой проверки flaky-теста для каждого отличающегося имени. Для infra сначала оценивается, похожа ли ошибка на временную: timeout, недоступный runner, сетевой сбой или quota могут оправдать retry, тогда как ошибка конфигурации, отсутствие секрета или детерминированное assertion failure обычно требуют исправления причины. MCP-вариант повторяет конкретную GitHub Actions job и затем проверяет появление нового запуска; pup-вариант использует gh run rerun --failed. Для GitLab и других провайдеров даётся ссылка на pipeline, а unknown направляет к сырым логам. Навык не должен объявлять причину доказанной, если backend не вернул события, default-branch check или данные о распространённости; в такой ситуации правильный результат — unknown и запрос на просмотр исходных логов.