[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6993DSBN53K1A2NEJCK3VD2":3,"skill-same:01M6993DSBN53K1A2NEJCK3VD2":101},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":16,"categories":17,"keywords":23,"publishedAt":46,"linkOnly":47,"markdownContent":48,"markdownBody":49,"frontMatter":50,"refName":37,"commitSha":55,"skillDirectory":56,"forksCount":57,"repositoryHtmlUrl":58,"repositoryHomepageUrl":6,"ownerHtmlUrl":59,"ownerBlogUrl":60,"ownerDescription":61,"updatedAt":62,"install":63,"resources":76},"01M6993DSBN53K1A2NEJCK3VD2","gke-alert-configuration",null,"Configures alerting policies in Terraform for Google Kubernetes Engine (GKE) clusters, workloads, and services using PromQL and Google Cloud Managed Service for Prometheus. Use when writing, analyzing, validating, or deploying Terraform alerting policies to monitor GKE service latency, traffic, error rates using Multi-Window Multi-Burn-Rate SLO alerts, memory saturation, and cluster health such as CrashLoopBackOff and Node NotReady conditions. Don't use for non-GKE compute runtimes such as standalone Compute Engine VMs or standalone Cloud Run services without GKE.","google\u002Fskills","google","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F1342004?v=4","01M698VYEFDM0VJBZDYYJ2T83S","Google","01M698WR0H76ENHE587T9EJT89",24122,"Apache-2.0","https:\u002F\u002Fgithub.com\u002Fgoogle\u002Fskills\u002Fblob\u002Fmain\u002Fskills\u002Fcloud\u002Fgke-alert-configuration\u002FSKILL.md",[18],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000011","运维与部署","SCENARIO","使用场景",[24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43,44,45,9],"gke alert configuration","gke","alert","configuration","saturation","when","managed","promql","standalone","traffic","Managed Service","error","alerts","main","writing","burn-rate","slo","alerting","memory","google cloud","kubernetes","github","2026-11-10 10:12:30",false,"---\nname: gke-alert-configuration\nmetadata:\n  version: \"1.0.3\"\n  category: CloudInfrastructure\n  canonical_source: https:\u002F\u002Fgithub.com\u002Fgoogle\u002Fskills\u002Ftree\u002Fmain\u002Fskills\u002Fcloud\u002Fgke-alert-configuration\ndescription: >-\n  Configures alerting policies in Terraform for Google Kubernetes Engine (GKE)\n  clusters, workloads, and services using PromQL and Google Cloud Managed Service\n  for Prometheus. Use when writing, analyzing, validating, or deploying Terraform\n  alerting policies to monitor GKE service latency, traffic, error rates using\n  Multi-Window Multi-Burn-Rate SLO alerts, memory saturation, and cluster health\n  such as CrashLoopBackOff and Node NotReady conditions.\n  Don't use for non-GKE compute runtimes such as standalone Compute Engine VMs or\n  standalone Cloud Run services without GKE.\n---\n\n# GKE Alert Configuration\n\nThis skill provides guidelines and best practices for creating robust,\nhigh-signal alerting policies for Google Kubernetes Engine workloads using\nGoogle Cloud Managed Service for Prometheus and Terraform. It ensures\ncomprehensive coverage of the **4 Golden Signals** and key cluster health\nmetrics while minimizing alert noise.\n\n--------------------------------------------------------------------------------\n\n## Attribution\n\n**MUST READ**: Before executing any `gcloud`, REST API, or MCP command, you\nMUST read [Usage Attribution](references\u002Fattribution.md). For commands executed\ndirectly in the terminal (never in generated scripts, Terraform, or user code),\nprefix `gcloud` with\n`CLOUDSDK_METRICS_REQUEST_ATTRIBUTION=\"agent-skills\u002F1.0 (skill:gke-alert-configuration)\"`\nand append `agent-skills\u002F1.0 (skill:gke-alert-configuration)` to `User-Agent` headers.\n\n## Critical Rules\n\n*   **Negative Triggers and Scope Redirection for Non-GKE Standalone Runtimes**:\n    *   This skill is strictly scoped to Google Kubernetes Engine (GKE)\n        workloads, clusters, and services using PromQL and Google Cloud Managed\n        Service for Prometheus.\n    *   **Do not use for non-GKE compute runtimes**, such as standalone Compute\n        Engine virtual machines or standalone Cloud Run services without GKE.\n    *   **STOP AND RESPOND DIRECTLY (Do Not Edit Files)**: When the user\n        requests alert configuration for non-GKE compute infrastructure:\n        1.  **Do not write, create, edit, or validate any Terraform files on\n            disk**.\n        2.  **Immediately stop and respond directly to the user in chat**:\n            *   **Explicitly Clarify Out-of-Scope**: State clearly that\n                standalone Compute Engine virtual machine monitoring or\n                standalone Cloud Run monitoring is out of scope for this\n                GKE-specific PromQL alerting skill, which is designed\n                specifically for GKE workloads using Google Cloud Managed\n                Service for Prometheus and PromQL.\n            *   **Do Not Generate GKE PromQL Alerts**: Do not create or generate\n                Kubernetes PromQL alert policies or fabricate Kubernetes\n                container, pod, or node resources for non-GKE infrastructure.\n            *   **Redirect the User**: Guide and redirect the user to standard\n                Google Cloud Monitoring metrics, such as\n                `compute.googleapis.com\u002Finstance\u002Fcpu\u002Futilization` or\n                `run.googleapis.com\u002Frequest_latencies`, using standard\n                `google_monitoring_alert_policy` with `condition_threshold` or\n                MQL, or recommend the relevant specialized Cloud observability\n                skill.\n*   **Mandatory `kube-state-metrics` (KSM) Cost Guardrail**:\n    *   Deploying open-source `kube-state-metrics` in Google Cloud Managed\n        Service for Prometheus incurs billable metric ingestion costs.\n    *   **STOP AND ASK PERMISSION FIRST (Do Not Edit Files)**: When a requested\n        alert rule relies on **Tier 2 KSM metrics** (such as `kube_cronjob_*`,\n        `kube_pod_status_phase`, `kube_persistentvolume_*`, `kube_deployment_*`,\n        `kube_statefulset_*`, `kube_job_*`, or `kube_daemonset_*`), **do not\n        write, create, edit, or validate any Terraform files or generate alert\n        policies before obtaining user approval**.\n    *   Instead, you **must immediately stop and respond directly to the user**\n        to:\n        1.  **Alert the user** that the requested alert requires\n            `kube-state-metrics`.\n        2.  **Explain the cost impact**: Detail that `kube-state-metrics` incurs\n            billable sample ingestion costs in Google Cloud Managed Service for\n            Prometheus.\n        3.  **Ask for explicit permission**: Ask the user for explicit\n            permission before assuming, enabling, or generating KSM-dependent\n            alert configurations.\n        4.  **Recommend filtering or allowlisting**: Suggest and recommend\n            filtering or allowlisting only the specific required metrics, such\n            as using a `PodMonitoring` resource with `metricRelabeling`\n            (`action: keep`) or KSM `--metric-allowlist` to minimize ingestion\n            costs. Provide a concrete allowlist example.\n    *   **Always prefer Non-KSM Native Alternatives** (Tier 1 cAdvisor or native\n        GKE metrics documented in\n        [metrics_and_alerts_catalog.md](references\u002Fmetrics_and_alerts_catalog.md))\n        whenever possible, such as using `container_memory_working_set_bytes`\n        and `container_spec_memory_limit_bytes` instead of\n        `kube_pod_container_resource_limits`.\n    *   **Explicit Tier and Cost Surcharge Identification in Response**: In\n        every response where you generate or recommend an alerting policy, you\n        **must explicitly state its classification tier and cost impact**:\n        *   **Tier 1 native or standard metric** (GKE built-in metrics, cAdvisor\n            `container_*`, kubelet volume stats, kubelet node conditions, and\n            control-plane metrics; see\n            [metrics_and_alerts_catalog.md](references\u002Fmetrics_and_alerts_catalog.md)):\n            State that it is a **Tier 1 native or standard metric with zero KSM\n            cost surcharge**.\n        *   **Tier 2 KSM metric**: State that it is a **Tier 2 KSM-dependent\n            metric** and follow the permission and allowlisting guardrail above.\n            *(Tip: Generally, metrics with the `kube_` prefix that represent\n            resource state or metadata belong to Tier 2).*\n*   **Plan-Validate-Execute Loop for Approved File Edits**: When modifying,\n    adding, or merging approved Terraform files on disk in a workspace, follow\n    the three-phase workflow:\n    1.  **Plan**: Draft a structured change plan (`changes.json`) containing\n        proposed policy resource names, PromQL expressions, grouping labels, and\n        durations.\n    2.  **Validate**: Run the pre-edit validation script (`python3\n        scripts\u002Fvalidate_config.py --plan changes.json`) to verify PromQL\n        grammar, lookback windows, duration rules, and ensure no duplicate\n        signals exist.\n    3.  **Execute**: After the plan passes validation, apply or merge changes\n        in-place into the target Terraform configuration (`alerts.tf`).\n    4.  *Note*: When answering questions or providing Terraform snippets\n        directly in chat where no disk modification is requested, output the\n        complete, valid Terraform HCL block in your response.\n*   **Configure the 4 Golden Signals and Cluster Health**: Always ensure the\n    target Kubernetes workload or service has the following alerting coverage:\n    1.  **Latency** (P95 response time)\n    2.  **Errors** (Multi-Window Multi-Burn-Rate SLO alerts, such as Fast Burn 1\n        hour \u002F 5 minutes with factor 14.4, Slow Burn 6 hours \u002F 30 minutes with\n        factor 6.0; do not use simple static ratios)\n    3.  **Traffic** (Sudden drop or complete metric disappearance using\n        `absent()` or `default 0` syntax, or overload spikes)\n    4.  **Saturation (Memory Limit Utilization Only)**: When describing or\n        configuring alert policies for a cluster or project, include ONLY\n        **Memory Saturation** (`container_memory_working_set_bytes` \u002F\n        `container_spec_memory_limit_bytes`). Do **NOT** include CPU saturation\n        alerts or list `container_cpu_usage_seconds_total` as an alert metric\n        because CPU is compressible and throttled by CFS quotas rather than\n        causing uncompressible fatal termination (OOM).\n    5.  **Cluster Health** (Pod CrashLooping, Node NotReady)\n*   **PromQL Only (Managed Prometheus)**: You must use\n    `condition_prometheus_query_language` with PromQL. Do **NOT** use MQL or\n    standard `condition_threshold` unless explicitly requested. Google Cloud\n    Managed Service for Prometheus is the standard telemetry ingestion path for\n    GKE.\n*   **Terraform Only**: Write the generated observability configuration ONLY as\n    Terraform (`.tf`) files, such as `alerts.tf` and `variables.tf`.\n*   **Dynamic Multi-Resource Alerting (No Hardcoding)**: You must not hardcode\n    specific pod names, node names, or service names in alerting conditions\n    unless explicitly requested. Alerting policies must be written to cover\n    resources dynamically:\n    *   Always use grouping aggregations (`by (cluster, namespace, service, pod,\n        container)`) instead of filtering to a single instance. This allows a\n        single alert policy to dynamically track each service or pod separately.\n    *   Always declare and use Terraform variables for `project_id`,\n        `cluster_name`, and `namespace` (`var.project_id`, `var.cluster_name`,\n        `var.namespace`) to make the configuration reusable across environments.\n        Always define these variables in `variables.tf` (or within the\n        configuration) and reference all three in policies or PromQL label\n        matchers.\n*   **No Redundant Duration Windows on Lookbacks**:\n    *   When PromQL expressions already use an aggregated lookback window (such\n        as `increase(...[15m]) > 3` or multi-window SLO burn rates), the query\n        time window already smooths out transient spikes.\n    *   Adding a Terraform duration on top of a PromQL lookback window increases\n        the Mean Time to Detect (MTTD) without providing additional smoothing\n        benefits.\n    *   In these cases, set Terraform `duration = \"0s\"` (or `\"60s\"`). Do not\n        enforce `duration = \"300s\"` on top of `[15m]`, which delays critical\n        crashloop alerts by up to 20 minutes total (15 minutes + 5 minutes).\n    *   Use `duration = \"300s\"` only on instantaneous gauge conditions, such as\n        `kube_node_status_condition == 0`.\n*   **Use SLO Burn Rates Instead of Simple Ratios**: For error rate alerting,\n    always generate Multi-Window Multi-Burn-Rate (MWMBR) SLO alerts (such as\n    14.4x burn rate over 1 hour and 5 minute windows for a 99% SLO) rather than\n    simple error rate ratios (`rate(5xx)\u002Frate(total) > 0.05`), which produce\n    excessive false alarms on low traffic.\n*   **Robust Traffic Drop Detection (`absent()` \u002F `default 0`)**: When\n    monitoring for traffic drops to zero, do not use `rate(...) == 0` alone\n    because Prometheus time series disappear completely when no requests occur\n    (evaluating to an empty vector rather than 0). Use `default 0` syntax, such\n    as `sum(rate(...[5m])) default 0 == 0`, or `absent(...) == 1`.\n*   **Notification Channels**: By default, never configure any notification\n    channels without user input. If the user explicitly provides a notification\n    channel, configure the alerts to use it. Otherwise, you must prompt the user\n    in your response to ask if they would like to configure one.\n*   **Consult GKE Metrics and Open-Source Alerts Catalog**: When designing or\n    generating evaluation suites or alerting policies, consult\n    [metrics_and_alerts_catalog.md](references\u002Fmetrics_and_alerts_catalog.md)\n    for public GKE metrics (`kubernetes.io\u002F`) and open-source Kubernetes alerts\n    (`awesome-prometheus-alerts`).\n*   **Plain English Response**: You must include a plain English explanation for\n    what the alerts do in your response. Explain what the alert measures, what\n    the threshold represents, and what a trigger indicates.\n*   **User Labels**: Include a `user_labels` block in all\n    `google_monitoring_alert_policy` resources to track policies created by this\n    skill:\n\n    ```terraform\n    user_labels = {\n      created-with-google-skill = \"gke-alert-configuration\"\n    }\n    ```\n\n--------------------------------------------------------------------------------\n\n## Alerting Policy Structure in Terraform\n\nAlerting policies must be defined using the `google_monitoring_alert_policy`\nresource with `condition_prometheus_query_language`. Always declare variables in\n`variables.tf` for `project_id`, `cluster_name`, and `namespace`.\n\n```hcl\n# variables.tf\nvariable \"project_id\" {\n  type        = string\n  description = \"Google Cloud Project ID\"\n}\n\nvariable \"cluster_name\" {\n  type        = string\n  description = \"GKE Cluster Name\"\n}\n\nvariable \"namespace\" {\n  type        = string\n  description = \"Target Kubernetes Namespace\"\n  default     = \"default\"\n}\n\nvariable \"slo_target\" {\n  type        = number\n  description = \"SLO Target fraction (for example 0.99 for 99%)\"\n  default     = 0.99\n}\n```\n\n```hcl\n# alerts.tf\n# Example: Multi-Window Multi-Burn-Rate (MWMBR) SLO Alert (Fast Burn: 14.4x, 1h & 5m windows)\nresource \"google_monitoring_alert_policy\" \"k8s_service_error_rate_slo\" {\n  project      = var.project_id\n  display_name = \"[K8s] ${var.cluster_name} - Service Error Rate SLO Fast Burn\"\n  combiner     = \"OR\"\n\n  conditions {\n    display_name = \"Error Budget Fast Burn (14.4x over 1h and 5m)\"\n    condition_prometheus_query_language {\n      query    = \u003C\u003C-EOT\n        (\n          (\n            sum(\n              rate(\n                http_requests_total{\n                  cluster=\"${var.cluster_name}\",\n                  namespace=\"${var.namespace}\",\n                  status=~\"5..\"\n                }[5m]\n              )\n            ) by (service, namespace, cluster)\n            \u002F\n            sum(\n              rate(\n                http_requests_total{\n                  cluster=\"${var.cluster_name}\",\n                  namespace=\"${var.namespace}\"\n                }[5m]\n              )\n            ) by (service, namespace, cluster)\n          ) > (1 - ${var.slo_target}) * 14.4\n        )\n        and\n        (\n          (\n            sum(\n              rate(\n                http_requests_total{\n                  cluster=\"${var.cluster_name}\",\n                  namespace=\"${var.namespace}\",\n                  status=~\"5..\"\n                }[1h]\n              )\n            ) by (service, namespace, cluster)\n            \u002F\n            sum(\n              rate(\n                http_requests_total{\n                  cluster=\"${var.cluster_name}\",\n                  namespace=\"${var.namespace}\"\n                }[1h]\n              )\n            ) by (service, namespace, cluster)\n          ) > (1 - ${var.slo_target}) * 14.4\n        )\n      EOT\n      duration = \"0s\"\n    }\n  }\n}\n```\n\n--------------------------------------------------------------------------------\n\n## Telemetry Metrics and PromQL Examples\n\nFor GKE metrics (`kubernetes.io\u002F`), community open-source alerts\n(`awesome-prometheus-alerts`), KSM cost guardrails, and non-KSM native\nalternatives, you must read and follow:\n\n*   [metrics_and_alerts_catalog.md](references\u002Fmetrics_and_alerts_catalog.md)\n\nFor specific PromQL queries corresponding to each of the Golden Signals, you\nmust read and follow:\n\n*   [promql_queries.md](references\u002Fpromql_queries.md)\n\nFor GKE cluster prerequisites, enabling Google Cloud Managed Service for\nPrometheus collection, configuring PodMonitoring custom scraping, and enabling\ncontrol plane metrics collection (API Server, Controller Manager, Scheduler),\nyou must read and follow:\n\n*   [gke_configuration_prerequisites.md](references\u002Fgke_configuration_prerequisites.md)\n\n--------------------------------------------------------------------------------\n\n## Tooling Scripts and Validation Loop\n\nUse the `validate_config.py` script to validate change plans and Terraform\nconfigurations when working in a repository:\n\n*   **Pre-Edit Plan Validation**: Draft a `changes.json` plan specifying the\n    proposed policies, queries, and durations, and validate it before editing:\n    *   Command: `python3 scripts\u002Fvalidate_config.py --plan changes.json`\n*   **Post-Edit and Directory Validation**: Scan existing or modified Terraform\n    files in a directory to ensure no duplicates or syntax errors exist:\n    *   Command: `python3 scripts\u002Fvalidate_config.py --directory [TARGET_TF_DIR]\n        --cluster-var \"${var.cluster_name}\"`\n    *   Single file validation: `python3 scripts\u002Fvalidate_config.py --file\n        [PATH_TO_TF_FILE]`\n\n--------------------------------------------------------------------------------\n\n## Technical Considerations and Gotchas\n\n*   **Lookback Windows versus Duration Buffers**:\n    *   Do not add large `duration = \"300s\"` buffers to alerts that already use\n        aggregated lookback windows like `increase(...[15m])` or multi-window\n        SLO rates.\n    *   The `[15m]` window in `increase(...[15m]) > 3` already smooths spikes.\n        Adding `duration = \"300s\"` increases MTTD by forcing the restart count\n        to remain above 3 for an extra 5 continuous minutes, delaying alerts by\n        up to 20 minutes total.\n    *   Use `duration = \"0s\"` or `\"60s\"` when using lookback window functions.\n        Reserve `duration = \"300s\"` for raw instantaneous gauge conditions, such\n        as `kube_node_status_condition == 0`.\n*   **Memory Saturation Only for Cluster Alerting**:\n    *   Do not configure CPU saturation alerts for cluster or workload\n        monitoring. CPU is compressible (throttled by the CFS scheduler), while\n        memory is uncompressible (triggers OOMKills).\n    *   Configure Memory Saturation using `container_memory_working_set_bytes` \u002F\n        `container_spec_memory_limit_bytes`.\n*   **Missing Resource Limits Blind Spot (Mandatory Explanation)**: Saturation\n    alerts that compare usage to limits (such as\n    `container_spec_memory_limit_bytes`) will **fail to resolve** or return\n    `NaN` if workloads do not have explicit Memory limits configured in their\n    Kubernetes manifests.\n    *   **Mandatory Instruction**: Whenever you generate, discuss, or recommend\n        any memory saturation alert comparing usage against limits (including\n        non-KSM cAdvisor alternatives using\n        `container_spec_memory_limit_bytes`), you **must explicitly explain and\n        warn the user in your response** that container memory limits must be\n        explicitly configured in the Kubernetes pod specs or manifests\n        (`resources.limits.memory`) for the saturation query to resolve (and not\n        return `NaN` or fail to resolve).\n*   **Linear Disk Predictions (`predict_linear`)**: When forecasting volume\n    exhaustion using\n    `predict_linear(kubelet_volume_stats_available_bytes[6h:5m], 4 * 24 * 3600)\n    \u003C 0`, explain that `predict_linear` uses linear regression over the recent\n    lookback window (for example, 6 hours) to project when available disk will\n    drop below 0 (for example, within 4 days). Identify\n    `kubelet_volume_stats_available_bytes` as a Tier 1 native kubelet metric\n    with zero KSM surcharge.\n*   **API Server Error and Client Metrics**:\n    *   `apiserver_request_total` and `rest_client_requests_total` are Tier 1\n        Control Plane metrics with zero KSM cost surcharge. Explain that\n        `apiserver_request_total` monitors 5xx HTTP error rates across API\n        server endpoints, while `rest_client_requests_total` monitors 4xx and\n        5xx requests sent by REST clients communicating with the API server.\n*   **Traffic Disappearance Gotcha (`absent()` \u002F `default 0`)**:\n    *   When traffic drops completely to zero, Prometheus and GMP stop emitting\n        the `http_requests_total` time series.\n    *   `sum(rate(...[5m])) == 0` evaluates to an empty vector, preventing the\n        alert from triggering.\n    *   Always use `sum(rate(...[5m])) default 0 == 0` or `absent(...) == 1` to\n        reliably detect total traffic loss.\n*   **CrashLooping versus Normal Restarts**: A container restarting occasionally\n    might be normal, for example job completion or a minor rolling update. Alert\n    on **frequent** restarts (such as more than 3 restarts in 15 minutes with\n    `duration = \"0s\"`) using `kube_pod_container_status_restarts_total` rather\n    than a single restart to avoid noise.\n*   **Node Upgrades**: During GKE cluster upgrades, nodes are drained and\n    restarted, which can trigger \"Node NotReady\" alerts. Warn the user that\n    these alerts might fire during maintenance windows, or suggest configuring\n    maintenance windows if supported.\n\n--------------------------------------------------------------------------------\n\n## Additional Resources\n\n*   [Google Cloud Managed Service for Prometheus Documentation](https:\u002F\u002Fdocs.cloud.google.com\u002Fstackdriver\u002Fdocs\u002Fmanaged-prometheus.md.txt)\n*   [GKE Observability and Monitoring Concepts](https:\u002F\u002Fdocs.cloud.google.com\u002Fkubernetes-engine\u002Fdocs\u002Fconcepts\u002Fobservability.md.txt)\n*   [Google Cloud Alerting Policies in Terraform](https:\u002F\u002Fdocs.cloud.google.com\u002Fmonitoring\u002Falerts\u002Fterraform.md.txt)\n*   [Google Cloud Monitoring Pricing](https:\u002F\u002Fcloud.google.com\u002Fproducts\u002Fobservability\u002Fpricing)\n*   [Google SRE Workbook: Alerting on SLOs](https:\u002F\u002Fsre.google\u002Fworkbook\u002Falerting-on-slos\u002F)\n*   [Awesome Prometheus Alerts Repository](https:\u002F\u002Fgithub.com\u002Fsamber\u002Fawesome-prometheus-alerts)\n","# GKE Alert Configuration\n\nThis skill provides guidelines and best practices for creating robust,\nhigh-signal alerting policies for Google Kubernetes Engine workloads using\nGoogle Cloud Managed Service for Prometheus and Terraform. It ensures\ncomprehensive coverage of the **4 Golden Signals** and key cluster health\nmetrics while minimizing alert noise.\n\n--------------------------------------------------------------------------------\n\n## Attribution\n\n**MUST READ**: Before executing any `gcloud`, REST API, or MCP command, you\nMUST read [Usage Attribution](references\u002Fattribution.md). For commands executed\ndirectly in the terminal (never in generated scripts, Terraform, or user code),\nprefix `gcloud` with\n`CLOUDSDK_METRICS_REQUEST_ATTRIBUTION=\"agent-skills\u002F1.0 (skill:gke-alert-configuration)\"`\nand append `agent-skills\u002F1.0 (skill:gke-alert-configuration)` to `User-Agent` headers.\n\n## Critical Rules\n\n*   **Negative Triggers and Scope Redirection for Non-GKE Standalone Runtimes**:\n    *   This skill is strictly scoped to Google Kubernetes Engine (GKE)\n        workloads, clusters, and services using PromQL and Google Cloud Managed\n        Service for Prometheus.\n    *   **Do not use for non-GKE compute runtimes**, such as standalone Compute\n        Engine virtual machines or standalone Cloud Run services without GKE.\n    *   **STOP AND RESPOND DIRECTLY (Do Not Edit Files)**: When the user\n        requests alert configuration for non-GKE compute infrastructure:\n        1.  **Do not write, create, edit, or validate any Terraform files on\n            disk**.\n        2.  **Immediately stop and respond directly to the user in chat**:\n            *   **Explicitly Clarify Out-of-Scope**: State clearly that\n                standalone Compute Engine virtual machine monitoring or\n                standalone Cloud Run monitoring is out of scope for this\n                GKE-specific PromQL alerting skill, which is designed\n                specifically for GKE workloads using Google Cloud Managed\n                Service for Prometheus and PromQL.\n            *   **Do Not Generate GKE PromQL Alerts**: Do not create or generate\n                Kubernetes PromQL alert policies or fabricate Kubernetes\n                container, pod, or node resources for non-GKE infrastructure.\n            *   **Redirect the User**: Guide and redirect the user to standard\n                Google Cloud Monitoring metrics, such as\n                `compute.googleapis.com\u002Finstance\u002Fcpu\u002Futilization` or\n                `run.googleapis.com\u002Frequest_latencies`, using standard\n                `google_monitoring_alert_policy` with `condition_threshold` or\n                MQL, or recommend the relevant specialized Cloud observability\n                skill.\n*   **Mandatory `kube-state-metrics` (KSM) Cost Guardrail**:\n    *   Deploying open-source `kube-state-metrics` in Google Cloud Managed\n        Service for Prometheus incurs billable metric ingestion costs.\n    *   **STOP AND ASK PERMISSION FIRST (Do Not Edit Files)**: When a requested\n        alert rule relies on **Tier 2 KSM metrics** (such as `kube_cronjob_*`,\n        `kube_pod_status_phase`, `kube_persistentvolume_*`, `kube_deployment_*`,\n        `kube_statefulset_*`, `kube_job_*`, or `kube_daemonset_*`), **do not\n        write, create, edit, or validate any Terraform files or generate alert\n        policies before obtaining user approval**.\n    *   Instead, you **must immediately stop and respond directly to the user**\n        to:\n        1.  **Alert the user** that the requested alert requires\n            `kube-state-metrics`.\n        2.  **Explain the cost impact**: Detail that `kube-state-metrics` incurs\n            billable sample ingestion costs in Google Cloud Managed Service for\n            Prometheus.\n        3.  **Ask for explicit permission**: Ask the user for explicit\n            permission before assuming, enabling, or generating KSM-dependent\n            alert configurations.\n        4.  **Recommend filtering or allowlisting**: Suggest and recommend\n            filtering or allowlisting only the specific required metrics, such\n            as using a `PodMonitoring` resource with `metricRelabeling`\n            (`action: keep`) or KSM `--metric-allowlist` to minimize ingestion\n            costs. Provide a concrete allowlist example.\n    *   **Always prefer Non-KSM Native Alternatives** (Tier 1 cAdvisor or native\n        GKE metrics documented in\n        [metrics_and_alerts_catalog.md](references\u002Fmetrics_and_alerts_catalog.md))\n        whenever possible, such as using `container_memory_working_set_bytes`\n        and `container_spec_memory_limit_bytes` instead of\n        `kube_pod_container_resource_limits`.\n    *   **Explicit Tier and Cost Surcharge Identification in Response**: In\n        every response where you generate or recommend an alerting policy, you\n        **must explicitly state its classification tier and cost impact**:\n        *   **Tier 1 native or standard metric** (GKE built-in metrics, cAdvisor\n            `container_*`, kubelet volume stats, kubelet node conditions, and\n            control-plane metrics; see\n            [metrics_and_alerts_catalog.md](references\u002Fmetrics_and_alerts_catalog.md)):\n            State that it is a **Tier 1 native or standard metric with zero KSM\n            cost surcharge**.\n        *   **Tier 2 KSM metric**: State that it is a **Tier 2 KSM-dependent\n            metric** and follow the permission and allowlisting guardrail above.\n            *(Tip: Generally, metrics with the `kube_` prefix that represent\n            resource state or metadata belong to Tier 2).*\n*   **Plan-Validate-Execute Loop for Approved File Edits**: When modifying,\n    adding, or merging approved Terraform files on disk in a workspace, follow\n    the three-phase workflow:\n    1.  **Plan**: Draft a structured change plan (`changes.json`) containing\n        proposed policy resource names, PromQL expressions, grouping labels, and\n        durations.\n    2.  **Validate**: Run the pre-edit validation script (`python3\n        scripts\u002Fvalidate_config.py --plan changes.json`) to verify PromQL\n        grammar, lookback windows, duration rules, and ensure no duplicate\n        signals exist.\n    3.  **Execute**: After the plan passes validation, apply or merge changes\n        in-place into the target Terraform configuration (`alerts.tf`).\n    4.  *Note*: When answering questions or providing Terraform snippets\n        directly in chat where no disk modification is requested, output the\n        complete, valid Terraform HCL block in your response.\n*   **Configure the 4 Golden Signals and Cluster Health**: Always ensure the\n    target Kubernetes workload or service has the following alerting coverage:\n    1.  **Latency** (P95 response time)\n    2.  **Errors** (Multi-Window Multi-Burn-Rate SLO alerts, such as Fast Burn 1\n        hour \u002F 5 minutes with factor 14.4, Slow Burn 6 hours \u002F 30 minutes with\n        factor 6.0; do not use simple static ratios)\n    3.  **Traffic** (Sudden drop or complete metric disappearance using\n        `absent()` or `default 0` syntax, or overload spikes)\n    4.  **Saturation (Memory Limit Utilization Only)**: When describing or\n        configuring alert policies for a cluster or project, include ONLY\n        **Memory Saturation** (`container_memory_working_set_bytes` \u002F\n        `container_spec_memory_limit_bytes`). Do **NOT** include CPU saturation\n        alerts or list `container_cpu_usage_seconds_total` as an alert metric\n        because CPU is compressible and throttled by CFS quotas rather than\n        causing uncompressible fatal termination (OOM).\n    5.  **Cluster Health** (Pod CrashLooping, Node NotReady)\n*   **PromQL Only (Managed Prometheus)**: You must use\n    `condition_prometheus_query_language` with PromQL. Do **NOT** use MQL or\n    standard `condition_threshold` unless explicitly requested. Google Cloud\n    Managed Service for Prometheus is the standard telemetry ingestion path for\n    GKE.\n*   **Terraform Only**: Write the generated observability configuration ONLY as\n    Terraform (`.tf`) files, such as `alerts.tf` and `variables.tf`.\n*   **Dynamic Multi-Resource Alerting (No Hardcoding)**: You must not hardcode\n    specific pod names, node names, or service names in alerting conditions\n    unless explicitly requested. Alerting policies must be written to cover\n    resources dynamically:\n    *   Always use grouping aggregations (`by (cluster, namespace, service, pod,\n        container)`) instead of filtering to a single instance. This allows a\n        single alert policy to dynamically track each service or pod separately.\n    *   Always declare and use Terraform variables for `project_id`,\n        `cluster_name`, and `namespace` (`var.project_id`, `var.cluster_name`,\n        `var.namespace`) to make the configuration reusable across environments.\n        Always define these variables in `variables.tf` (or within the\n        configuration) and reference all three in policies or PromQL label\n        matchers.\n*   **No Redundant Duration Windows on Lookbacks**:\n    *   When PromQL expressions already use an aggregated lookback window (such\n        as `increase(...[15m]) > 3` or multi-window SLO burn rates), the query\n        time window already smooths out transient spikes.\n    *   Adding a Terraform duration on top of a PromQL lookback window increases\n        the Mean Time to Detect (MTTD) without providing additional smoothing\n        benefits.\n    *   In these cases, set Terraform `duration = \"0s\"` (or `\"60s\"`). Do not\n        enforce `duration = \"300s\"` on top of `[15m]`, which delays critical\n        crashloop alerts by up to 20 minutes total (15 minutes + 5 minutes).\n    *   Use `duration = \"300s\"` only on instantaneous gauge conditions, such as\n        `kube_node_status_condition == 0`.\n*   **Use SLO Burn Rates Instead of Simple Ratios**: For error rate alerting,\n    always generate Multi-Window Multi-Burn-Rate (MWMBR) SLO alerts (such as\n    14.4x burn rate over 1 hour and 5 minute windows for a 99% SLO) rather than\n    simple error rate ratios (`rate(5xx)\u002Frate(total) > 0.05`), which produce\n    excessive false alarms on low traffic.\n*   **Robust Traffic Drop Detection (`absent()` \u002F `default 0`)**: When\n    monitoring for traffic drops to zero, do not use `rate(...) == 0` alone\n    because Prometheus time series disappear completely when no requests occur\n    (evaluating to an empty vector rather than 0). Use `default 0` syntax, such\n    as `sum(rate(...[5m])) default 0 == 0`, or `absent(...) == 1`.\n*   **Notification Channels**: By default, never configure any notification\n    channels without user input. If the user explicitly provides a notification\n    channel, configure the alerts to use it. Otherwise, you must prompt the user\n    in your response to ask if they would like to configure one.\n*   **Consult GKE Metrics and Open-Source Alerts Catalog**: When designing or\n    generating evaluation suites or alerting policies, consult\n    [metrics_and_alerts_catalog.md](references\u002Fmetrics_and_alerts_catalog.md)\n    for public GKE metrics (`kubernetes.io\u002F`) and open-source Kubernetes alerts\n    (`awesome-prometheus-alerts`).\n*   **Plain English Response**: You must include a plain English explanation for\n    what the alerts do in your response. Explain what the alert measures, what\n    the threshold represents, and what a trigger indicates.\n*   **User Labels**: Include a `user_labels` block in all\n    `google_monitoring_alert_policy` resources to track policies created by this\n    skill:\n\n    ```terraform\n    user_labels = {\n      created-with-google-skill = \"gke-alert-configuration\"\n    }\n    ```\n\n--------------------------------------------------------------------------------\n\n## Alerting Policy Structure in Terraform\n\nAlerting policies must be defined using the `google_monitoring_alert_policy`\nresource with `condition_prometheus_query_language`. Always declare variables in\n`variables.tf` for `project_id`, `cluster_name`, and `namespace`.\n\n```hcl\n# variables.tf\nvariable \"project_id\" {\n  type        = string\n  description = \"Google Cloud Project ID\"\n}\n\nvariable \"cluster_name\" {\n  type        = string\n  description = \"GKE Cluster Name\"\n}\n\nvariable \"namespace\" {\n  type        = string\n  description = \"Target Kubernetes Namespace\"\n  default     = \"default\"\n}\n\nvariable \"slo_target\" {\n  type        = number\n  description = \"SLO Target fraction (for example 0.99 for 99%)\"\n  default     = 0.99\n}\n```\n\n```hcl\n# alerts.tf\n# Example: Multi-Window Multi-Burn-Rate (MWMBR) SLO Alert (Fast Burn: 14.4x, 1h & 5m windows)\nresource \"google_monitoring_alert_policy\" \"k8s_service_error_rate_slo\" {\n  project      = var.project_id\n  display_name = \"[K8s] ${var.cluster_name} - Service Error Rate SLO Fast Burn\"\n  combiner     = \"OR\"\n\n  conditions {\n    display_name = \"Error Budget Fast Burn (14.4x over 1h and 5m)\"\n    condition_prometheus_query_language {\n      query    = \u003C\u003C-EOT\n        (\n          (\n            sum(\n              rate(\n                http_requests_total{\n                  cluster=\"${var.cluster_name}\",\n                  namespace=\"${var.namespace}\",\n                  status=~\"5..\"\n                }[5m]\n              )\n            ) by (service, namespace, cluster)\n            \u002F\n            sum(\n              rate(\n                http_requests_total{\n                  cluster=\"${var.cluster_name}\",\n                  namespace=\"${var.namespace}\"\n                }[5m]\n              )\n            ) by (service, namespace, cluster)\n          ) > (1 - ${var.slo_target}) * 14.4\n        )\n        and\n        (\n          (\n            sum(\n              rate(\n                http_requests_total{\n                  cluster=\"${var.cluster_name}\",\n                  namespace=\"${var.namespace}\",\n                  status=~\"5..\"\n                }[1h]\n              )\n            ) by (service, namespace, cluster)\n            \u002F\n            sum(\n              rate(\n                http_requests_total{\n                  cluster=\"${var.cluster_name}\",\n                  namespace=\"${var.namespace}\"\n                }[1h]\n              )\n            ) by (service, namespace, cluster)\n          ) > (1 - ${var.slo_target}) * 14.4\n        )\n      EOT\n      duration = \"0s\"\n    }\n  }\n}\n```\n\n--------------------------------------------------------------------------------\n\n## Telemetry Metrics and PromQL Examples\n\nFor GKE metrics (`kubernetes.io\u002F`), community open-source alerts\n(`awesome-prometheus-alerts`), KSM cost guardrails, and non-KSM native\nalternatives, you must read and follow:\n\n*   [metrics_and_alerts_catalog.md](references\u002Fmetrics_and_alerts_catalog.md)\n\nFor specific PromQL queries corresponding to each of the Golden Signals, you\nmust read and follow:\n\n*   [promql_queries.md](references\u002Fpromql_queries.md)\n\nFor GKE cluster prerequisites, enabling Google Cloud Managed Service for\nPrometheus collection, configuring PodMonitoring custom scraping, and enabling\ncontrol plane metrics collection (API Server, Controller Manager, Scheduler),\nyou must read and follow:\n\n*   [gke_configuration_prerequisites.md](references\u002Fgke_configuration_prerequisites.md)\n\n--------------------------------------------------------------------------------\n\n## Tooling Scripts and Validation Loop\n\nUse the `validate_config.py` script to validate change plans and Terraform\nconfigurations when working in a repository:\n\n*   **Pre-Edit Plan Validation**: Draft a `changes.json` plan specifying the\n    proposed policies, queries, and durations, and validate it before editing:\n    *   Command: `python3 scripts\u002Fvalidate_config.py --plan changes.json`\n*   **Post-Edit and Directory Validation**: Scan existing or modified Terraform\n    files in a directory to ensure no duplicates or syntax errors exist:\n    *   Command: `python3 scripts\u002Fvalidate_config.py --directory [TARGET_TF_DIR]\n        --cluster-var \"${var.cluster_name}\"`\n    *   Single file validation: `python3 scripts\u002Fvalidate_config.py --file\n        [PATH_TO_TF_FILE]`\n\n--------------------------------------------------------------------------------\n\n## Technical Considerations and Gotchas\n\n*   **Lookback Windows versus Duration Buffers**:\n    *   Do not add large `duration = \"300s\"` buffers to alerts that already use\n        aggregated lookback windows like `increase(...[15m])` or multi-window\n        SLO rates.\n    *   The `[15m]` window in `increase(...[15m]) > 3` already smooths spikes.\n        Adding `duration = \"300s\"` increases MTTD by forcing the restart count\n        to remain above 3 for an extra 5 continuous minutes, delaying alerts by\n        up to 20 minutes total.\n    *   Use `duration = \"0s\"` or `\"60s\"` when using lookback window functions.\n        Reserve `duration = \"300s\"` for raw instantaneous gauge conditions, such\n        as `kube_node_status_condition == 0`.\n*   **Memory Saturation Only for Cluster Alerting**:\n    *   Do not configure CPU saturation alerts for cluster or workload\n        monitoring. CPU is compressible (throttled by the CFS scheduler), while\n        memory is uncompressible (triggers OOMKills).\n    *   Configure Memory Saturation using `container_memory_working_set_bytes` \u002F\n        `container_spec_memory_limit_bytes`.\n*   **Missing Resource Limits Blind Spot (Mandatory Explanation)**: Saturation\n    alerts that compare usage to limits (such as\n    `container_spec_memory_limit_bytes`) will **fail to resolve** or return\n    `NaN` if workloads do not have explicit Memory limits configured in their\n    Kubernetes manifests.\n    *   **Mandatory Instruction**: Whenever you generate, discuss, or recommend\n        any memory saturation alert comparing usage against limits (including\n        non-KSM cAdvisor alternatives using\n        `container_spec_memory_limit_bytes`), you **must explicitly explain and\n        warn the user in your response** that container memory limits must be\n        explicitly configured in the Kubernetes pod specs or manifests\n        (`resources.limits.memory`) for the saturation query to resolve (and not\n        return `NaN` or fail to resolve).\n*   **Linear Disk Predictions (`predict_linear`)**: When forecasting volume\n    exhaustion using\n    `predict_linear(kubelet_volume_stats_available_bytes[6h:5m], 4 * 24 * 3600)\n    \u003C 0`, explain that `predict_linear` uses linear regression over the recent\n    lookback window (for example, 6 hours) to project when available disk will\n    drop below 0 (for example, within 4 days). Identify\n    `kubelet_volume_stats_available_bytes` as a Tier 1 native kubelet metric\n    with zero KSM surcharge.\n*   **API Server Error and Client Metrics**:\n    *   `apiserver_request_total` and `rest_client_requests_total` are Tier 1\n        Control Plane metrics with zero KSM cost surcharge. Explain that\n        `apiserver_request_total` monitors 5xx HTTP error rates across API\n        server endpoints, while `rest_client_requests_total` monitors 4xx and\n        5xx requests sent by REST clients communicating with the API server.\n*   **Traffic Disappearance Gotcha (`absent()` \u002F `default 0`)**:\n    *   When traffic drops completely to zero, Prometheus and GMP stop emitting\n        the `http_requests_total` time series.\n    *   `sum(rate(...[5m])) == 0` evaluates to an empty vector, preventing the\n        alert from triggering.\n    *   Always use `sum(rate(...[5m])) default 0 == 0` or `absent(...) == 1` to\n        reliably detect total traffic loss.\n*   **CrashLooping versus Normal Restarts**: A container restarting occasionally\n    might be normal, for example job completion or a minor rolling update. Alert\n    on **frequent** restarts (such as more than 3 restarts in 15 minutes with\n    `duration = \"0s\"`) using `kube_pod_container_status_restarts_total` rather\n    than a single restart to avoid noise.\n*   **Node Upgrades**: During GKE cluster upgrades, nodes are drained and\n    restarted, which can trigger \"Node NotReady\" alerts. Warn the user that\n    these alerts might fire during maintenance windows, or suggest configuring\n    maintenance windows if supported.\n\n--------------------------------------------------------------------------------\n\n## Additional Resources\n\n*   [Google Cloud Managed Service for Prometheus Documentation](https:\u002F\u002Fdocs.cloud.google.com\u002Fstackdriver\u002Fdocs\u002Fmanaged-prometheus.md.txt)\n*   [GKE Observability and Monitoring Concepts](https:\u002F\u002Fdocs.cloud.google.com\u002Fkubernetes-engine\u002Fdocs\u002Fconcepts\u002Fobservability.md.txt)\n*   [Google Cloud Alerting Policies in Terraform](https:\u002F\u002Fdocs.cloud.google.com\u002Fmonitoring\u002Falerts\u002Fterraform.md.txt)\n*   [Google Cloud Monitoring Pricing](https:\u002F\u002Fcloud.google.com\u002Fproducts\u002Fobservability\u002Fpricing)\n*   [Google SRE Workbook: Alerting on SLOs](https:\u002F\u002Fsre.google\u002Fworkbook\u002Falerting-on-slos\u002F)\n*   [Awesome Prometheus Alerts Repository](https:\u002F\u002Fgithub.com\u002Fsamber\u002Fawesome-prometheus-alerts)\n",{"name":5,"metadata":51,"description":7},{"version":52,"category":53,"canonical_source":54},"1.0.3","CloudInfrastructure","https:\u002F\u002Fgithub.com\u002Fgoogle\u002Fskills\u002Ftree\u002Fmain\u002Fskills\u002Fcloud\u002Fgke-alert-configuration","bb9b3f464aae37af360d079c1d863524955b0363","skills\u002Fcloud\u002Fgke-alert-configuration",2005,"https:\u002F\u002Fgithub.com\u002Fgoogle\u002Fskills","https:\u002F\u002Fgithub.com\u002Fgoogle","https:\u002F\u002Fopensource.google\u002F","Google ❤️ Open Source","2026-11-14 01:51:35",{"source":8,"skillName":5,"commands":64,"prompt":74,"zipAvailable":75},[65,68,71],{"tool":66,"command":67},"npx","npx skills add google\u002Fskills --skill gke-alert-configuration",{"tool":69,"command":70},"bunx","bunx skills add google\u002Fskills --skill gke-alert-configuration",{"tool":72,"command":73},"pnpm","pnpm dlx skills add google\u002Fskills --skill gke-alert-configuration","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fgoogle\u002Fskills\u002Fblob\u002Fmain\u002Fskills\u002Fcloud\u002Fgke-alert-configuration\u002FSKILL.md",true,[77,83,87,91,95],{"path":78,"resourceType":79,"resourceTypeDesc":80,"sizeBytes":81,"sourceHtmlUrl":82},"references\u002Fattribution.md","REFERENCE","参考文档",1909,"https:\u002F\u002Fgithub.com\u002Fgoogle\u002Fskills\u002Fblob\u002Fmain\u002Fskills\u002Fcloud\u002Fgke-alert-configuration\u002Freferences\u002Fattribution.md",{"path":84,"resourceType":79,"resourceTypeDesc":80,"sizeBytes":85,"sourceHtmlUrl":86},"references\u002Fgke_configuration_prerequisites.md",10823,"https:\u002F\u002Fgithub.com\u002Fgoogle\u002Fskills\u002Fblob\u002Fmain\u002Fskills\u002Fcloud\u002Fgke-alert-configuration\u002Freferences\u002Fgke_configuration_prerequisites.md",{"path":88,"resourceType":79,"resourceTypeDesc":80,"sizeBytes":89,"sourceHtmlUrl":90},"references\u002Fmetrics_and_alerts_catalog.md",25005,"https:\u002F\u002Fgithub.com\u002Fgoogle\u002Fskills\u002Fblob\u002Fmain\u002Fskills\u002Fcloud\u002Fgke-alert-configuration\u002Freferences\u002Fmetrics_and_alerts_catalog.md",{"path":92,"resourceType":79,"resourceTypeDesc":80,"sizeBytes":93,"sourceHtmlUrl":94},"references\u002Fpromql_queries.md",11906,"https:\u002F\u002Fgithub.com\u002Fgoogle\u002Fskills\u002Fblob\u002Fmain\u002Fskills\u002Fcloud\u002Fgke-alert-configuration\u002Freferences\u002Fpromql_queries.md",{"path":96,"resourceType":97,"resourceTypeDesc":98,"sizeBytes":99,"sourceHtmlUrl":100},"scripts\u002Fvalidate_config.py","SCRIPT","脚本",13265,"https:\u002F\u002Fgithub.com\u002Fgoogle\u002Fskills\u002Fblob\u002Fmain\u002Fskills\u002Fcloud\u002Fgke-alert-configuration\u002Fscripts\u002Fvalidate_config.py",[102,137,168,197,222,247],{"skillNo":103,"name":104,"nameZh":6,"description":105,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":106,"categories":107,"keywords":114,"publishedAt":46},"01M6998S2EZKD3GEJ7F943RZTE","sign-in-with-google-web","Implement, configure, and secure Sign In With Google (SiwG) using Google Identity Services (GIS \u002F `https:\u002F\u002Faccounts.google.com\u002Fgsi\u002Fclient`) across web architectures. Use when creating Google sign-in buttons, implementing Google One Tap with FedCM, integrating GIS in React\u002FNext.js\u002FAngular\u002FHTML, verifying ID tokens on backend runtimes (Python\u002FNode.js\u002FGo\u002FJava), enforcing Google Workspace domain restrictions (`hd`), securing client-side ID tokens via WebCrypto nonces or encrypted IndexedDB, embedding in cross-origin iframes via the Intermediate Iframe API (`https:\u002F\u002Faccounts.google.com\u002Fgsi\u002Fintermediate`), configuring Content Security Policy (CSP), COOP, and Permissions Policy (`identity-credentials-get`) headers, or handling sign-out and revocation. Don't use for legacy Google Sign-In (`gapi.auth2`), Google Cloud IAM service accounts, or Android\u002FiOS native Credential Manager.","https:\u002F\u002Fgithub.com\u002Fgoogle\u002Fskills\u002Fblob\u002Fmain\u002Fskills\u002Fidentity\u002Fsign-in-with-google-web\u002FSKILL.md",[108,111],{"categoryNo":109,"categoryName":110,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000009","前端开发",{"categoryNo":112,"categoryName":113,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000010","后端与接口",[9,115,116,117,118,119,120,121,122,43,123,124,125,126,127,128,129,130,131,132,133,134,135,136],"sign in with google web","sign","with","web","android","go","security","google workspace","implement","policy","python","implementing","react","iam","permissions","buttons","secure","manager","identity","architectures","domain","runtimes",{"skillNo":138,"name":139,"nameZh":6,"description":140,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":141,"categories":142,"keywords":152,"publishedAt":46},"01M6998PHPDCAD684VW5WRG83D","dpop-adoption","Implement and debug OAuth 2.0 DPoP (RFC 9449) refresh token sender-constraining for WebCrypto, Node.js ES6, and browser runtimes integrating with Google's OAuth platform. Use when configuring non-extractable asymmetric key pairs (P-256), generating DPoP Proof JWTs for authorization code exchange and token refresh, or handling 400 use_dpop_nonce challenge retry loops at oauth2.googleapis.com\u002Ftoken. Don't use for unconstrained OAuth 2.0 flows (where refresh tokens are not bound to a client key pair), or for Google Cloud IAM \u002F service account authentication.","https:\u002F\u002Fgithub.com\u002Fgoogle\u002Fskills\u002Fblob\u002Fmain\u002Fskills\u002Fidentity\u002Fdpop-adoption\u002FSKILL.md",[143,144,147],{"categoryNo":112,"categoryName":113,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":145,"categoryName":146,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000023","Skill与智能体开发",{"categoryNo":148,"categoryName":149,"taxonomyType":150,"taxonomyTypeDesc":151},"01JBSEEDCAT000000000000030","开发工程师","PROFESSION","适用职业",[153,154,9,43,155,156,157,158,159,160,128,161,162,163,164,165,166,133,136,167,29],"dpop adoption","adoption","es6","retry","authentication","flows","challenge","code","browser","loops","at","node","token","pair","platform",{"skillNo":169,"name":170,"nameZh":6,"description":171,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":172,"categories":173,"keywords":180,"publishedAt":46},"01M6998M72TC73EEAQH4XC7EXW","retrieving-developer-knowledge","Searches, retrieves, and synthesizes official Google developer documentation across Google Cloud, AI\u002FGemini, Android, Chrome, Web, Flutter, Go, Firebase, and other Google developer platforms. Integrates with the Developer Knowledge MCP server (search_documents, get_documents, answer_query) or the Developer Knowledge REST API fallback. Use when searching for gcloud CLI commands, API syntax, IAM permissions, official documentation, architectural comparisons, or product choice overviews. Don't use for local filesystem lookups or non-Google documentation.","https:\u002F\u002Fgithub.com\u002Fgoogle\u002Fskills\u002Fblob\u002Fmain\u002Fskills\u002Fdevelopers\u002Fretrieving-developer-knowledge\u002FSKILL.md",[174,175,178,179],{"categoryNo":112,"categoryName":113,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":176,"categoryName":177,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000021","资料检索与研究",{"categoryNo":145,"categoryName":146,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":148,"categoryName":149,"taxonomyType":150,"taxonomyTypeDesc":151},[181,182,183,184,43,185,186,187,188,189,190,191,192,29,193,194,195,128,196,129],"retrieving developer knowledge","knowledge","developer","MCP","mcp server","official","developer documentation","get","search","local","choice","documents","query","api","across","documentation",{"skillNo":198,"name":199,"nameZh":6,"description":200,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":201,"categories":202,"keywords":203,"publishedAt":46},"01M6998J2CZEXS9BES9S3WWFKC","migrate-to-rust","Clones, analyzes, plans, and migrates legacy codebases (C++, Fortran, Java, Python, C, Shell) from a GitHub URL or local directory to a modern, high-performance, deterministic, 100% Safe Rust architecture, tracking live telemetry across every task bucket, test failure\u002Ffix cycle, and Profile-Guided Optimization (PGO) stage, and producing a first-person AI storytelling report and interactive HTML infographic. Use when migrating a GitHub repository or local codebase to Rust, porting legacy C++, Fortran, Python, or Java workloads to memory-safe Rust, designing Struct-of-Arrays (SoA) or SIMD Rust architectures, or optimizing Rust ports with LLVM PGO. Don't use for unrelated non-Rust refactoring or single-line syntax questions.","https:\u002F\u002Fgithub.com\u002Fgoogle\u002Fskills\u002Fblob\u002Fmain\u002Fskills\u002Fdevelopers\u002Fmigrate-to-rust\u002FSKILL.md",[],[204,205,206,45,42,207,208,209,125,210,211,212,213,214,215,190,216,217,218,29,219,220,195,221],"migrate to rust","rust","migrate","performance","directory","safe","ports","llvm","soa","cycle","porting","fix","arrays","infographic","high-performance","URL","architecture","unrelated",{"skillNo":223,"name":224,"nameZh":6,"description":225,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":226,"categories":227,"keywords":231,"publishedAt":46},"01M6998GCC3K29WZ82KXMB9E02","finding-google-skills","Google platform decision and setup guidance, loaded on demand from Google's skill catalog. Use when a developer is choosing or setting up part of their stack, such as where to run a service, a database, storage, messaging, authentication, analytics, ads, or AI model serving, and a Google product is a reasonable candidate - whether or not a vendor is named - or when a request names a Google product or API. Brings in the matching Google skill so the answer can weigh Google options, their trade-offs, and when they are not the right fit. Skip when the stack is already settled on another provider and no Google product is named, or the task involves no platform choice.","https:\u002F\u002Fgithub.com\u002Fgoogle\u002Fskills\u002Fblob\u002Fmain\u002Fskills\u002Fdevelopers\u002Ffinding-google-skills\u002FSKILL.md",[228,229,230],{"categoryNo":112,"categoryName":113,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":145,"categoryName":146,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":148,"categoryName":149,"taxonomyType":150,"taxonomyTypeDesc":151},[9,232,233,234,235,167,236,237,238,239,240,157,241,242,243,191,244,245,29,246,194],"finding google skills","storage","as","messaging","model","trade-offs","provider","answer","fit","catalog","up","decision","use","database","candidate",{"skillNo":248,"name":249,"nameZh":6,"description":250,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":251,"categories":252,"keywords":255,"publishedAt":46},"01M6998DWNHTH0BS6W1CY8ZXMP","workload-manager-basics","Use this skill to manage Google Cloud Workload Manager evaluations, rules, scanned resources, and validation results by using public client libraries and the REST API. Use when you need to inspect workload best-practice rules, create and run evaluations for Google Cloud general best practices, SAP, SQL Server, or custom organizational rules, review violations, export results to BigQuery, or automate Workload Manager through client libraries because no service-specific public CLI or MCP server is available. Don't use for general Google Compute Engine instance management, VPC configuration, or standard IAM auditing.","https:\u002F\u002Fgithub.com\u002Fgoogle\u002Fskills\u002Fblob\u002Fmain\u002Fskills\u002Fcloud\u002Fworkload-manager-basics\u002FSKILL.md",[253,254],{"categoryNo":112,"categoryName":113,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":145,"categoryName":146,"taxonomyType":21,"taxonomyTypeDesc":22},[256,257,132,258,9,184,259,43,185,260,261,262,263,29,264,194,128,265,266,267,268],"workload manager basics","workload","basics","cli","review","vpc","resources","inspect","you","create","libraries","server","run"]