← all publishers

arjunprabhulal

@arjunprabhulal source repo

Report this profile Claim this profile

• 88 skills
• 0 followers
• 6 hours ago last updated

1. ▌
   Containerization · arjunprabhulal bundle

   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. Use this whenever the user is writing a Dockerfile, mentions Docker or OCI images, image size or build times, or is preparing an application to run on Kubernetes. For orchestrating those images use `kubernetes-operations`; for scanning them use `image-scanning`.
   0 installs
2. ▌
   Progressive Delivery · arjunprabhulal

   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. Use this whenever the user wants automatic rollback on error-rate or latency regression, is defining an AnalysisTemplate or metric provider, asks about canary weight steps, or wants a rollout gated on real signals, not "wait ten minutes and ship." For the strategies automated use `deployment-strategies`; for the reconciler underneath use `argocd-operations`; for metrics queried use `metrics-and-monitoring`.
   0 installs
3. ▌
   Observability · arjunprabhulal

   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. Use this whenever the user asks why something broke with no warning, is deciding what to instrument before a service ships, is choosing between a metric, log, or trace, or asks what observability means beyond "we have dashboards." For metric mechanics use `metrics-and-monitoring`, for logs use `log-management`, for tracing use `distributed-tracing`.
   0 installs
4. ▌
   Compliance As Code · arjunprabhulal

   Turns compliance controls into executable, version-controlled checks with automated evidence collection, so audits become a query instead of a fire drill. Use this whenever the user is preparing for SOC 2, ISO 27001, or PCI audits, mapping controls to infrastructure, detecting drift from a compliance baseline, manually screenshotting settings for an auditor, or proving a control is enforced rather than just documented. For enforcing rules at deploy time use `policy-as-code`; for who has access to audited systems use `iam-access-management`.
   0 installs
5. ▌
   Secrets Management · arjunprabhulal bundle

   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. Use this whenever the user is hardcoding a password or token, asking how to store an API key, setting up a CI pipeline that needs credentials, configuring a secret store like Vault or a cloud KMS, or responding to a leaked secret. For who is allowed to fetch those secrets use `iam-access-management`; for scanning dependencies and images for other flaws use `vulnerability-management`.
   0 installs
6. ▌
   Configuration Management · arjunprabhulal

   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. Use this whenever the user is writing a playbook, cookbook, or manifest, debugging why a run isn't converging, organizing hosts into an inventory, or deciding whether a fleet should be config-managed or replaced wholesale. For replacing servers instead of mutating them use `immutable-infrastructure`, for provisioning the underlying resources use `infrastructure-as-code`.
   0 installs
7. ▌
   Immutable Infrastructure · arjunprabhulal

   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. Use this whenever the user is deciding whether to SSH into a running instance to fix it, building an AMI or container image as a deployment unit, debugging config drift on a long-lived server, or arguing for or against in-place patching. For hosts that must stay mutable use `configuration-management`, for image build mechanics use `containerization`.
   0 installs
8. ▌
   Log Management · arjunprabhulal

   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. Use this whenever the user is adding logging to a service, debugging why logs are unsearchable or too expensive to keep, designing log levels or a sampling strategy, or asking how to connect a log line back to its request. For the trace those IDs point into use `distributed-tracing`, and for the paging layer use `alerting`.
   0 installs
9. ▌
   Slo Definition · arjunprabhulal

   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. Use this whenever the user defines a service's reliability target, argues how reliable something "should" be, picks the metric an SLO is based on, or decides what happens when a budget runs out. For paging math on the budget use `alerting`, for day-to-day tracking use `error-budgets`.
   0 installs
10. ▌
    Well Architected Review · arjunprabhulal bundle

    Runs a structured audit against the standard pillars — reliability, security, cost, performance, operational excellence, sustainability — producing prioritized, actionable findings, not a checklist tick. Use this whenever the user asks for an architecture review, a well-architected assessment, a pre-launch readiness check, "is this built right," or wants pillar tradeoffs reconciled into a decision. For fixing one pillar in depth use `cost-optimization` or `disaster-recovery` directly — this is the cross-cutting audit that finds where to point them.
    0 installs
