analyzing-release-readiness

analyzing-release-readiness запускает проверку готовности к релизу перед merge. Навык предназначен для анализа изменений на GitHub pull request, GitLab merge request или локальной ветке и фокусируется на рисках, корректности и возможности отката. Он помогает ответить на практические вопросы: безопасно ли сливать изменения, что может сломаться после публикации, какие предположения не подтверждены и какой rollback-план нужен. Источник разделяет два режима входа. Если есть PR или MR URL, из него извлекаются все необходимые поля: repository, номер PR или MR, hostname и, если доступно, headSha или headBranch. В этом режиме нельзя дополнительно ходить за деталями через gh, glab или другой внешний инструмент: DevOps Agent получает идентификаторы и сам забирает содержимое. Для GitHub используется массив githubPrContent с repository, prNumber как строкой и hostname; для GitLab — массив gitlabMrContent с repository, mergeRequestIid как строкой и hostname. Если ссылки нет и пользователь назвал только репозиторий или пакет, применяется local GitHub/GitLab repo flow. Его нельзя сокращать: сначала проверяется корень рабочего репозитория и существование remote-tracking base branch, по умолчанию main; затем фиксируются git status и число коммитов, которых ещё нет в origin. Любая локальная модификация или непушенные коммиты требуют явного согласия перед публикацией снимка для анализа. После approval рабочие изменения можно сохранить stash с untracked-файлами, создать одноразовую ветку feat/release-readiness-review, применить stash, проверить отсутствие секретных файлов и сделать snapshot commit. Затем ветка пушится в origin, а repository и hostname извлекаются из remote URL; PR создавать не требуется, потому что review agent читает ветку напрямую. После завершения предусмотрено восстановление исходной ветки, удаление удалённой и локальной review-ветки и возврат stash, если он создавался. Перед core workflow требуется выбрать skip_automated_testing. При true выполняется быстрый статический анализ: code review, оценка рисков и проверки зависимостей. При false добавляются automated verification tests; это дольше и запускает testing environment, build и тестовые проверки. Для AWS DevOps Agent навыку также важен AgentSpace: при SigV4 нужно сначала определить agent_space_id через list_agent_spaces, если соответствующая orchestration skill ещё не вызывалась; bearer-token flow этого шага не требует. Основной сценарий создаёт release-readiness job с выбранным content и параметром skipAutomatedTesting, затем ожидает переход IN_PROGRESS. Если job не достигает IN_PROGRESS за пять минут, его отменяют. Для 429 или ThrottlingException разрешены пауза 30 секунд и до трёх повторов; неизвестную ошибку нужно показать пользователю без маскировки. При недоступности aws-devops-agent предусмотрен aws-mcp fallback: сначала перечисляются agent spaces через AWS CLI в us-east-1, пользователь выбирает пространство, затем создаются и опрашиваются backlog task и journal records. В процессе отслеживаются terminal states COMPLETED, FAILED, CANCELED и TIMED_OUT. При COMPLETED извлекается release_analysis_report, сохраняется markdown-артефакт с timestamp и сообщается абсолютный путь. Fallback также требует затем попытаться подготовить fixes для всех actionable risks по отдельному auto-fix flow, но эти исправления не должны смешиваться с исходным review snapshot. При FAILED или TIMED_OUT показывается error information и предлагается следующий шаг; при CANCELED фиксируется отсутствие отчёта. Навык не даёт права незаметно коммитить или пушить локальные изменения: commit, push, stash, создание ветки и auto-fix происходят только в предусмотренном сценарии и после нужного согласия. Технический анализ не является гарантией безрискового релиза; его результат — структурированный набор рисков, доказательств и действий перед merge, а окончательное решение остаётся за владельцем репозитория.