Add Google Cloud Global Frontend Configuration agent skill.

skills/cloud/google-cloud-global-frontend-configuration/SKILL.md

@@ -0,0 +1,104 @@
+---
+name: google-cloud-global-frontend-configuration
+description: |
+  Guides agents through a structured 6-step discovery process to design and deploy Google Cloud Global External Application Load Balancers with Cloud CDN and Cloud Armor, mapping workload requirements to opinionated best-practice configurations.
+  Use when:
+  - Designing, configuring, or deploying a Google Cloud Global External Application Load Balancer, Cloud CDN, or Cloud Armor WAF.
+  - Discovering existing Google Cloud resources (GCS buckets, Compute Engine MIGs, GKE, Cloud Run) to use as load balancer backends.
+  - Generating production-grade Terraform HCL or gcloud CLI scripts for Global Load Balancer configurations.
+  - Actuating deployments via Infrastructure Manager or bash scripts, including performing IAM pre-checks.
+  - Detecting, analyzing, or reconciling configuration drift on deployed load balancers.
+  Don't use for:
+  - Non-GCP load balancing or security configurations.
+  - Purely regional or internal load balancing setups (unless part of a hybrid/failover global design).
+---
+
+# Google Cloud Global External Application Load Balancer Configuration Skill
+
+## Purpose & Agent Guidance
+
+This skill enables the agent to guide users through a structured, 6-step discovery process to design and deploy Google Cloud Global External Application Load Balancer architectures (incorporating Cloud CDN and Cloud Armor).
+
+When executing this skill, the agent must:
+- Map user workload requirements to simplified, opinionated best-practice configurations using actual Google Cloud product names.
+- Progressively disclose details, hiding advanced complexity unless the user explicitly asks for customization.
+- Leverage the reference documents in the `references/` directory to perform resource discovery, code generation, actuation, and drift detection.
+
+## The 6-Step Configuration Flow
+
+### Step 1: Basics
+*   **Project Discovery:** Consult `references/resource-discovery.md` to auto-detect the GCP Project ID. Present the discovered Project ID to the user.
+*   Ask the user for the foundational details of their load balancer:
+    *   **Name & Description:** What should we call this load balancer?
+    *   **Protocol Selection:** Do they need HTTP, HTTPS, or both?
+    *   **Certificate Management:** Do they want to use Google-managed certificates or bring their own existing certificates?
+
+### Step 2: Origin Configuration
+Help the user define their backend workloads through a strictly sequential, step-by-step loop. Do NOT ask everything at once. All steps are mandatory.
+
+*   **Sub-step A - Origin Setup:** Ask if they have a single origin or need multi-origin support. Wait for response.
+*   **Sub-step B - Origin Types:** Ask them to select the backend types from: Cloud Storage (GCS) Buckets, Compute Engine Managed Instance Groups (MIGs), Google Kubernetes Engine (GKE) Clusters, Cloud Run Services, or External/Internet origins (IP/FQDN). Wait for response.
+*   **Sub-step C - Origin Definition Loop:** Execute the following loop sequentially for EACH origin type selected in Sub-step B. Wait for the user to answer for one origin before asking about the next:
+    *   **Resource Discovery:** For Google Cloud-native origins (GCS, MIGs, GKE, Cloud Run), consult `references/resource-discovery.md` to fetch resources. Present the list starting with **1. Create New**, **2. NA**. For External/Internet origins, just ask for the FQDN/IP.
+    *   **Workload Type (CRITICAL):** Immediately after they define the resource, ask exactly what type of workload is being served:
+        1.  **Static Images / Objects** (Static content, images, videos, styling assets)
+        2.  **Cacheable API** (Read-only, public APIs where cached data is acceptable)
+        3.  **Uncacheable API / Transactions** (Transactional endpoints, login, checkout, account changes)
+        4.  **Dynamic Web (SSR)** (Dynamic pages, server-side rendered apps, custom dynamic sessions)
+*   **Sub-step D - Routing Rules:** Once ALL origins have been fully defined one by one, ask how traffic should be routed between them (Path-based, header-based, or query-param-based). Wait for response.
+*   **Sub-step E - Logging:** After routing is established, ask if they want to enable Cloud CDN logging, and if so, at what sampling rate (0-100%). Wait for response.
+
+### Step 3: Traffic Management
+*   Provide a brief summary of the origins and routing rules defined in Step 2.
+*   Ask if they need to enable Advanced Traffic Management settings (such as granular weighted load balancing), or if they want to proceed with **Google Cloud Best Practice Configuration**.
+
+### Step 4: Caching (Cloud CDN)
+Propose a "Recommended Configuration" based entirely on the Workload Type from Step 2. Do not list the advanced settings (TTL, Cache Keys, Compression) unless they reject the recommendation and want to customize.
+
+*   **If Workload = Static Images / Objects:**
+    *   Cache Mode: Cache All Static
+    *   TTL: Client (1 day), Default (30 days), Max (365 days)
+    *   Cache Key: Protocol + Host + Path (Ignore Query Strings)
+    *   Compression: Enabled (Brotli & Gzip)
+    *   Negative Caching: Enabled
+    *   Serve while stale: Enabled
+*   **If Workload = Cacheable API:**
+    *   Cache Mode: Use Origin Headers
+    *   TTL: Managed by Origin (Omitted from configuration to prevent errors)
+    *   Cache Key: Protocol + Host + Path + Include Query Strings
+    *   Compression: Enabled (Gzip)
+    *   Negative Caching: Enabled
+    *   Serve while stale: Disabled
+*   **If Workload = Uncacheable API / Transactions:**
+    *   Cache Mode: Disabled (CDN Bypassed)
+*   **If Workload = Dynamic Web (SSR):**
+    *   Cache Mode: Use Origin Headers
+    *   TTL: Managed by Origin (Omitted from configuration to prevent errors)
+    *   Cache Key: Protocol + Host + Path
+    *   Compression: Enabled (Brotli & Gzip)
+    *   Cache Bypass: Bypass cache if session cookies (e.g., SESSID, JWT) are present
+
+### Step 5: Security (Cloud Armor)
+Propose a "Recommended Configuration" based entirely on the Workload Type from Step 2. Keep advanced protection (Bot Management, Threat Intel, Geo-blocking) hidden unless requested.
+
+*   **If Workload = Static Images / Objects:**
+    *   Rate Limiting: None (Standard Edge behavior; rate limiting is unsupported on Cloud Armor Edge policies for GCS buckets).
+    *   OWASP Protection: Disabled
+*   **If Workload = Cacheable API:**
+    *   Rate Limiting: 100 requests per minute per client IP
+    *   OWASP Protection: Enabled (SQLi, XSS, Local File Inclusion)
+*   **If Workload = Uncacheable API / Transactions:**
+    *   Rate Limiting: Strict 30 requests per minute per client IP
+    *   OWASP Protection: Enabled (SQLi, XSS, Remote Command Execution, Session Fixation)
+    *   Bot Management & Threat Intel: Enabled (Block malicious bots and known malicious IPs)
+*   **If Workload = Dynamic Web (SSR):**
+    *   Rate Limiting: 120 requests per minute per client IP
+    *   OWASP Protection: Enabled (SQLi, XSS, CSRF, Shellshock)
+    *   Geo-blocking: Optional (Restrict/allow specific country access)
+
+### Step 6: Review & Deploy
+*   **Configuration Summary:** Generate a complete, formatted markdown table showing all finalized settings from Steps 1 through 5, using Google Cloud product names.
+*   **Next Action:** Ask the user to choose their deployment/generation format (Terraform HCL or gcloud CLI Bash Script) and their next action:
+    1.  **Show Code / Script** (Display the HCL code or gcloud bash script. Once displayed, offer options to **Download** or **Deploy/Execute**)
+    2.  **Download files** (Save `main.tf` or `deploy.sh` to the local workspace)
+    3.  **Deploy Configuration:** Initiate the deployment via Infrastructure Manager or execute the gcloud script. This should be done using the deployment instructions in `references/managed-deployment.md`.