11. ▌
    Container Registry · arjunprabhulal

    Stores and distributes container images safely — tagging strategy, immutability, retention and garbage collection, access control, signing, and replication or pull-through caching. Use this whenever the user asks about registry setup, mutable versus immutable tags, cleaning up old images, who can push or pull, image signing or verification, or images being slow to pull across regions. For scanning image contents use `image-scanning`; for reducing what gets pushed use `image-optimization`.
    0 installs
12. ▌
    Image Optimization · arjunprabhulal

    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. Use this whenever the user complains an image is too large, a build or CI pipeline is slow, asks about distroless or scratch images, wants multi-architecture support, or wants to know what is actually inside a shipped image. For image structure and non-root users use `containerization`; for build-cache design in CI use `build-optimization`.
    0 installs
13. ▌
    Kubernetes Storage · arjunprabhulal

    Covers persistent data in the cluster — PersistentVolumes/Claims, StorageClasses and dynamic provisioning, access modes, StatefulSets, volume lifecycle, and reclaim policy so data survives rescheduling. Use this whenever the user is provisioning a PVC, choosing a StorageClass or access mode, running a stateful workload, or debugging a Pending PVC or stuck volume attach. For the database engine's own concerns use `database-operations`; for backup mechanics use `backup-and-restore`.
    0 installs
14. ▌
    Operators And Crds · arjunprabhulal

    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. Use this whenever the user is designing a CRD's schema, writing a controller's reconcile loop, or evaluating an off-the-shelf operator. For the RBAC an operator's service account needs use `kubernetes-security`; for storage an operator manages use `kubernetes-storage`.
    0 installs
15. ▌
    Capacity Planning · arjunprabhulal

    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. Use this whenever the user asks whether current infrastructure can handle projected growth, is planning for a known traffic spike or seasonal peak, sees resource utilization trending upward, or asks "when will we run out of X." For reacting to load automatically in real time use `autoscaling`, and for right-sizing what's already provisioned use `rightsizing`.
    0 installs
16. ▌
    Chaos Engineering · arjunprabhulal

    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. Use this whenever the user wants to run a game day, test resilience by killing pods or nodes, ask "what happens if this dependency goes down," or validate that a failover or circuit breaker actually works. For the drill that validates region/backup failover use `disaster-recovery`; for injecting load rather than failure use `load-testing`.
    0 installs
17. ▌
    Disaster Recovery · arjunprabhulal

    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. Use this whenever the user asks about disaster recovery, region failover, RTO or RPO, "what if we lost the whole database," or is designing for a failure bigger than a single pod. For live coordination once disaster strikes use `incident-response`; for backup/restore mechanics use `backup-and-restore`.
    0 installs
