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/arjunprabhulal/devops-skills/multi-cloudnpx skills add arjunprabhulal/devops-skills --skill multi-cloudgit clone --depth 1 https://github.com/arjunprabhulal/devops-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.00100 | $0.01115 |
| Opus 5 | $0.00050 | $0.00558 |
| Sonnet 5 | $0.00020 | $0.00223 |
| Haiku 4.5 | $0.00010 | $0.00112 |
Grade A, and why
multi-cloud 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 — 91 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Multi-Cloud
Multi-cloud is usually sold as risk reduction and delivered as a tax: a second provider means a second set of IAM models, networking primitives, billing dashboards, and on-call runbooks to maintain, permanently, whether or not you ever use the failover it was meant to provide. The question is never whether multi-cloud is possible — it always is — but whether the ongoing operational cost buys something the business actually needs.
Most teams that end up multi-cloud didn't decide to; they acquired a company, or a team picked a different provider, or a vendor tool only ran on one cloud. Multi-cloud should be a decision with a stated reason, not something you discover you're already doing.
1. Name the reason before building anything
The legitimate reasons are narrow: a regulatory requirement to avoid a single vendor, genuine negotiating leverage at large spend, a specific managed service only one provider offers, or disaster-recovery requirements that mandate provider diversity. "Just in case we need to switch" is not on that list — it's a hedge against a risk that's rarely priced against the daily cost of carrying it.
Done when: the reason for running on more than one provider is written down and would survive someone asking "why not just use one?"
2. Separate true portability from lowest-common-denominator design
Building only on the intersection of features every provider supports means giving up each
provider's best managed offerings — a managed database with strong consistency guarantees, a
purpose-built queue — in favor of something you self-run so it's portable. That trade is
sometimes right and often isn't; know which one you're making. A portability layer like Kubernetes
gets you portable compute, not portable everything — data services, IAM, and networking still
differ underneath. See kubernetes-operations for running that layer, and cloud-architecture
for the managed-vs-self-run tradeoff this decision is really an instance of.
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 · 91 lines · 100 tokens per session scan A bd5e2586acf6
multi-cloud is a skill published in the GitHub repository arjunprabhulal/devops-skills (2 stars, last pushed 8d ago), licensed MIT. It adds 100 tokens to every session and 1,115 once invoked, about $0.0005 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-31.
Other skills, from other repositories
agent-platform-deploy
Deploy open models or custom weights from Model Garden to Agent Platform endpoints, check the status of an in-progress deployment operation, or clean up resources by undeploying models and deleting endpoints. Use when asked to actively deploy a model, list the Model Garden CATALOG of available models, check if a…
agent-platform-alert-configuration
Configures best-practice alerting policies for AI agents using OpenTelemetry (OTel) metrics, generating output as Terraform (.tf) configuration files. Use when analyzing, writing, or deploying alerting policies to monitor agent latency, error rates, token usage, and quality metrics. Don't use for standard…
application-design-center-design-deploy
Processes GCP infrastructure design and deployment workflows within Application Design Center (ADC). Use when: - Designing GCP infrastructure with Terraform. - Validating local HCL. - Performing best-practice plan scans. - Importing templates to Application Design Center (ADC). - Deploying templates. - Troubleshooting…
cloud-logging-cross-project-configuration
Configure and troubleshoot Google Cloud cross-project centralized logging and read-time aggregation. Use when: - Setting up log routing from multiple projects/folders/organizations to a central log bucket. - Creating cross-project log sinks and configuring central log buckets. - Troubleshooting cross-project routing.…
cloud-run-basics
Manages Cloud Run services, jobs, and worker pools. Use when you need to deploy applications responding to HTTP requests (services), run event-triggered or scheduled tasks (jobs), or handle always-on pull-based background processing (worker pools).
gcloud
Provides safety-critical validation, guardrails, and data reduction for gcloud CLI operations across Google Cloud Platform (GCP) services and infrastructure. Use when planning, generating, constructing, proposing, describing, or executing any gcloud CLI commands - including when answering questions about gcloud…