google-cloud-slo-alert-configuration

Files (5)

• SKILL.md
• app_hub_labels.md · references/
• attribution.md · references/
• promql_templates.md · references/
• service_metrics.md · references/

SKILL.md (first lines)

# SLO Alert Configuration Setup Wizard

This skill guides the user through a structured conversation to configure Cloud
Monitoring PromQL-based Service Level Objective (SLO) alerting policies on
Google Cloud in Terraform. Your
role is to act as a setup wizard that conceptually models the 4 key components
of an SLO API (Service Scope, Service Level, SLI, and Alert Condition), gathers
the requirements, and outputs a Terraform configuration.

## Attribution

**MUST READ**: Before executing any `gcloud`, REST API, or MCP command, you
MUST read [Usage Attribution](references/attribution.md). For commands executed
directly in the terminal (never in generated scripts, Terraform, or user code),
prefix `gcloud` with
`CLOUDSDK_METRICS_REQUEST_ATTRIBUTION="agent-skills/1.0 (skill:google-cloud-slo-alert-configuration)"`
and append `agent-skills/1.0 (skill:google-cloud-slo-alert-configuration)` to `User-Agent` headers.

## CRITICAL RULES

*   **Structured Conversation**: You **MUST** follow the 4-step wizard workflow
    below.

*   **Gather Missing Information**: Evaluate all 4 steps below first. Ask the
    user for all missing information across all steps in a single response.

    -   **DO NOT** stop after finding the first missing piece of information.

    -   **DO NOT** use the `ask_question` tool. You must ask questions using
        plain text in your response and end your turn to wait for the user to
        reply.

    -   **DO NOT** write the Terraform configuration if information is missing.

*   **Skip What Is Known**: If the user has already provided information for a
    step in their previous messages or initial prompt **DO NOT** ask them for
    it. Move to the next missing piece of information. If ALL information for
    Steps 1-4 is provided, call `write_to_file` to generate the Terraform
    configuration without asking for permission to proceed.

*   **Provide Best Practices**: Whenever you ask the user a question, you
    **MUST** explicitly state the recommended "Best Practice".

*   **Best Practice Shortcut**: If the user asks for "best practices" or
    similar, do not overwrite their explicit inputs. **SKIP** all remaining data
    gathering and keep any specific targets or custom metrics they provided. For
    all fields left blank, apply the recommended defaults defined in the "SRE
    Best Practice Suggestion" of each step.

*   **User Labels**: Include a `user_labels` block in all
    `google_monitoring_alert_policy` resources to track policies created by this
    skill:

    ```terraform
    user_labels = {
      created-with-google-skill = "google-cloud-slo-alert-configuration"
    }
    ```

*   **Terraform Output**: Write the generated observability configuration ONLY
    as Terraform (`.tf`) files using the `google_monitoring_alert_policy`
    resource and `condition_prometheus_query_language` resources.

*   **Alert Strategy**: **ALWAYS** include an `alert_strategy` block with an
    `auto_close` setting. Leave `notification_channels` empty unless the user
    provides one. Provide plain-English explanations of the PromQL math before
    finalizing the conversation.

--------------------------------------------------------------------------------

## SETUP WIZARD WORKFLOW

### Step 1: Define `ServiceScope`

1.  **Check Context**: Identify target resource, service, workload, or
    application the user wants to monitor. If you already know, proceed.
    Otherwise ask the user to identify it.

2.  **Autonomous Investigation**: If the user specified a project or general
    service name without providing specifics, autonomously use `gcloud` to
    discover the target services in their environment. If multiple services or
    workloads are discovered, list all of them and suggest applying SLO **ONLY**
    to the most critical backend services as a best practice.

    If you struggle to identify potential resources, ask the user to specify.

3.  **Identify Underlying Infrastructure**: To resolve the correct PromQL
    metric, you **MUST** know the underlying Google Cloud resource type.

    *   If the user only provides a logical name or an App Hub Service/Workload
        name such as `projects/.../services/frontend` or
        `projects/.../workloads/backend`, you still need to know the underlying
        infrastructure.
    *   If the prompt provides the underlying infrastructure, use that
        information. Do **NOT** attempt to discover it.
    *   If you don't know the underlying infrastructure but have a resource
        identified, you **MUST** proactively use `gcloud` to discover the
        infrastructure. If you struggle to identify the resource type, ask the
        user to specify.

4.  **Label Scoping**:

    *   If the user explicitly mentions the resource is in App Hub or provides
        an App Hub URI like `projects/.../locations/.../applications/...`, use
        App Hub labels and consult `references/app_hub_labels.md` to identify
        the correct group-by fields.
    *   Otherwise, assume it is a standard Google Cloud resource and use
        standard grouping labels such as `project_id, location, service_name`
        for Cloud Run.

    Example gcloud commands:

    -   `gcloud --quiet apphub applications services list --application=-
        --location=-`
    -   `gcloud --quiet apphub applications workloads list --application=-
        --location=-`
    -   `gcloud --quiet asset search-all-resources`
    -   `gcloud --quiet run services list`
    -   `gcloud --quiet apphub applications services describe <service>

From google/skills, Apache-2.0.

More from google/skills