pushing-ci-changes

Навык pushing-ci-changes посвящён узкой, но важной ситуации в репозитории Codex: отправка изменений, затрагивающих конфигурацию GitHub Actions. В исходном SKILL.md прямо указано, что репозиторий не разрешает загружать изменения в CI-конфигурацию без временно выданной роли. Поэтому отказ push в таком случае рассматривается не как обычная ошибка Git, которую можно исправить повторным вводом команды, а как сигнал отдельного workflow approval. Область правила обозначена явно: речь идёт о файлах .github/**/*.yml и связанных с ними изменениях. Это помогает не переносить инструкцию на любой push подряд и сначала определить, действительно ли набор изменений попадает под защищённую область. Практический сценарий начинается с проверки того, что push действительно отклонён из-за ограничения CI. Если ожидается изменение workflow, навык рекомендует всё равно выполнить push: такая попытка показывает, есть ли у текущей учётной записи уже действующее разрешение. Если сервер принимает push, дополнительный запрос не нужен. Если сервер отказывает, следующий шаг находится вне автоматического обхода: пользователю нужно открыть go/workflow-approvals и запросить временное исключение через предусмотренный процесс. Сам навык не пытается просить exemption от имени пользователя и не обещает, что разрешение появится мгновенно. После отказа полезный результат работы — понятное объяснение причины, ссылка на go/workflow-approvals и ожидание, пока решение распространится в GitHub. Возвращаться к push имеет смысл после подтверждения, что approval применился. Такой порядок разделяет три состояния: обычный push без защищённых файлов, push при уже имеющемся разрешении и push, остановленный политикой workflow. Он также не подменяет проверку содержимого коммита: перед повторной попыткой всё равно нужно убедиться, что изменены именно нужные файлы и что в push не попали посторонние изменения. Навык не является способом отключить GitHub Actions, изменить права репозитория или самостоятельно выдать роль. Он не предлагает обходить защиту, подделывать ответ сервера или переносить CI-файлы в другой путь ради прохождения проверки. Его назначение уже: распознать отказ загрузки CI-изменений, проверить наличие текущего разрешения, направить владельца операции в официальный approval flow и дождаться его завершения. Это делает карточку полезной при подготовке изменения workflow и при разборе отклонённого push, но не заменяет правила доступа организации, ревью YAML или обычную диагностику синтаксиса и поведения pipeline.