Getting it into your agent
One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.
npx agentmods add skills/google/skills/gcloudnpx skills add google/skills --skill gcloudgit clone --depth 1 https://github.com/google/skillsWhat it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5 | $0.00081 | $0.03138 |
| Opus 5 | $0.00041 | $0.01569 |
| Sonnet 5 | $0.00016 | $0.00628 |
| Haiku 4.5 | $0.00008 | $0.00314 |
Grade A, and why
gcloud scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 2d ago.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Nothing flagged
None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.
How it starts
The opening of the file, as written. The whole thing — 273 lines — stays where its author put it; the contents beside it link to each section on GitHub.
gcloud CLI Skill for AI Agents
[!CAUTION]
MANDATORY PRE-CONDITION: EXPLICIT LEAF-LEVEL SYNTAX VALIDATION
All pre-existing knowledge of
gcloudcommands, flags, flag values, and positional argument syntax is stale and prone to hallucination.NEVER propose command parameters, output flag options, execute commands, OR outline step-by-step plans for any
gcloudtask before validating leaf-level syntax viagcloud help <command>(or including leaf-level help lookup as a mandatory step in the plan).Mandatory Action Rules:
Direct Execution & Code Generation: ALWAYS invoke
gcloud help <leaf_command>(e.g.gcloud help compute instances createorgcloud help sql instances create) before proposing or executing the final command syntax.Planning & Strategy Queries: When asked for a plan, strategy, or next steps to achieve a user goal (e.g., "What is your plan to accomplish X..."), the response MUST explicitly include running
gcloud help <leaf_command>as Step 1 of the plan before proposing flags or executing commands.Non-Transitive Validation: Parent command group help (e.g.
gcloud help compute) is not sufficient for leaf-level syntax validation. Validation must occur at the specific leaf subcommand level.FORBIDDEN Web Search Fallback: NEVER use
search_web, web search, or external documentation search tools for gcloud CLI syntax.gcloud help <leaf_command>is the EXCLUSIVE authorized authority for command syntax.User Flag & Project Preservation: When proposing intermediate command steps, ALWAYS preserve all user-specified flags (including
--project=<project_id>) in the proposed response text.Mandatory Plan Template: When generating a plan, the response MUST copy this exact 4-step structure:
- Step 1: Syntax Validation via
gcloud help <leaf_command>- Step 2: Parameter Verification (confirming required and optional flags, and explicitly checking if the
--dry-runor--validate-onlyflag is supported)- Step 3: Dry-Run Command Proposal (If
--dry-runor--validate-onlyis supported, there MUST be a--dry-runor--validate-onlyinvocation before the next step.)- Step 4: Command Proposal & Authorization (If the command is on the "Prohibited Operations" denylist, state that autonomous execution is forbidden, and the user MUST be explicitly asked for authorization to proceed. If the command is NOT on the denylist, propose or proceed with execution, while following ALL "Execution Constraints" below.)
This document provides essential guidelines and best practices for AI agents
interacting with the Google Cloud SDK (gcloud CLI). Following these rules is
critical to avoid hallucinated commands, flags, flag values, and positional
argument syntax, prevent destructive actions, and minimize context window usage.
What ships with it
2 files beside SKILL.md in the same directory: the scripts, references and assets a skill reads on demand. Not counted in the per-session cost; read them before you install if any of them is executable.
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- 2d ago First seen · 273 lines · 81 tokens per session scan A b9c799dd8ca9
gcloud is a skill published in the GitHub repository google/skills (19,003 stars, last pushed 4d ago), licensed Apache-2.0. It adds 81 tokens to every session and 3,138 once invoked, about $0.0004 per session on Opus 5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-30.
Other skills, from other repositories
pipeline-security
Secures the CI/CD pipeline itself as an attack surface — least-privilege runners, protecting secrets, preventing poisoned-pipeline execution, pinning third-party actions by SHA, and preferring OIDC over long-lived keys. Use this whenever the user configures CI runner permissions, stores secrets for a pipeline, reviews…
scheduled-jobs
Covers cron and scheduled work done right — idempotency, preventing overlapping runs, monitoring for missed and failed runs, alerting on silence, and getting time zones and DST transitions correct. Use this whenever the user is writing a cron job or Kubernetes CronJob, asks why a scheduled job ran twice or didn't run…
scripting-automation
Covers writing operational scripts that survive contact with production — idempotency, real error handling and exit codes, structured logging, a dry-run mode, and recognizing when a script has outgrown scripting. Use this whenever the user is writing a bash or Python script that touches production, asks why a script…
artifact-management
Versions, stores, and promotes build outputs — registries, immutability, build-once-promote-many, retention and garbage collection, and provenance metadata. Use this whenever the user sets up an artifact or container registry, asks how to promote a build between environments without rebuilding, needs a retention or…
build-optimization
Makes builds fast and reproducible through incremental and hermetic builds, remote or shared caching, dependency caching, and parallelism, without trading correctness for speed. Use this whenever the user complains builds are slow, asks about build caching or cache keys, wants to cut cold-build time, is setting up a…
ci-pipelines
Designs continuous integration pipelines that give a fast, honest merge signal — stage ordering, reproducibility, safe caching, and required checks that actually gate merges. Use this whenever the user is writing or debugging a CI workflow (GitHub Actions, GitLab CI, Jenkins), complaining that CI is slow or flaky…