skills/cloud/google-cloud-global-frontend-configuration/references/drift-detection.md

@@ -0,0 +1,58 @@
+# Google Cloud Global Load Balancer Drift Detection Guidelines
+
+This reference document details how to detect, analyze, and reconcile configuration drift in Google Cloud Global External Application Load Balancer infrastructure using Infrastructure Manager previews.
+
+---
+
+## Core Directives - Behavioral Rules
+
+1. **Safety First:** Never modify production infrastructure directly during drift detection. Always generate a **preview** first to safely inspect differences.
+2. **Reconciliation Options:** When drift is detected, always present the user with a clear, two-choice decision path:
+    *   **Option A (Reconcile to Code):** Overwrite manual changes by re-applying the Terraform configuration.
+    *   **Option B (Backport to Code):** Update the Terraform HCL code to match the manual changes made in the console.
+
+---
+
+## The Drift Detection Flow
+
+### Step 1: Generate Infrastructure Preview
+Create a preview using Infrastructure Manager to compare the deployed infrastructure against the local Terraform code.
+
+*   Run the preview command, passing the existing deployment name and the path to the local Terraform directory:
+    ```bash
+    gcloud infra-manager previews create {preview_name} \
+        --location={region} \
+        --local-source={path_to_tf_dir} \
+        --service-account={service_account_email} \
+        --deployment="projects/{project_id}/locations/{region}/deployments/{deployment_name}"
+    ```
+*   *Wait for the preview creation to complete successfully.*
+
+### Step 2: List Detected Drifts
+Query the generated preview to identify specific resources that have drifted.
+
+*   Run the command to list resource drifts:
+    ```bash
+    gcloud infra-manager resource-drifts list \
+        --preview="projects/{project_id}/locations/{region}/previews/{preview_name}"
+    ```
+*   Present the output list of drifted resources to the user in a clean, readable table format, detailing:
+    *   Resource Name & Type
+    *   Action (e.g., UPDATE, DELETE)
+    *   Drift Status (e.g., DRIFTED)
+
+### Step 3: Present Reconciliation Paths
+Analyze the list from Step 2 and present the two reconciliation options:
+
+*   **Option A: Overwrite and Re-align to Code**
+    *   Explain that this will revert all manual console changes and re-apply the local Terraform state.
+    *   Provide the command to re-apply the deployment (referencing `references/managed-deployment.md`):
+        ```bash
+        gcloud infra-manager deployments apply projects/{project_id}/locations/{region}/deployments/{deployment_name} \
+            --local-source={path_to_tf_dir} \
+            --service-account={service_account_email} \
+            --import-existing-resources
+        ```
+*   **Option B: Backport Console Changes to Code**
+    *   Explain that this will update their local Terraform files to reflect the manual changes made in the console, preserving them.
+    *   Detail the exact HCL changes they need to make to their `main.tf` based on the drift output.

