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/cloud-architecturenpx skills add arjunprabhulal/devops-skills --skill cloud-architecturegit clone --depth 1 https://github.com/arjunprabhulal/devops-skillsWrote this? Show the measurements
A badge with what this costs and how it scanned, read live from this page, so it follows the numbers instead of freezing them. Markdown for a README, HTML for a documentation site or a project page.
[](https://agentmods.dev/skills/arjunprabhulal/devops-skills/cloud-architecture)<a href="https://agentmods.dev/skills/arjunprabhulal/devops-skills/cloud-architecture"><img src="https://agentmods.dev/badge/skills/arjunprabhulal/devops-skills/cloud-architecture.svg" alt="Measured on agentmods" height="20"></a>What 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.1 | $0.00122 | $0.01180 |
| Opus 5 | $0.00061 | $0.00590 |
| Sonnet 5 | $0.00024 | $0.00236 |
| Haiku 4.5 | $0.00012 | $0.00118 |
Grade A, and why
cloud-architecture 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 6d 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 — 93 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Cloud Architecture
The cloud is not a bigger data center; it is a set of failure domains with prices attached. Every region, zone, and managed service is a boundary that fails independently and bills differently. Architecture in the cloud is mostly the discipline of choosing which boundaries your system can survive crossing, and which ones you pay to avoid.
Most bad cloud architectures are not wrong on features — they are wrong on failure domains, built as if a region or a disk is permanent. Design for the boundary to fail, then decide what you're willing to pay to make that survivable.
1. Put failure domains on paper before compute
Draw the regions, zones, and managed-service boundaries before you draw a single instance or container. Every one of those lines is a place where a real outage has happened to someone. A single-AZ deployment is a bet that AZ never fails; a single-region deployment is a bet the region never does. Neither bet needs to be wrong — but it must be a decision, not a default.
- Zones protect against power, network, and hardware failure at low latency cost and low effort — use them for anything worth being up during a routine outage.
- Regions protect against correlated failures (control-plane bugs, natural disasters) at real latency and data-consistency cost — reserve multi-region for the workloads that justify it.
- Managed-service boundaries (a database's own failover, a queue's durability guarantee) often give you more resilience per dollar than DIY replication across zones.
Done when: every major component has a stated failure domain and a stated blast radius if that domain goes down.
2. Default to managed, justify self-run
A managed database, queue, or cache pushes operational failure modes onto someone whose full-time job is not failing at them. Self-running the same thing is sometimes right — cost at scale, a feature the managed version lacks, regulatory control — but it is a decision with an ongoing staffing cost, not a one-time engineering cost. Write down the reason, because in a year someone will ask why you're patching a database cluster by hand.
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.
- 6d ago First seen · 93 lines · 122 tokens per session scan A 8c15f72600b5
cloud-architecture is a skill published in the GitHub repository arjunprabhulal/devops-skills (3 stars, last pushed 11d ago), licensed MIT. It adds 122 tokens to every session and 1,180 once invoked, about $0.0006 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
google-cloud-solution-guided-gke-ai-migration
Guides the migration of existing AI workloads (Cloud Run, Gemini API, Gemini Enterprise Agent Platform) to self-hosted GKE inference using gcloud and kubectl. Use when the user has an existing AI inference workload (on Cloud Run, the Gemini API, Gemini Enterprise Agent Platform, or a custom VM) and wants to move it to…
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…
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.…
gke-alert-configuration
Configures alerting policies in Terraform for Google Kubernetes Engine (GKE) clusters, workloads, and services using PromQL and Google Cloud Managed Service for Prometheus. Use when writing, analyzing, validating, or deploying Terraform alerting policies to monitor GKE service latency, traffic, error rates using…
gke-compute-classes
Configures, optimizes, and troubleshoots GKE ComputeClasses. Use when configuring Spot VMs with on-demand fallback, targeting specific accelerators (GPUs/TPUs) or machine families, restricting ComputeClass access, or debugging pending pods related to node pool auto-creation. Do not use for cluster-level Node Auto…
google-cloud-recipe-foundation-builder
Deploys a baseline landing zone foundation for a Google Cloud Organization, establishing security guardrails using Organization Policies, resource hierarchy folders and projects, billing association, and centralized logging and monitoring. Deploys Google Cloud's recommended security controls and architecture. Use when…