gcloud

Официальный skill Google задаёт безопасный workflow для любых задач вокруг gcloud CLI: подготовки команды, объяснения синтаксиса, генерации примера, планирования и фактического выполнения. Его центральное правило — не доверять памяти о командах, флагах и позиционных аргументах. Перед предложением или запуском точной команды нужно вызвать gcloud help для leaf-level подкоманды, например gcloud help compute instances create. Проверка родительской группы не переносится на дочернюю команду. Это ограничение распространяется и на планы: первым шагом должна быть валидация синтаксиса, затем проверка обязательных и необязательных параметров, наличие dry-run или validate-only и только после этого — предложение или разрешённый запуск. Skill отдельно уменьшает объём данных, который CLI возвращает агенту. Команду list нельзя выполнять без хотя бы одного ограничения: --limit, --filter или --format. Для нужных полей рекомендуется projection через --format=json(key1, key2), а при неизвестной схеме сначала следует запросить один объект с --limit=1 --format=json. После просмотра реальной структуры можно строить точный filter и projection, не загружая весь ресурсный список. Такой порядок полезен для discovery и диагностики: сначала ограниченная выборка, затем проверка полей, потом узкий запрос. Не следует угадывать JSON-путь, filter или формат вывода по названию ресурса. Выполнение должно оставаться атомарным и явно scoped. Источник запрещает цепочки shell-команд, pipe, redirection и command substitution в исполняемом gcloud workflow; предполагается одна понятная команда за раз. Для headless-сценария нужны --quiet или -q, чтобы команда не зависала на интерактивном подтверждении, выборе значения по умолчанию или отсутствии stdin. Для операций с ресурсами и запросов нужно явно указывать --project=<PROJECT_ID>, а для региональных и зональных ресурсов — --region, --zone или --location. Если локация неизвестна, её сначала ищут ограниченной командой discovery, например gcloud compute regions list с project scope или соответствующим locations list. Активные defaults нельзя считать достаточным доказательством целевого проекта. Безопасностные границы описаны отдельно. Любые IAM policy, role и binding изменения требуют участия человека; API нельзя включать проактивно, потому что это может создать ресурсы или расходы. Команды gcloud * delete, billing, organizations, kms и infra-manager deployments apply находятся в denylist автономного запуска. Delete, update и remove в общем случае нельзя выполнять без явного разрешения пользователя. Если leaf-level help показывает --dry-run или --validate-only, этот режим обязателен до фактического действия. Для длительных операций можно использовать --async, но operation ID после этого нужно проверять, если следующий шаг зависит от завершения. Практический сценарий начинается с аутентификации подходящего типа: user login, Application Default Credentials или явно разрешённого service account в зависимости от среды. Skill не выдаёт права и не проверяет, что выбранный аккаунт действительно имеет нужный доступ. Он также не заменяет чтение схемы ресурса, подтверждение проекта или проверку результата после операции. Ограничение важно и для генерации текста: карточка помогает сформировать безопасное предложение команды, но не должна подменять свежий gcloud help. Для cloud-инфраструктуры это не универсальный рецепт развертывания, а guardrail-first инструкция, снижающая риск неверного флага, широкого list-запроса, интерактивного зависания и действия в чужом проекте.