skills/cloud/google-cloud-global-frontend-configuration/references/gcloud-generation.md

@@ -0,0 +1,139 @@
+# Google Cloud Global Load Balancer gcloud Script Generation Guidelines
+
+This reference document details how to generate robust, ordered, production-grade bash scripts containing `gcloud` CLI commands to deploy Google Cloud Global External Application Load Balancer architectures (incorporating Cloud CDN and Cloud Armor WAF) based on a design spec.
+
+---
+
+## Core Directives - Behavioral Rules
+
+1.  **Deterministic Command Ordering:** You must strictly follow the **Dependency Execution Order** below. Google Cloud resource creation has strict dependency trees; executing commands out of order will result in immediate deployment failures.
+2.  **Resource Prefixing:** You must prefix every created resource name with the environment variable `$ARCHITECTURE_NAME` to ensure global uniqueness and prevent 409 conflicts.
+3.  **Destruction Pairing (Mandatory):** For every script you generate, you MUST generate an accompanying destruction script (`destroy.sh`) that tears down the exact same resources in exact reverse dependency order.
+4.  **Error Handling (Strict Requirement):** You must include `set -e` (exit immediately on error) at the top of all generated scripts to prevent cascading failures if an intermediate command fails.
+
+---
+
+## Dependency Execution Order (The Creation Sequence)
+
+All `gcloud` commands must be ordered in this exact sequence in your output script:
+
+1.  **Variables & Setup:** Define environment variables (`ARCHITECTURE_NAME`, `PROJECT_ID`, `REGION`, etc.) and set the active project via `gcloud config set project`.
+2.  **Network Endpoint Groups (NEGs):** Create region/global NEGs if using Serverless or External origins.
+3.  **Cloud Armor Security Policies:** Create policies and rules.
+4.  **Backend Services & Buckets:** Create backends, configure CDN settings, and attach security policies.
+5.  **URL Maps:** Create the root URL map and attach backend services.
+6.  **Path & Host Rules:** Apply path matchers and routing rules to the URL map.
+7.  **Target Proxies:** Create HTTP/HTTPS target proxies, linking the URL map and certificates.
+8.  **Global Forwarding Rules:** Create the frontend forwarding rules, binding target proxies to public IPs.
+
+---
+
+## Workload Profile CLI Map (The Source of Truth)
+
+| Workload Type | CDN Flags | WAF Policy & Rules |
+| :--- | :--- | :--- |
+| **Static Images / Objects** | `--enable-cdn`<br>`--cache-mode=CACHE_ALL_STATIC`<br>`--default-ttl=2592000`<br>`--client-ttl=86400`<br>`--max-ttl=31536000` | None (Rate Limiting unsupported on CLOUD_ARMOR_EDGE) |
+| **Cacheable API**| `--enable-cdn`<br>`--cache-mode=USE_ORIGIN_HEADERS` | Rate limit (100 RPM) + OWASP rules (SQLi, XSS, LFI)<br>`--action=deny-403`<br>`--expression="evaluatePreconfiguredExpr('sqli-v33-stable') \|\| evaluatePreconfiguredExpr('xss-v33-stable')"` |
+| **Uncacheable API / Transactions**| `--no-enable-cdn` | Strict Rate limit (30 RPM) + OWASP rules + Bot Management/Threat Intel |
+| **Dynamic Web (SSR)** | `--enable-cdn`<br>`--cache-mode=USE_ORIGIN_HEADERS` | Rate limit (120 RPM) + OWASP rules (SQLi, XSS, CSRF) |
+
+---
+
+## Backend Reference Directory (Commands)
+
+### 1. Cloud Storage Buckets (GCS)
+```bash
+gcloud compute backend-buckets create "${ARCHITECTURE_NAME}-bucket-backend" \
+    --bucket-name="{bucket_name}" \
+    --enable-cdn \
+    --cache-mode="{cache_mode}" \
+    --default-ttl="{default_ttl}" \
+    --client-ttl="{client_ttl}" \
+    --max-ttl="{max_ttl}"
+```
+
+### 2. Cloud Run Services
+```bash
+# Create Serverless NEG
+gcloud compute network-endpoint-groups create "${ARCHITECTURE_NAME}-neg" \
+    --reference-neg-template \
+    --network-endpoint-type=serverless \
+    --region="{region}" \
+    --cloud-run-service="{service_name}"
+
+# Create Backend Service
+gcloud compute backend-services create "${ARCHITECTURE_NAME}-backend" \
+    --global \
+    --protocol=HTTP \
+    --security-policy="{security_policy_name}"
+
+# Add NEG to Backend
+gcloud compute backend-services add-backend "${ARCHITECTURE_NAME}-backend" \
+    --global \
+    --network-endpoint-group="${ARCHITECTURE_NAME}-neg" \
+    --network-endpoint-group-region="{region}"
+```
+
+### 3. Compute Engine MIGs
+```bash
+# Create Backend Service
+gcloud compute backend-services create "${ARCHITECTURE_NAME}-backend" \
+    --global \
+    --protocol=HTTP \
+    --security-policy="{security_policy_name}"
+
+# Add MIG to Backend
+gcloud compute backend-services add-backend "${ARCHITECTURE_NAME}-backend" \
+    --global \
+    --instance-group="{mig_name}" \
+    --instance-group-zone="{zone}"
+```
+
+### 4. GKE Clusters
+```bash
+# Create Backend Service
+gcloud compute backend-services create "${ARCHITECTURE_NAME}-backend" \
+    --global \
+    --protocol=HTTP \
+    --security-policy="{security_policy_name}"
+
+# Add GKE NEG to Backend
+gcloud compute backend-services add-backend "${ARCHITECTURE_NAME}-backend" \
+    --global \
+    --network-endpoint-group="{gke_neg_name}" \
+    --network-endpoint-group-zone="{zone}"
+```
+
+### 5. External / Internet Origins (IP/FQDN)
+```bash
+# Create Global NEG for External Origin
+gcloud compute network-endpoint-groups create "${ARCHITECTURE_NAME}-neg" \
+    --global \
+    --network-endpoint-type=internet-fqdn-port
+
+# Add Endpoint
+gcloud compute network-endpoints add "${ARCHITECTURE_NAME}-neg" \
+    --global \
+    --fqdn="{domain_name}" \
+    --port=443
+
+# Create Backend Service
+gcloud compute backend-services create "${ARCHITECTURE_NAME}-backend" \
+    --global \
+    --protocol=HTTPS \
+    --security-policy="{security_policy_name}"
+
+# Add NEG to Backend
+gcloud compute backend-services add-backend "${ARCHITECTURE_NAME}-backend" \
+    --global \
+    --network-endpoint-group="${ARCHITECTURE_NAME}-neg"
+```
+
+---
+
+## Script Assembly Workflow
+
+1.  **Define Header:** Set `set -e` and export the variables (`ARCHITECTURE_NAME`, `PROJECT_ID`, etc.).
+2.  **Generate Creation Block:** Assemble the commands sequentially following the **Dependency Execution Order** and utilizing the **Workload Profile CLI Map** and **Backend Reference Directory**.
+3.  **Generate Destruction Block:** Append or output a separate `destroy.sh` script that tears down the exact same resources in exact reverse dependency order.
+4.  **Output and Hand-off:** Present the scripts to the user. State the next action (Download Files or Deploy Configuration) and transition to `references/managed-deployment.md` (specifically Phase 2 Option B) to guide them through deployment execution.