18. ▌
    Incident Response · arjunprabhulal bundle

    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`.
    0 installs
19. ▌
    Workflow Automation · arjunprabhulal

    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. Use this whenever the user wires up automation that reacts to an event, chains several operational steps together, decides whether an action can run unattended, or asks why a retried workflow left things in a bad state. For time-triggered work use `scheduled-jobs`, and for the scripts implementing individual steps use `scripting-automation`.
    0 installs
20. ▌
    Kubernetes Security · arjunprabhulal

    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. Use this whenever the user asks about RBAC roles, hardening pod security, writing an admission policy, or reducing what a compromised pod can do. For network isolation use `kubernetes-networking` and `multi-tenancy`; for image contents use `image-scanning`; for secret backends use `secrets-management`.
    0 installs
21. ▌
    Performance Tuning · arjunprabhulal bundle

    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. Use this whenever the user asks why something is slow, wants to make a service faster, or is about to tune JVM flags or database indexes without data. For finding the hot path itself use `profiling`, for generating load to test under use `load-testing`, and for designs where the bottleneck moves out use `scalability-design`.
    0 installs
22. ▌
    Scalability Design · arjunprabhulal

    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. Use this whenever the user is designing a new service for growth, asks whether an architecture will handle 10x traffic, is deciding between scaling out and scaling up, or hits a wall where adding more instances stops helping. For proving the design holds under real traffic use `load-testing`, and for provisioning the headroom over time use `capacity-planning`.
    0 installs
23. ▌
    On Call Management · arjunprabhulal

    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. Use this whenever the user is setting up or fixing an on-call rotation, mentions alert fatigue or burnout, is designing escalation policies, or asks how pages should route. For handling a page once it fires use `incident-response`; for reducing pages by fixing their cause use `alerting` and `toil-reduction`.
    0 installs
24. ▌
    Iam Access Management · arjunprabhulal

    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. Use this whenever the user is granting cloud or system access, designing IAM roles or policies, setting up break-glass procedures, reviewing who has access to what, or asking why a person or service still has a permission nobody remembers granting. For where the credentials themselves live use `secrets-management`; for enforcing identity-based access on the network itself use `zero-trust`.
    0 installs
25. ▌
    Supply Chain Security · arjunprabhulal

    Establishes trust in what you build and ship — SBOMs, build provenance, dependency pinning and verification, artifact signing, and signature verification before deploy. Use this whenever the user is asking what's inside their build, wants to pin or verify a dependency, is setting up artifact signing or SLSA provenance, is deciding whether to trust a third-party package, or is hardening a release pipeline against tampering. For patching what a scan finds use `vulnerability-management`; for the CI system producing these builds use `pipeline-security`.
    0 installs
26. ▌
    Scripting Automation · arjunprabhulal

    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 failed silently or left things half-changed, wants a `--dry-run` flag added, or is deciding whether a script should become a proper tool or service. For chaining scripts into a multi-step process use `workflow-automation`, and for running one on a schedule use `scheduled-jobs`.
    0 installs
27. ▌
    Service Connectivity · arjunprabhulal

    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. Use this whenever the user is setting retry or timeout policy, adding mTLS between services, debugging cascading failures from a slow dependency, connecting services across VPCs or clouds, or seeing an upstream overwhelmed by a retry storm. For the north-south API front door use `api-gateway`, and for a mesh implementing these patterns declaratively use `service-mesh`.
    0 installs
28. ▌
    Root Cause Analysis · arjunprabhulal

    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. Use this whenever the user is writing a postmortem, doing a retro after an outage, asking "why did this really happen," or an incident has been mitigated and needs a writeup. For running the incident itself use `incident-response`, and for turning findings into a tested procedure use `runbooks`.
    0 installs
29. ▌
    Kubernetes Networking · arjunprabhulal bundle

    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. Use this whenever the user asks why a Service has no endpoints, why a request 502s inside the cluster, how to expose an app externally, or how to write a NetworkPolicy. For readiness-driven endpoint removal use `kubernetes-operations`; for mTLS at L7 use `service-mesh`.
    0 installs
30. ▌
    Kubernetes Operations · arjunprabhulal bundle

    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. Use this whenever the user is debugging a pod that won't start or keeps restarting, tuning probes or resource limits, or planning a rollout or rollback. For Service/Ingress traffic issues use `kubernetes-networking`; for scaling policy use `autoscaling`.
    0 installs
31. ▌
    Infrastructure Testing · arjunprabhulal

    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. Use this whenever the user adds tests for Terraform or Kubernetes manifests, asks why a plan applied cleanly but broke production, wants a policy check to block a risky change, or is deciding what needs a full environment versus a fast local check. For the policy rules use `policy-as-code`, and for module structure use `terraform-modules`.
    0 installs
32. ▌
    Distributed Tracing · arjunprabhulal bundle

    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. Use this whenever the user debugs a slow request touching multiple services, instruments a service with OpenTelemetry or similar, asks why a trace has gaps, or decides what to sample when full tracing is too expensive. For metrics that flag a latency problem use `metrics-and-monitoring`, for one service's hot path use `profiling`.
    0 installs
33. ▌
    Golden Paths · arjunprabhulal

    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. Use this whenever the user creates a service template, standardizes how new services get built, decides what ships enabled by default (logging, tracing, auth), or debates letting every team choose its own stack. For where templates are registered and discovered use `service-catalog`; for how they're provisioned end to end use `self-service-infrastructure`; for the platform surface they live on use `internal-developer-platform`.
    0 installs
34. ▌
    Vulnerability Management · arjunprabhulal

    Finds, prioritizes, and closes out vulnerabilities across code, dependencies, images, and infrastructure without drowning the team in unactionable findings. Use this whenever the user is deciding what to patch first, has a scanner producing hundreds of CVEs, is setting patch SLAs, is asking whether a vulnerability is actually exploitable, or is building a remediation process. For the scanners that produce these findings use `security-scanning`; for trusting the artifacts you patch use `supply-chain-security`.
    0 installs
35. ▌
    Network Troubleshooting · arjunprabhulal bundle

    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. Use this whenever the user reports a connection timing out, refused, or intermittently failing, cannot tell whether DNS, routing, a firewall, or the application is at fault, or needs to prove exactly where a request is failing. For fixing DNS records once diagnosed use `dns-management`, and for policy fixes once isolated use `network-security`.
    0 installs
36. ▌
    Metrics And Monitoring · arjunprabhulal bundle

    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. Use this whenever the user is adding metrics to code, choosing a metric type, debugging a cardinality explosion or a slow metrics query, or deciding between pull and push collection. For turning metrics into paging rules use `alerting`, for visualizing them use `dashboards`, and for the broader signal strategy use `observability`.
    0 installs
37. ▌
    Service Catalog · arjunprabhulal

    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. Use this whenever the user sets up Backstage or a similar catalog, asks who owns a service during an incident, scaffolds a new service, audits for orphaned systems, or wires ownership metadata into paging and access control. For the templates it scaffolds from use `golden-paths`; for the platform it runs on use `internal-developer-platform`; for wiring ownership into paging use `on-call-management`.
    0 installs
38. ▌
    Developer Experience · arjunprabhulal

    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. Use this whenever the user complains local dev is slow or fragile, asks how to measure developer productivity, wants to reduce time-to-first-commit for new hires, or is deciding what toil to automate next. For the platform hosting these workflows use `internal-developer-platform`; for templates removing setup friction use `golden-paths`; for automating identified toil use `toil-reduction`.
    0 installs
39. ▌
    Internal Developer Platform · arjunprabhulal bundle

    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. Use this whenever the user is scoping a platform team's roadmap, deciding what to abstract versus expose, evaluating Backstage or a platform orchestrator, or arguing how much Kubernetes/Terraform detail developers should see. For what the platform hosts use `service-catalog`; for its templates use `golden-paths`; for measuring it use `developer-experience`.
    0 installs
40. ▌
    Self Service Infrastructure · arjunprabhulal

    Lets developers provision databases, queues, and environments themselves through guardrailed templates instead of filing a ticket and waiting on a platform team. Use this whenever the user designs a self-service provisioning flow, decides what needs manual approval versus auto-approval, replaces ticket-based infrastructure requests, or worries self-service will let someone provision something dangerous or expensive. For the IaC modules provisioned use `terraform-modules`; for the guardrail logic use `policy-as-code`; for the templates surfaced to developers use `golden-paths`.
    0 installs
41. ▌
    Gitops · arjunprabhulal

    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. Use this whenever the user designs a deployment repo layout, asks how environments should be promoted, debates config repo vs app repo, wants rollback to mean "revert a commit," or decides what belongs in Git versus a secret store. For the controller itself use `argocd-operations`; for canary mechanics use `progressive-delivery`; for building images use `ci-pipelines`.
    0 installs
42. ▌
    Cdn · arjunprabhulal

    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. Use this whenever the user is configuring a CDN, choosing cache-control headers, debugging stale or leaking cached content, setting up cache invalidation after a deploy, or deciding whether a response is safe to cache at all. For application-layer and database caching use `caching-strategies`, and for the origin's own load-balancing behavior use `load-balancing`.
    0 installs
43. ▌
    Serverless · arjunprabhulal

    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. Use this whenever the user is writing a Lambda/Cloud Function/Azure Function, designing an event-driven pipeline, debugging cold-start latency, hitting concurrency throttling, or asking whether to move a workload to serverless. For managed-vs-self-run tradeoffs use `cloud-architecture`; for containers use `kubernetes-operations`; for scheduled batch use `scheduled-jobs`.
    0 installs
44. ▌
    Multi Cloud · arjunprabhulal

    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. Use this whenever the user is considering a second provider, evaluating a portability layer like Kubernetes across clouds, discovering their stack already spans providers without a plan, or asking whether to abstract away managed services. For the shape within one provider use `cloud-architecture`; for moving a workload use `cloud-migration`.
    0 installs
45. ▌
    CI Pipelines · arjunprabhulal bundle

    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, adding a required status check, or asking how to structure test stages. For what happens after merge use `continuous-delivery`; for making the underlying build itself faster use `build-optimization`; for securing the pipeline's runners and permissions use `pipeline-security`.
    0 installs
46. ▌
    Rightsizing · arjunprabhulal

    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. Use this whenever the user asks whether an instance or fleet is oversized, wants to cut provisioned capacity, is picking an instance type, or is choosing between fixed capacity and autoscaling. For turning savings into a prioritized plan use `cost-optimization`, and for the commitment discounts that should follow a sized fleet use `cloud-budgeting`.
    0 installs
47. ▌
    Policy As Code · arjunprabhulal bundle

    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. Use this whenever the user is writing a Rego or Sentinel policy, adding an admission controller, wiring a policy check into a pipeline, or deciding whether a rule should be enforced or just audited. For the Terraform plan those policies gate use `infrastructure-as-code`, for Kubernetes-specific admission enforcement use `kubernetes-security`.
    0 installs
48. ▌
    Feature Flags · arjunprabhulal

    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. Use this whenever the user wants to gate a feature behind a flag, is asking about kill switches, needs to roll out a change gradually to a subset of users, or has accumulated stale flags nobody remembers the purpose of. For strategies that use flags as part of a rollout mechanism use `deployment-strategies`; for the broader deploy-vs-release distinction use `continuous-delivery`.
    0 installs
49. ▌
    Data Migration · arjunprabhulal bundle

    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. Use this whenever the user renames a column, changes a data type, moves data between tables, backfills a new field, or asks how to migrate without a maintenance window. For deploy sequencing of each phase use `deployment-strategies`, and for day-to-day database operations use `database-operations`.
    0 installs
50. ▌
    Zero Trust · arjunprabhulal

    Replaces network location with verified identity as the basis for access, removing implicit trust inside the perimeter via microsegmentation and continuous verification. Use this whenever the user assumes "inside the VPC" means trusted, wants access controls that follow identity rather than IP address, is planning a migration off perimeter-based security, or is limiting lateral movement after a compromised workload. For firewalls and segmentation use `network-security`; for the role model behind access decisions use `iam-access-management`.
    0 installs
51. ▌
    Runbooks · arjunprabhulal

    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. Use this whenever the user is documenting an operational procedure, writing a "what to do when X fires" doc, building an alert-to-action mapping, or complaining that on-call has to reverse-engineer fixes each time an alert repeats. For the live coordination during an active incident use `incident-response`, and for the improvised procedures that emerge in one-off outages use `root-cause-analysis` to turn them into a permanent runbook.
    0 installs
52. ▌
    Cloud Migration · arjunprabhulal

    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. Use this whenever the user is planning a cloud migration, choosing between rehost/replatform/refactor, designing a cutover plan, migrating a database to a new provider, or asking why a "simple" migration is stalling. For the target shape use `cloud-architecture`; for sync mechanics use `data-migration`; for running providers long-term use `multi-cloud`.
    0 installs
53. ▌
    Terraform Modules · arjunprabhulal

    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. Use this whenever the user is writing a new module, designing variables and outputs, deciding whether to nest modules, pinning a module source to a version, or debating whether shared logic should become a module yet. For state and plan discipline see `infrastructure-as-code`, for blocking bad module usage before apply use `policy-as-code`.
    0 installs
54. ▌
    Profiling · arjunprabhulal

    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. Use this whenever the user asks what's slow inside a specific process, wants to read or generate a flame graph, suspects a memory leak, or is about to optimize code without evidence of where the time goes. For deciding what to change once the hot path is known use `performance-tuning`, and for generating load to profile under use `load-testing`.
    0 installs
55. ▌
    Cloud Networking · arjunprabhulal

    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. Use this whenever the user is designing a VPC/VNet layout, planning subnet CIDR ranges, connecting two networks or a cloud to a data center, locking down egress, or debugging traffic that can't cross a network boundary. For DNS and load balancing use `dns-management`/`load-balancing`; for perimeter posture use `network-security`.
    0 installs
56. ▌
    Cloud Budgeting · arjunprabhulal

    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. Use this whenever the user asks for a spend forecast, wants a budget alert or anomaly detector, is building a showback or chargeback report, or asks what a feature or customer costs to run. For cutting the spend a budget flags as too high use `cost-optimization`, and for the tags budgets are sliced by use `resource-tagging`.
    0 installs
57. ▌
    Autoscaling · arjunprabhulal

    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. Use this whenever the user is configuring an HPA, deciding between HPA and VPA, debugging autoscaling that flaps, or sizing a cluster autoscaler. For the requests/limits autoscaling depends on use `kubernetes-operations`; for cost tradeoffs use `cost-optimization`.
    0 installs
58. ▌
    Helm Charts · arjunprabhulal

    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. Use this whenever the user is writing a Helm chart, designing a values.yaml hierarchy, debugging a failed `helm upgrade`, or deciding between Helm and Kustomize. For rollout mechanics on the cluster use `kubernetes-operations`; for GitOps delivery of charts use `gitops`.
    0 installs
59. ▌
    API Gateway · arjunprabhulal

    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. Use this whenever the user is designing an API entry point, adding rate limits or quotas, centralizing auth for several backend services, transforming a request between an external and internal contract, or debugging a gateway timeout. For east-west traffic between internal services use `service-connectivity`, and for token issuance details use `iam-access-management`.
    0 installs
60. ▌
    Alerting · arjunprabhulal

    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. Use this whenever the user is writing a new alert rule, asking why on-call is paged too often or missing real incidents, choosing an alert threshold, or designing severity routing. For the SLO the burn-rate math comes from use `slo-definition`, and for what a runbook should contain use `runbooks`.
    0 installs
61. ▌
    Pipeline Security · arjunprabhulal bundle

    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 a workflow file for security issues, or sets up cloud credentials for a deploy job. For scanning produced artifacts use `image-scanning`; for the wider software supply chain use `supply-chain-security`.
    0 installs
62. ▌
    Backup And Restore · arjunprabhulal

    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. Use this whenever the user sets up a backup job, chooses a retention policy, argues about RPO or RTO, asks whether current backups are enough, or plans for ransomware or accidental deletion. For the wider recovery plan use `disaster-recovery`, and for stateful platform durability use `stateful-workloads`.
    0 installs
63. ▌
    Caching Strategies · arjunprabhulal

    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. Use this whenever the user adds a cache layer, picks a TTL, debugs stale reads, sees a load spike on the database right after a cache miss, or asks whether something should be cached at all. For the database load a cache protects use `database-operations`, and for proving a cache is actually paying off use `load-testing`.
    0 installs
64. ▌
    Stateful Workloads · arjunprabhulal

    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. Use this whenever the user deploys a database or queue on Kubernetes, picks a StorageClass, debugs a pod that lost data on restart, or debates self-hosting versus managed. For volume mechanics use `kubernetes-storage`, and for restore discipline use `backup-and-restore`.
    0 installs
65. ▌
    Resource Tagging · arjunprabhulal

    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. Use this whenever the user is designing tag keys or naming conventions, asking who owns a resource or why a bill can't be attributed to a team, setting up cost allocation, or finding resources that escaped a tagging policy. For turning tags into dollar decisions use `cost-optimization`, and for the budgets tags feed into use `cloud-budgeting`.
    0 installs
66. ▌
    Service Mesh · arjunprabhulal

    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. Use this whenever the user asks whether they need a service mesh, is configuring mTLS or traffic-splitting rules, or is debugging sidecar-added latency. For basic Service/Ingress routing use `kubernetes-networking`; for canary rollout mechanics use `progressive-delivery`.
    0 installs
67. ▌
    Build Optimization · arjunprabhulal

    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 remote build cache, or is debugging a build that's fast but wrong. For caching inside a CI workflow use `ci-pipelines`; for shrinking the resulting image use `image-optimization`.
    0 installs
68. ▌
    Release Management · arjunprabhulal

    Coordinates what ships and when — semantic versioning, changelogs, release trains vs continuous release, and cutting a multi-service release safely. Use this whenever the user asks how to version a package, write release notes, cut a release, coordinate a release across services, or choose between shipping continuously versus on a schedule. For actually deploying a version use `continuous-delivery`; for how its bits are stored use `artifact-management`.
    0 installs
69. ▌
    Cloud Architecture · arjunprabhulal

    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. Use this whenever the user is choosing a region topology, deciding between a managed service and self-hosting, sketching a new system's compute and data layout, or asking why an architecture is expensive or fragile. For the virtual network layer use `cloud-networking`; for moving an existing workload use `cloud-migration`; for scoring an existing system use `well-architected-review`.
    0 installs
70. ▌
    Database Operations · arjunprabhulal

    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. Use this whenever the user is sizing a connection pool, adding an index to a live table, setting up read replicas, debugging replication lag, or planning a failover drill. For the step-by-step mechanics of a specific schema or data change use `data-migration`, and for restore testing use `backup-and-restore`.
    0 installs
71. ▌
    Cost Optimization · arjunprabhulal bundle

    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. Use this whenever the user asks how to reduce their cloud bill, reacts to a cost spike or a finance escalation, wants to find waste, or is deciding between on-demand, reserved, and spot pricing. For matching resource size to real usage use `rightsizing`, and for knowing who owns each dollar use `resource-tagging`.
    0 installs
72. ▌
    Argocd Operations · arjunprabhulal bundle

    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. Use this whenever the user mentions Argo CD, an Application stuck "Progressing" or "OutOfSync," app-of-apps or ApplicationSets, sync waves and hooks, or asks why a deploy shows synced but the workload is unhealthy. For the underlying model this tool implements use `gitops`; for automated canary analysis on top of it use `progressive-delivery`; for the workloads it manages use `kubernetes-operations`.
    0 installs
73. ▌
    Multi Tenancy · arjunprabhulal

    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. Use this whenever the user is onboarding a team onto a shared cluster, setting quotas per namespace, or debugging one tenant starving another's resources. For RBAC verbs and admission hardening use `kubernetes-security`; for isolation mechanics use `kubernetes-networking`.
    0 installs
74. ▌
    Dashboards · arjunprabhulal

    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. Use this whenever the user is building a new dashboard, asking why an existing one never gets used, deciding what panels a service needs, or reducing a sprawling dashboard down to something useful. For the metrics that fill the panels use `metrics-and-monitoring`, and for the paging layer that should point at these dashboards use `alerting`.
    0 installs
75. ▌
    Load Testing · arjunprabhulal

    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. Use this whenever the user wants to know how much traffic a system can handle, is preparing for a launch or seasonal peak, or is about to ship a change that affects throughput. For diagnosing why an endpoint is slow use `profiling`, and for sizing headroom from results use `capacity-planning`.
    0 installs
76. ▌
    Scheduled Jobs · arjunprabhulal bundle

    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 at all, is debugging a job that fired wrong after a DST change, or wants to know if a nightly job silently stopped. For the logic inside the job use `scripting-automation`, and for event-driven work instead of time-driven use `workflow-automation`.
    0 installs
77. ▌
    Toil Reduction · arjunprabhulal

    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. Use this whenever the user asks what to automate next, complains on-call is all manual tickets, wants to justify time spent on tooling over features, or is deciding whether a recurring task is worth eliminating. For the automation that replaces toil once found use `workflow-automation` or `scripting-automation`.
    0 installs
78. ▌
    Artifact Management · arjunprabhulal

    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 cleanup policy, or wants to trace where an artifact came from. For an image's contents and size use `image-optimization`; for vulnerability scanning use `image-scanning`.
    0 installs
79. ▌
    Continuous Delivery · arjunprabhulal

    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. Use this whenever the user is designing a deployment pipeline, asking how to ship changes faster, setting up dev/staging/prod promotion, or asking the difference between continuous delivery and deployment. For the merge signal that feeds this use `ci-pipelines`; for a single deploy's mechanics use `deployment-strategies`.
    0 installs
80. ▌
    Image Scanning · arjunprabhulal

    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. Use this whenever the user asks about CVEs, Trivy, Grype, or Snyk scans, wants a pipeline to block on critical vulnerabilities, is triaging a scan report, or asks if an image is safe to deploy. For fixing image structure use `containerization`; for the org-wide vulnerability program use `vulnerability-management`; for signing use `container-registry`.
    0 installs
81. ▌
    Dns Management · arjunprabhulal

    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. Use this whenever the user is planning a DNS cutover, choosing a TTL, debugging why a domain won't resolve after a change, setting up failover records, or separating internal and external resolution of the same zone. For diagnosing an active resolution failure step by step use `network-troubleshooting`, and for distributing traffic once DNS resolves use `load-balancing`.
    0 installs
82. ▌
    Load Balancing · arjunprabhulal

    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. Use this whenever the user is choosing a load balancer type, configuring health checks, picking round-robin versus least-connections, debugging uneven traffic distribution, or deciding whether sessions need to be sticky. For routing and auth at the application layer use `api-gateway`, and for balancing across pods inside a cluster use `kubernetes-networking`.
    0 installs
83. ▌
    Error Budgets · arjunprabhulal

    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. Use this whenever the user mentions error budgets, asks whether they can ship given recent reliability, or wants a release-freeze policy tied to reliability. For defining the SLO the budget derives from use `slo-definition`; for the live incident burning the budget use `incident-response`.
    0 installs
84. ▌
    Network Security · arjunprabhulal

    Protects traffic and boundaries through segmentation, default-deny rules, egress control, and TLS everywhere, minimizing what's actually reachable on the network. Use this whenever the user is configuring security groups or firewalls, designing network segmentation, asking why a service can reach something it shouldn't, setting up egress filtering, or enabling TLS between internal services. For identity-based access that replaces network location as the trust boundary use `zero-trust`; for Kubernetes-specific network policy and mesh use `kubernetes-networking`.
    0 installs
85. ▌
    Environment Management · arjunprabhulal

    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. Use this whenever the user provisions a new environment, sets up preview environments for pull requests, debugs a bug that only happens in prod, or decides what should differ between environments. For one module with per-environment values use `terraform-modules`, for gating risky promotions use `policy-as-code`.
    0 installs
86. ▌
    Infrastructure As Code · arjunprabhulal bundle

    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. Use this whenever the user is writing or reviewing Terraform, CloudFormation, or Pulumi code, applying infrastructure changes, managing remote state, or asking why an environment drifted from what's declared. For module design use `terraform-modules`, for blocking bad changes before apply use `policy-as-code`, for dev/staging/prod differences use `environment-management`.
    0 installs
87. ▌
    Security Scanning · arjunprabhulal

    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. Use this whenever the user is adding a security scanner to CI, choosing between SAST and DAST, deciding whether a scan should block a merge, tuning scanner noise, or complaining that a pipeline is full of findings nobody triages. For deciding what to do with the findings once they exist use `vulnerability-management`; for the pipeline infrastructure running these scans use `pipeline-security`.
    0 installs
88. ▌
    Deployment Strategies · arjunprabhulal

    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. Use this whenever the user asks how to deploy with zero downtime, wants a canary or blue-green setup, is worried about a risky rollout, or is planning a DB migration alongside a code deploy. For deciding whether to release deployed code at all use `feature-flags`; for a Kubernetes-native rollout use `progressive-delivery`.
    0 installs