How to use the GKE Alert Configuration agent skill

What the skill makes the agent do

When the skill is active, the agent follows guidance for building alerting policies that watch GKE clusters and workloads. The guidance covers latency, traffic, error rates, memory saturation and cluster health conditions such as CrashLoopBackOff and Node NotReady. The alerts are written in PromQL and Terraform and are built on native GKE metrics where possible, with a focus on low noise and cost awareness.

The skill also sets limits. It declines to create alerts for standalone Compute Engine VMs or standalone Cloud Run services without GKE, and it points you to standard Cloud Monitoring metrics for those cases.

• Latency (P95 response time)
• Errors, using Multi-Window Multi-Burn-Rate SLO alerts rather than simple static ratios
• Traffic, including sudden drops, missing metrics using absent() or default 0, and overload spikes
• Memory limit utilization
• Cluster health, such as CrashLoopBackOff and Node NotReady

Install the skill from the ZIP or the Claude apps

Download the ZIP of the skill from the page where you found it. Then choose one of two routes.

For Claude Code, unzip the folder into ~/.claude/skills/ to make it available to all of your projects, or into a project's .claude/skills/ folder to make it available only to that project. The skill folder contains SKILL.md at its top level, along with the references and scripts folders.

In the Claude apps, you can upload the skill instead. Open Settings, go to Capabilities, then Skills, and upload the skill there.

• Personal install: ~/.claude/skills/
• Project install: .claude/skills/ inside your project
• Claude apps: Settings → Capabilities → Skills

Check that you have the requirements

The skill assumes a specific setup. Before you rely on it, confirm the following. The skill needs Python 3 to run its validation script, Terraform to manage the alert policy resources, and a GKE cluster with Google Cloud Managed Service for Prometheus enabled.

If you want the agent to run gcloud commands, you also need a Google Cloud project and gcloud CLI access. The skill is not useful for teams that do not use Terraform or Managed Service for Prometheus, because its workflow assumes both.

• Python 3 (to run scripts/validate_config.py)
• Terraform (for the alert policy resources)
• A GKE cluster with Google Cloud Managed Service for Prometheus enabled
• A Google Cloud project and gcloud CLI access, if the agent runs gcloud commands

Trigger the skill with natural requests

You do not need a special command to use the skill. Describe what you want in plain language and mention GKE, Terraform or alerting. The agent decides when the skill applies based on your request.

Good requests name the workload or signal and the outcome you want. You can also ask the agent to review an existing PromQL alert before you deploy it. Requests about Compute Engine VMs or Cloud Run without GKE will not be handled by this skill and should be expected to be redirected.

• "Write Terraform alerts for the latency and error rate of my checkout service on GKE."
• "Add an alert for CrashLoopBackOff pods in the prod namespace."
• "Alert when a GKE node goes NotReady, using native metrics only."
• "Review this PromQL alert policy and check it for duplicates before I deploy it."

Understand the approval steps and file edits

When you ask for changes to Terraform files in a workspace, the skill follows three phases. First the agent drafts a change plan in a file called changes.json, listing policy names, PromQL expressions, grouping labels and durations. Then it runs the validation script on that plan. Only after the plan passes does it apply or merge the changes into your Terraform configuration, usually alerts.tf.

The validation script checks PromQL grammar, lookback windows, duration rules and whether any duplicate signals exist. You can run it yourself with the command below.

• Plan: draft changes.json
• Validate: run the script against the plan
• Execute: apply the changes to alerts.tf after validation passes

Know the cost rules for kube-state-metrics

Some alerts depend on kube-state-metrics (KSM), which is an open-source component. In Google Cloud Managed Service for Prometheus, KSM metrics create billable sample ingestion costs. The skill treats these as a Tier 2 dependency and stops to ask your permission before it writes or validates any Terraform for them.

The skill prefers Tier 1 native metrics, such as cAdvisor container metrics and kubelet and control-plane metrics, which carry no KSM cost surcharge. Every alert it proposes should be labelled with its tier and cost impact. If you approve KSM alerts, the skill recommends filtering or allowlisting only the metrics you need.

• Tier 1: GKE built-in, cAdvisor container_*, kubelet and control-plane metrics; no KSM surcharge
• Tier 2: KSM-dependent metrics such as kube_pod_status_phase or kube_deployment_*; needs your approval first

Safety notes: scripts and network

The skill runs a bundled Python script, scripts/validate_config.py, as part of its validation step. It does not use the network, according to the skill's own description. Review the script before you run the skill on sensitive repositories if your policy requires it.

The skill also asks the agent to tag gcloud commands it runs in the terminal with a usage attribution variable. The skill's references/attribution.md file explains the tag. It identifies only the skill, and the instructions say to set it inline on each command rather than with gcloud config set.

• Runs scripts: yes (scripts/validate_config.py)
• Uses network: no
• Terraform and gcloud changes are made only after the plan passes validation