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/serverlessnpx skills add arjunprabhulal/devops-skills --skill serverlessgit 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.00115 | $0.01148 |
| Opus 5 | $0.00057 | $0.00574 |
| Sonnet 5 | $0.00023 | $0.00230 |
| Haiku 4.5 | $0.00012 | $0.00115 |
Grade A, and why
serverless 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 3d 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.
Serverless
Serverless is not "no infrastructure" — it is infrastructure with the operational knobs replaced by a billing meter and a set of hard limits you don't control. The platform enforces statelessness, imposes concurrency ceilings, and charges per invocation. That's a genuine gift for bursty, event-driven work, and a genuine liability for steady, latency-sensitive, or long-running work.
The question is never "is serverless good" — it's whether your workload's shape matches the platform's enforced shape. Match the workload's traffic and duration profile to the platform's constraints before you match its convenience.
1. Treat statelessness as enforced, not optional
A function instance can be frozen, killed, or never reused between invocations. Anything written
to local disk or held in memory across calls is not guaranteed to survive to the next one. This
is the same principle as cloud-architecture's statelessness default, except here the platform
enforces it for you instead of asking nicely — so design the function so a cold, stateless restart
on every single call would still be correct.
Done when: the function produces correct output with zero assumptions about warm-instance reuse.
2. Budget for cold starts explicitly
A cold start pays for provisioning a runtime, loading your code, and initializing dependencies, and that latency lands on whichever request triggers it. For latency-sensitive paths, this is not a rounding error — it can be the majority of response time under low or spiky traffic.
- Keep the deployment package small — fewer dependencies to load means a faster cold start.
- Initialize expensive clients outside the handler so warm invocations skip that cost, but never depend on that state being present.
- Use provisioned/reserved concurrency for latency-critical functions if the platform offers it, and treat that as paying to opt partway out of serverless's cost model.
- Accept the latency for background and async paths where nobody's waiting on the response.
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.
- 3d ago First seen · 91 lines · 115 tokens per session scan A 3059a714eecc
serverless is a skill published in the GitHub repository arjunprabhulal/devops-skills (2 stars, last pushed 8d ago), licensed MIT. It adds 115 tokens to every session and 1,148 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
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…