DevOps practice written as field guides that an AI coding agent loads on demand.
88 skills across 15 categories: CI/CD, containers, Kubernetes, infrastructure as code, cloud,
GitOps, observability, reliability, security, networking, data, platform engineering,
automation, FinOps, and performance.
| # | Section |
|---|---|
| 1 | 📚 Skills Catalogue |
| 2 | 🚀 Quick start |
| 3 | 🧩 What a skill is |
| 4 | 📥 Installation |
| 5 | 🧲 skills.sh |
| 6 | 📖 Documentation |
| 7 | 🗺️ Roadmap |
| 8 | 🤝 Contributing |
Agents are good at the work and inconsistent at the process. Each skill here is the written-down
procedure for one DevOps job: numbered steps, each ending in a check the agent can actually
verify against a real system, and a final Report that states what the skill does not cover.
Tools are named to illustrate a principle, never as a requirement.
| Category | Skills | Focus |
|---|---|---|
| CI/CD | 8 | Getting a change from commit to production, fast and safe |
| Containers | 4 | Packaging applications into images that are small, reproducible, and safe |
| Kubernetes | 9 | Running workloads on Kubernetes without fighting the control loop |
| Infrastructure as Code | 6 | Changing infrastructure through version-controlled, reviewable configuration |
| Cloud | 6 | Designing and operating on cloud platforms deliberately |
| GitOps | 3 | Making Git the source of truth and letting a controller reconcile reality to it |
| Observability | 7 | Making running systems explain themselves |
| Reliability & SRE | 8 | Keeping systems up, and recovering fast when they are not |
| Security & DevSecOps | 8 | Building security into the pipeline and the platform, not bolting it on |
| Networking | 6 | Getting traffic to the right place, reliably and securely |
| Data & Storage | 5 | Running stateful systems and moving data without losing it |
| Platform Engineering | 5 | Building the paved roads that make the right way the easy way |
| Automation | 5 | Removing the repetitive, error-prone work humans should not be doing |
| FinOps | 4 | Spending cloud money deliberately, not accidentally |
| Performance | 4 | Making systems fast by measuring, not guessing |
Each category links down to its section in the detailed catalogue at the end of this README.
npx skills add arjunprabhulal/devops-skillsSkills load themselves when the work matches. You never name them.
| You say | What loads | What changes |
|---|---|---|
| "a pod keeps restarting, CrashLoopBackOff, and I can't tell why" | kubernetes-operations |
Reads the container's previous logs before the restart, then describe/events for the exit code — 137 points at the memory limit, 1 at the process itself |
| "our terraform plan wants to replace the RDS instance and I don't know what changed" | infrastructure-as-code |
Finds the forces replacement line in the plan output first, then decides whether the attribute driving it can be changed in place |
| "checkout is down for about 30% of users" | incident-response |
Mitigates first — rollback, failover, or shed load — before diagnosing, with one person owning the decisions |
| "how much capacity do we need for the launch?" | capacity-planning |
Starts from the measured ceiling and scaling lead time, and names the resource that saturates first |
To invoke one deliberately, name it: "use the incident-response skill".
Using a skill in Claude Code and Antigravity
There is no command to run. Both Claude Code and Antigravity preload only each skill's name
and description, then read the body of a SKILL.md when the description matches the task.
> a pod keeps restarting, CrashLoopBackOff, and I can't tell why
⏺ Skill(kubernetes-operations)
Reads the container's previous logs before the restart, then describe/events for the
exit code — 137 points at the memory limit, 1 at the process itself...
Antigravity discovers skills from .agents/skills/<skill>/ in the workspace and
~/.gemini/config/skills/<skill>/ globally, and selects them the same way — by description.
Per the Antigravity skills documentation: "You don't
need to explicitly tell the agent to use a skill — it decides based on context. However, you can
mention a skill by name if you want to ensure it's used."
Skills also compose. A cost question that turns into a sizing question pulls in
rightsizing from
cost-optimization, because each skill names the
sibling to hand off to.
A directory containing a SKILL.md. YAML frontmatter declares when it applies, then the body
gives the procedure to follow. The description does the heavy lifting — it is the only part
always in context, and it alone decides whether the skill loads.
See a real one: the opening of skills/reliability/incident-response/SKILL.md
---
name: incident-response
description: Runs a live incident from first alert to resolution — assigning clear roles, mitigating before diagnosing, setting severity, and communicating in a structured cadence so a system under stress does not also become a communication failure. Use this whenever the user says production is down, an alert just fired, customers are affected, they need an incident commander, or they ask how to run or structure an active incident. For the after-the-fact writeup use `root-cause-analysis`, for the step-by-step fix procedures use `runbooks`, and for the on-call rotation that catches the page use `on-call-management`.
license: MIT
---
**Mitigate first, understand second, and let one person own the decisions.**
## 2. Mitigate before you diagnose
Rolling back a bad deploy, failing over to a healthy region, or shedding load buys time and
stops the bleeding, even if you don't yet know why the system broke. Root-causing while the
customer is still down is optimizing for the wrong thing. The fix does not need to be
permanent — it needs to be now.
- **Ask "what changed?" before "why did it break?"** — most incidents trace to a recent
deploy, config change, or scaling event, and reverting it is faster than understanding it.
- **Prefer reversible mitigations** — a rollback or a traffic shift you can undo beats a
targeted code fix you're improvising under pressure.
- **A mitigated incident is not a closed incident** — it moves to lower urgency, not to done.
**Done when:** customer-facing impact has stopped or measurably reduced, independent of
whether the cause is understood.Notice how much of that file is the description. It names the phrasings a user would actually type, and hands off to the sibling skill for the adjacent case.
Only the name and description of each skill sit in context permanently. The body loads when
the skill matches; bundled references/ load only when the procedure reaches for them. Because a
skill is just a file, any harness that can read one can use these.
Claude Code — as a plugin, or one skill at a time
/plugin marketplace add arjunprabhulal/devops-skills
/plugin install devops-skills@arjunprabhulal
cp -r skills/kubernetes/kubernetes-operations ~/.claude/skills/Google Antigravity — via the generated .agents/skills/ layout
Antigravity reads a flat .agents/skills/ layout, which is generated from the canonical tree
rather than committed. Build it once, then take the whole set into a workspace or one skill
globally:
git clone https://github.com/arjunprabhulal/devops-skills.git
cd devops-skills && python3 scripts/build-antigravity.py
cp -r .agents /path/to/your-project/
cp -r .agents/skills/kubernetes-operations ~/.gemini/config/skills/Any harness — through the skills CLI
npx skills add arjunprabhulal/devops-skills--skill <name> installs a single skill instead of the whole set. New installs always fetch the
current contents; npx skills update refreshes what you already installed.
See docs/installation.md for rules and workflows, verification, updating, and uninstalling.
This collection is also listed on skills.sh — the open directory and install leaderboard for agent skills, built by Vercel. The badge in the header shows the listing's live install count, and the listing has a page for every one of the 88 skills with its own install command.
# the whole set — lists all 88 skills and links the ones you pick
npx skills add arjunprabhulal/devops-skills
# a single skill, e.g. alerting
npx skills add arjunprabhulal/devops-skills --skill alerting
# refresh skills you installed when this repo changes
npx skills update- Browse the listing: https://www.skills.sh/arjunprabhulal/devops-skills
- How the count works: the skills CLI reports installs anonymously, and the leaderboard ranks collections by that telemetry — installing from anywhere (this README, the listing, a post) is what moves the collection up it.
- Progressive disclosure: skills.sh loads only each skill's
nameanddescriptionup front, so browsing the catalogue costs nothing; the body loads when a skill matches the task.
| Guide | Covers |
|---|---|
| Installation | Installing in Claude Code, Antigravity, or by hand |
| Authoring skills | The skill format, frontmatter rules, and constraints |
| Evals | The eval file schema and the three-case convention |
| Architecture | Repository layout, the two skill trees, and the scripts |
| Publishing | Listing on skills.sh, other directories, and distribution |
| FAQ | Common questions about scope, triggering, and limits |
- 88 skills across 15 categories
- Validation tooling and continuous integration
- Plugin packaging and marketplace
- Eval cases for every skill
- Automated eval runner harness (
scripts/run-evals.py) - Generated Antigravity layout
- skills.sh listing and
npxinstaller - Cross-harness install docs (Cursor, Windsurf, Copilot) via the skills CLI and rules
- Refresh schedule for vendor syntax in
references/ - Execute the eval suite against a no-skill baseline
New skills should be single-responsibility, take a position and explain it, and end with a Report. Match the format of an existing skill and cross-reference siblings rather than duplicating them. See CONTRIBUTING.md for the full process, and the code of conduct for how discussions run here. The validator must pass.
The most valuable contribution is a skill you have used on real work, or a report of one that behaved badly. A transcript of what you asked and what the agent did is worth more than a bug description.
Security issues go through SECURITY.md, privately. Everything else — questions, proposals, and bug reports — belongs in GitHub issues.
The SKILL.md format follows the
Agent Skills specification published by Anthropic. The authoring
standards here (trigger-oriented descriptions, progressive disclosure through reference files,
and completion criteria on every step) draw on their published guidance and on the reference
skill collection at anthropics/skills.
This repository is licensed under the MIT License.
The full catalogue, one table per category with every skill and its description. The repository layout, authoring standards, testing, and validation details follow in the sections above.
Getting a change from commit to production, fast and safe.
| Skill | What it does |
|---|---|
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 |
continuous-delivery |
Builds the deployment pipeline that takes an artifact from a merged commit to production automatically and safely — promotion gates between environments, deploy-on-merge, and keeping main always releasable |
deployment-strategies |
Chooses and implements the deployment technique — blue-green, canary, rolling, or shadow — that buys the most information before you're fully committed, plus the rollback plan that makes each one safe |
release-management |
Coordinates what ships and when — semantic versioning, changelogs, release trains vs continuous release, and cutting a multi-service release safely |
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 |
artifact-management |
Versions, stores, and promotes build outputs — registries, immutability, build-once-promote-many, retention and garbage collection, and provenance metadata |
feature-flags |
Decouples deploying code from releasing it to users through runtime feature flags — flag types, targeting rules, and the flag-debt cleanup discipline that keeps the flag system from becoming its own liability |
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 |
Packaging applications into images that are small, reproducible, and safe.
| Skill | What it does |
|---|---|
containerization |
Packages an application into a container image that is small, reproducible, and safe to run — Dockerfiles, layer caching, multi-stage builds, non-root users, and runtime configuration |
image-optimization |
Shrinks container image size and build time — base image choice, layer minimization, dependency pruning, .dockerignore, multi-arch builds, and measuring what actually ends up in the image |
image-scanning |
Finds vulnerabilities, misconfiguration, and embedded secrets in container images before they ship — CVE scanning in the pipeline, gate-versus-warn policy, base image freshness, and separating fixable findings from noise |
container-registry |
Stores and distributes container images safely — tagging strategy, immutability, retention and garbage collection, access control, signing, and replication or pull-through caching |
Running workloads on Kubernetes without fighting the control loop.
| Skill | What it does |
|---|---|
kubernetes-operations |
Covers running workloads through Kubernetes's control loop — requests/limits, liveness/readiness/startup probes, reading describe/events to debug CrashLoopBackOff, OOMKilled, Pending, or empty endpoints, safe rollouts and undo, and guardrails like PodDisruptionBudgets |
kubernetes-networking |
Explains how traffic reaches and moves between pods — Services (ClusterIP/NodePort/LoadBalancer), Ingress and controllers, cluster DNS, NetworkPolicy default-deny, and debugging selector mismatches or empty endpoints |
kubernetes-security |
Hardens the cluster and its workloads — RBAC least-privilege, Pod Security Standards, admission control with OPA/Kyverno, securityContext, secrets at rest, image provenance, and disabling default service-account automount |
helm-charts |
Covers packaging and templating Kubernetes manifests with Helm — chart structure, values design and environment overrides, releases and revisions, upgrade/rollback semantics, avoiding template sprawl, and choosing Helm versus Kustomize |
kubernetes-storage |
Covers persistent data in the cluster — PersistentVolumes/Claims, StorageClasses and dynamic provisioning, access modes, StatefulSets, volume lifecycle, and reclaim policy so data survives rescheduling |
autoscaling |
Covers scaling Kubernetes workloads and nodes to demand — HPA on the right metric, VPA, cluster autoscaler, custom/external metrics, avoiding thrash with stabilization windows, and requests as the foundation underneath it all |
service-mesh |
Covers when and how to adopt a service mesh — mTLS between services, traffic shifting, retries/timeouts enforced at the mesh layer, near-free observability, and the real latency and complexity cost of running one |
operators-and-crds |
Covers extending Kubernetes with CustomResourceDefinitions and controllers — the reconciliation pattern, a CRD as an API contract, why controllers must be level-triggered not edge-triggered, and when to build an operator versus buy one versus not bother |
multi-tenancy |
Covers safely sharing a Kubernetes cluster across teams or customers — namespace isolation, ResourceQuota and LimitRange, NetworkPolicy tenant boundaries, per-tenant RBAC, noisy-neighbor control, and soft versus hard multi-tenancy |
Changing infrastructure through version-controlled, reviewable configuration.
| Skill | What it does |
|---|---|
infrastructure-as-code |
Treats infrastructure changes as version-controlled, reviewable configuration instead of manual clicks or SSH sessions — Terraform state, plan review, environment parity, and guardrails against irreversible changes |
terraform-modules |
Covers designing Terraform modules that are reusable and composable rather than copy-pasted or over-engineered — clean input/output interfaces, version pinning, and knowing when abstraction earns its complexity |
configuration-management |
Covers Ansible, Chef, and Puppet for managing mutable systems declaratively — idempotent tasks, convergence toward desired state instead of one-off scripts, inventory organization, and roles |
policy-as-code |
Covers enforcing infrastructure and cluster rules automatically, before a bad change ever reaches production — OPA, Sentinel, and Kyverno policies evaluated against the plan or admission request, and testing those policies like real code |
environment-management |
Covers keeping dev, staging, and prod as the same system at different sizes rather than forked copies that drift apart — parity via values not branches, ephemeral preview environments per pull request, and keeping non-prod cheap without making it useless as a signal |
immutable-infrastructure |
Covers replacing servers wholesale instead of patching them in place — baking golden images, treating instances as disposable cattle rather than nursed pets, rebuilding to make any change, and the rollback simplicity that buys |
Designing and operating on cloud platforms deliberately.
| Skill | What it does |
|---|---|
cloud-architecture |
Designs systems for the cloud's actual shape — regions and availability zones, managed vs self-run tradeoffs, statelessness, failure-domain isolation, and the cost and lock-in consequences of each choice |
serverless |
Covers functions and managed compute where the platform enforces statelessness and bills per request — cold starts, event-driven design, concurrency limits, and when serverless does not fit |
cloud-networking |
Covers the virtual network layer of a cloud deployment — VPCs, subnets, route tables, peering and transit, private endpoints, egress control, and hybrid or on-prem connectivity |
cloud-migration |
Guides moving workloads to or between clouds using the 6 Rs, a phased cutover with a real rollback path, data sync, and avoiding a lift-and-shift that just relocates old problems |
multi-cloud |
Covers running across cloud providers on purpose — portability vs managed services, the real operational cost of a second provider, avoiding accidental multi-cloud, and where the abstraction is worth it |
well-architected-review |
Runs a structured audit against the standard pillars — reliability, security, cost, performance, operational excellence, sustainability — producing prioritized, actionable findings, not a checklist tick |
Making Git the source of truth and letting a controller reconcile reality to it.
| Skill | What it does |
|---|---|
gitops |
Establishes Git as the single source of truth for deployed state, with a pull-based controller reconciling the cluster to match a repo instead of humans or pipelines pushing changes via kubectl or helm |
argocd-operations |
Covers running Argo CD day to day — structuring app-of-apps, choosing sync policies and waves, reading health versus sync status correctly, and unsticking a degraded or hung Application |
progressive-delivery |
Automates canary and blue-green rollouts so promotion and rollback are driven by live metrics, not a timer or a human watching a dashboard, using controllers like Argo Rollouts or Flagger |
Making running systems explain themselves.
| Skill | What it does |
|---|---|
observability |
Frames the mental model for making a running system explain itself — metrics, logs, and traces as complementary signals, RED and USE checklists, SLOs and error budgets, cardinality as the tax paid for detail |
metrics-and-monitoring |
Covers instrumenting and collecting numeric time-series data — the Prometheus data model, choosing between counters, gauges, and histograms, controlling cardinality before it controls your bill, applying RED and USE systematically, and writing recording rules |
log-management |
Covers structured logging at scale — emitting JSON not prose, choosing sensible levels, sampling high-volume paths, setting retention against real cost, correlating log lines with trace IDs, and keeping secrets out of logs entirely |
distributed-tracing |
Covers following a single request across service boundaries — context propagation, span and attribute design, sampling that keeps the traces worth keeping, and using traces to find where latency actually accumulates |
alerting |
Covers designing alerts that page a human only when a human needs to act — symptom-based alerting over cause-based, multi-window burn-rate alerts on error budgets, severity tiers that route between page/ticket/dashboard, requiring every page to link a runbook, and tuning out alert fatigue |
dashboards |
Covers building dashboards people actually open during an incident instead of ignoring — one question per panel, RED/USE-based layout, designing for a specific audience and decision, and avoiding the wall-of-graphs nobody reads |
slo-definition |
Covers turning "the service should be reliable" into a falsifiable number — SLIs that reflect real user experience, SLO targets meaningfully below 100%, the error budget those targets imply, and the policy that gates release velocity when it's spent |
Keeping systems up, and recovering fast when they are not.
| Skill | What it does |
|---|---|
incident-response |
Runs a live incident from first alert to resolution — assigning clear roles, mitigating before diagnosing, setting severity, and communicating in a structured cadence so a system under stress does not also become a communication failure |
runbooks |
Writes and maintains the procedural documents that let a tired, half-awake engineer resolve a known failure at 3am without needing the original author or deep system knowledge |
disaster-recovery |
Prepares a system to survive a total, catastrophic failure — a lost region, a corrupted database, a deleted cloud account — through defined RTO/RPO targets, backups that have actually been restored, and tested failover, not a backup cron job someone set up once |
chaos-engineering |
Deliberately injects controlled failure into a system to find weaknesses before they find you in production, using a stated hypothesis, a bounded blast radius, and a defined steady-state metric to verify against |
capacity-planning |
Ensures a system has enough headroom before it needs it, by forecasting growth, modeling load against real saturation signals, and accounting for the lead time it takes to actually add capacity |
root-cause-analysis |
Turns an incident into a blameless postmortem that actually changes something — a factual timeline, multiple contributing factors instead of one scapegoat cause, and action items with real owners and dates that get tracked to completion |
on-call-management |
Designs a sustainable on-call system — fair rotations, clear escalation paths, clean handoffs, and a humane alert load — and treats on-call health itself as a reliability metric rather than an unmeasured cost absorbed by whoever holds the pager |
error-budgets |
Turns an SLO into a spendable number that makes the velocity-versus-reliability tradeoff explicit — deriving the budget from the SLO, tracking how fast it's consumed, and enforcing freeze policies when it runs out, instead of arguing about "is it reliable enough" from gut feeling |
Building security into the pipeline and the platform, not bolting it on.
| Skill | What it does |
|---|---|
secrets-management |
Keeps credentials, API keys, and certificates out of code, images, and logs, and moves them into a real secret store with tight, scoped runtime injection |
vulnerability-management |
Finds, prioritizes, and closes out vulnerabilities across code, dependencies, images, and infrastructure without drowning the team in unactionable findings |
supply-chain-security |
Establishes trust in what you build and ship — SBOMs, build provenance, dependency pinning and verification, artifact signing, and signature verification before deploy |
compliance-as-code |
Turns compliance controls into executable, version-controlled checks with automated evidence collection, so audits become a query instead of a fire drill |
iam-access-management |
Grants least-privilege access to systems and cloud resources through roles rather than individual permissions, short-lived credentials, and regular review, so standing access doesn't accumulate unnoticed |
security-scanning |
Places SAST, DAST, and dependency scanning at the right stage of the pipeline, tuned to gate or merely inform depending on confidence, without turning every merge into a wall of unreviewed findings |
network-security |
Protects traffic and boundaries through segmentation, default-deny rules, egress control, and TLS everywhere, minimizing what's actually reachable on the network |
zero-trust |
Replaces network location with verified identity as the basis for access, removing implicit trust inside the perimeter via microsegmentation and continuous verification |
Getting traffic to the right place, reliably and securely.
| Skill | What it does |
|---|---|
dns-management |
Covers DNS as production infrastructure that can take down everything downstream — record types, TTL tradeoffs, propagation and caching, health-checked failover, and split-horizon setups for internal versus external views |
load-balancing |
Covers distributing traffic across healthy backends — L4 versus L7 balancing, algorithms, health checks that detect real failure, connection draining during deploys, and the real latency and capacity cost of sticky sessions |
api-gateway |
Covers the managed front-door pattern for APIs — request routing, centralized auth, rate limiting and quotas, request/response shaping, and recognizing when a gateway helps versus becomes a bottleneck or single point of failure |
cdn |
Covers caching and serving content at the edge — cache keys and TTL design, invalidation strategies, origin shielding, deciding what is safely cacheable, and moving static and dynamic content closer to users |
service-connectivity |
Covers making service-to-service connections reliable and secure — service discovery, mutual TLS, timeouts and retries with circuit breakers, backpressure under load, and secure links across hybrid or multi-cloud boundaries |
network-troubleshooting |
Covers diagnosing connectivity failures methodically, layer by layer, with the right tool per symptom — dig/nslookup for DNS, curl/openssl for TLS and HTTP, traceroute/mtr for routing, tcpdump for packet capture, and ss/netstat for local socket state |
Running stateful systems and moving data without losing it.
| Skill | What it does |
|---|---|
database-operations |
Covers the operational discipline of running databases in production — connection pooling and exhaustion, online schema changes, replication topology and read scaling, failover and promotion, and the runbook habits that keep an outage from becoming data loss |
backup-and-restore |
Defines the discipline of building backups you can actually restore under pressure — RPO-driven frequency, restores rehearsed on a schedule, offsite immutable copies, encryption, and treating a backup that has never been restored as equivalent to no backup at all |
data-migration |
Covers changing schema or data shape without downtime using expand-then-contract — adding new structures alongside old, backfilling historical data in batches, dual-writing during the transition, verifying both old and new code paths, and keeping every step independently reversible |
caching-strategies |
Covers caching correctly — deciding what is worth caching, choosing between cache-aside, write-through, and write-behind, setting TTLs from real staleness tolerance, invalidating on write instead of hoping a TTL catches it, and preventing thundering-herd stampedes on expiry |
stateful-workloads |
Covers running stateful systems — databases, queues, search indexes — on Kubernetes, including StatefulSets and stable identity, durable storage, backup and failover built into the platform rather than bolted on, and the tradeoff between self-managing a stateful service and paying for a managed one |
Building the paved roads that make the right way the easy way.
| Skill | What it does |
|---|---|
internal-developer-platform |
Designs an internal developer platform (IDP) as a product for one customer — engineers — with paved roads, self-service workflows, and abstractions that speed people up without hiding the levers they need during an incident |
developer-experience |
Cuts the friction between having an idea and seeing it running — fast local feedback loops, painless environment setup, and DORA-plus metrics that reveal where time actually goes |
service-catalog |
Builds and maintains a catalog of every service, its owner, and its scaffolding template so "who owns this" and "how do I start a new one" always have one authoritative answer |
self-service-infrastructure |
Lets developers provision databases, queues, and environments themselves through guardrailed templates instead of filing a ticket and waiting on a platform team |
golden-paths |
Curates the one opinionated, secure-and-observable-by-default way to build a service so the easy option and the right option are the same option |
Removing the repetitive, error-prone work humans should not be doing.
| Skill | What it does |
|---|---|
workflow-automation |
Covers automating multi-step operational workflows — event-driven triggers, orchestrating steps across systems, making every step idempotent and safely retryable, and keeping a human in the loop where judgment or blast radius demands it |
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 |
toil-reduction |
Covers finding and eliminating operational toil — measuring it honestly instead of by gut feel, automating the manual and repetitive, protecting a real automation budget against feature pressure, and telling toil apart from valuable work that just looks repetitive |
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 |
infrastructure-testing |
Covers testing infrastructure and config before it ships — validate-and-plan checks, policy enforcement, unit and integration tests for IaC modules, ephemeral test environments, and a testing pyramid sized for infrastructure |
Spending cloud money deliberately, not accidentally.
| Skill | What it does |
|---|---|
cost-optimization |
Cuts cloud spend without cutting reliability by finding the few levers that move most of the bill — idle and orphaned resources, over-committed on-demand spend that qualifies for reserved or savings-plan discounts, and oversized fleets — and going after them in dollar order |
resource-tagging |
Builds a tag taxonomy for cost, ownership, and automation, enforces it at provision time so it never depends on discipline after the fact, and uses it to drive cost allocation, showback, and the hunt for untagged waste |
rightsizing |
Matches compute, memory, and storage allocation to real measured usage instead of the guess made at launch time, sizing from percentiles rather than averages, and preferring autoscaling over a fixed size wherever demand varies |
cloud-budgeting |
Forecasts cloud spend from trend and known upcoming changes, sets budgets and alerts that fire before an overrun becomes a surprise invoice, catches anomalies early, and turns raw spend into unit economics and showback/chargeback that leadership can act on |
Making systems fast by measuring, not guessing.
| Skill | What it does |
|---|---|
performance-tuning |
Guides systematic performance work — measuring before changing, finding the actual bottleneck with the USE method (Utilization, Saturation, Errors), optimizing the real hot path, and verifying the fix moved the number that matters |
load-testing |
Tests a system under realistic traffic shapes to find its breaking point before users do — modeling real request mixes and ramp patterns, measuring latency percentiles and error rate together, and exercising the whole system instead of one endpoint in isolation |
profiling |
Finds where time, memory, and IO actually go inside a running system, using CPU and memory profilers, flame graphs, and the right choice between sampling and instrumentation, so optimization targets the real hot path instead of intuition |
scalability-design |
Designs systems to handle the next order of magnitude of load by removing state, shared contention, and single bottlenecks, and by choosing deliberately between horizontal and vertical scaling for each component |