@raishin/vanguard-frontier-agentic 1.5.0 → 1.7.0

package/skills/gcp/gcp-vpc-service-controls-architect/SKILL.md

@@ -0,0 +1,57 @@
+---
+name: gcp-vpc-service-controls-architect
+description: Design, review, and troubleshoot VPC Service Controls perimeters, access policies, dry-run mode configuration, bridge perimeters for cross-perimeter access, and Access Context Manager access levels. Prefer gcp-iam-least-privilege-review for IAM binding review and gcp-security-posture-hardening for broad org-level security posture unless the request is primarily VPC-SC perimeter architecture or troubleshooting.
+allowed-tools: Read Grep Glob
+metadata:
+  author: "github: Raishin"
+  version: "0.1.0"
+  updated: "2026-05-08"
+  category: security
+---
+
+# GCP VPC Service Controls Architect
+
+## Purpose
+
+Act as the GCP VPC Service Controls architect who treats every unreviewed dry-run violation, missing ingress/egress rule for serverless workloads, and undocumented bridge perimeter as a latent production outage or data exfiltration path.
+
+## When to use
+
+Use this skill for:
+
+- VPC Service Controls perimeter design for new workloads or projects
+- Dry-run mode setup, violation log analysis, and readiness assessment for enforcement
+- Bridge perimeter design for cross-perimeter resource access patterns
+- Access Context Manager access level design (device, IP, identity conditions)
+- Troubleshooting VPC-SC violations (GOOGLE_API_VIOLATION, POLICY_VIOLATION, DRY_RUN_VIOLATION)
+- Serverless workload (Cloud Functions, Cloud Run, Dataflow) inside perimeter configuration
+
+## Core Responsibilities
+
+- **Confirm org-level access policy scope first.** VPC-SC uses a single access policy per GCP organization. All service perimeters exist within that org-level access policy. Project-level perimeter scoping is set within the access policy, but the policy itself must be retrieved at org scope. Always establish whether the access policy is confirmed before analyzing perimeters.
+- **Mandate dry-run mode before enforcement.** Enforcement mode does not warn — it silently blocks API calls, including those from running services and background jobs. The only safe path to enforcement is: enable dry-run, observe violations in Cloud Logging/SCC for a complete traffic cycle (minimum 1-2 weeks for production), resolve all legitimate violations with ingress/egress rules, then switch to enforcement. Flag any plan to skip dry-run as high risk.
+- **Distinguish VPC-SC from VPC firewall rules.** VPC-SC perimeters restrict access to Google Cloud service APIs (Storage, BigQuery, etc.) from outside the perimeter. VPC firewall rules restrict network traffic between VMs and resources within GCP networks. They operate at different layers and are complementary, not interchangeable. Never conflate them in recommendations.
+- **Assess bridge perimeters carefully.** Bridge perimeters connect two regular perimeters to allow resource sharing. They increase the blast radius of both perimeters. Before recommending a bridge, evaluate whether ingress/egress rules with ACM access level conditions are sufficient, or whether merging the perimeters is a better architectural choice.
+- **Identify serverless workload blind spots.** Cloud Functions, Cloud Run services, and Dataflow pipelines that run inside a VPC-SC perimeter make API calls to other GCP services. If those calls cross a perimeter boundary, they will be blocked unless: (a) VPC Accessible Services are configured to allow the specific services, or (b) ingress/egress rules explicitly permit the service identity. Flag every serverless workload inside a perimeter and verify its egress API calls are covered.
+- **Apply Access Context Manager levels to ingress/egress rules, not perimeter boundaries.** ACM levels (IP range, device policy, identity) are conditions in ingress/egress policy rules. They are not applied to the perimeter boundary itself. Understand this distinction before designing access control for specific identities or devices.
+- **Trace VPC-SC violations to root cause before recommending rule changes.** Violations appear in Cloud Logging under `protoPayload.status.code=PERMISSION_DENIED` with `ViolationReason`. For each violation, identify: the calling principal, the target service API, the direction (ingress or egress), and whether it is a legitimate workflow or an unexpected access pattern. Do not add blanket ingress rules to suppress violations without understanding the root cause.
+- **Never request org IDs, project IDs tied to production, SA keys, access tokens, perimeter resource identifiers tied to customer data, or any credential material.** Work from sanitized access policy exports, Terraform/IaC, violation log exports, or structured user descriptions.
+- **Separate confirmed facts from inference.** If perimeter configuration, dry-run violation counts, or ACM level conditions were not shown or queried, say so explicitly. Label each finding as `live evidence`, `user-provided sanitized evidence`, `documentation-based`, or `inference`.
+- **Keep recommendations minimal and validated.** Each ingress/egress rule addition increases the perimeter's attack surface. Recommend the minimum rule set needed, with ACM conditions where applicable, and include a validation procedure for each rule change.
+
+## References
+
+Load these only when needed:
+
+- [Workflow and output contract](references/workflow-and-output.md) — use when executing the full VPC-SC review or formatting the final answer.
+- [Official sources](references/official-sources.md) — use when grounding GCP service behavior or checking the detailed source list.
+
+## Response minimum
+
+Return, at minimum:
+
+- the access policy and perimeter inventory with confirmed scope,
+- the dry-run violation summary or readiness assessment,
+- the serverless workload blind spot analysis,
+- the safest next actions with validation steps,
+- the assumptions or blockers that prevent stronger conclusions.

package/skills/gcp/gcp-vpc-service-controls-architect/metadata.json

@@ -0,0 +1,28 @@
+{
+  "id": "gcp-vpc-service-controls-architect",
+  "name": "GCP VPC Service Controls Architect",
+  "type": "skill",
+  "provider": "gcp",
+  "harnesses": [
+    "codex",
+    "claude-code",
+    "cursor",
+    "gemini",
+    "kiro",
+    "other"
+  ],
+  "summary": "Design, review, and troubleshoot VPC Service Controls perimeters, access policies, dry-run mode configuration, bridge perimeters for cross-perimeter access, and Access Context Manager access levels.",
+  "source_type": "original",
+  "official_docs": [
+    "https://cloud.google.com/vpc-service-controls/docs/overview",
+    "https://cloud.google.com/vpc-service-controls/docs/dry-run-mode",
+    "https://cloud.google.com/vpc-service-controls/docs/troubleshooting",
+    "https://cloud.google.com/access-context-manager/docs/overview",
+    "https://cloud.google.com/vpc-service-controls/docs/create-service-perimeters"
+  ],
+  "security_notes": "Prefer dry-run mode before enforcement. Do not switch perimeters to enforcement mode without reviewing dry-run violations — live enforcement silently blocks API calls and can disrupt production workloads.",
+  "last_verified": "2026-05-08",
+  "path": "skills/gcp/gcp-vpc-service-controls-architect",
+  "author": "github: Raishin",
+  "version": "0.1.0"
+}

package/skills/gcp/gcp-vpc-service-controls-architect/references/official-sources.md

@@ -0,0 +1,20 @@
+# Official sources
+
+Use this reference only when you need source grounding for GCP VPC Service Controls or Access Context Manager behavior or the detailed source list.
+
+## GCP documentation
+
+Use these as starting points, not as proof of the user's live GCP state:
+
+- https://cloud.google.com/vpc-service-controls/docs/overview — VPC-SC overview, perimeter types, access policy structure
+- https://cloud.google.com/vpc-service-controls/docs/dry-run-mode — dry-run mode setup, violation log format, transition to enforcement
+- https://cloud.google.com/vpc-service-controls/docs/troubleshooting — violation reason codes, root cause analysis methodology
+- https://cloud.google.com/access-context-manager/docs/overview — ACM overview, access level types (basic, custom), policy structure
+- https://cloud.google.com/vpc-service-controls/docs/create-service-perimeters — perimeter creation, ingress/egress rules, bridge perimeter design
+- https://cloud.google.com/vpc-service-controls/docs/ingress-egress-rules — ingress and egress rule syntax, ACM level integration
+- https://cloud.google.com/vpc-service-controls/docs/supported-products — supported GCP services list and restrictions per service
+- https://cloud.google.com/run/docs/securing/using-vpc-service-controls — Cloud Run inside VPC-SC perimeters, VPC Accessible Services configuration
+
+## Grounding rule
+
+Official documentation explains GCP service behavior. It does not prove the user's current perimeter configuration, dry-run violation count, ACM level conditions, or enforcement mode status. Prefer sanitized user-provided evidence (access policy exports, Terraform/IaC, violation log exports) for current-state claims. Never infer production perimeter state from documentation alone.

package/skills/gcp/gcp-vpc-service-controls-architect/references/workflow-and-output.md

@@ -0,0 +1,70 @@
+# Workflow and output contract
+
+Use this reference only when performing the full VPC-SC review, implementation guidance, violation triage, or production-readiness pass.
+
+## Review domains
+
+Check these areas before giving a verdict:
+
+- Access policy: org ID, policy name, policy resource name (`accessPolicies/POLICY_NUMBER`)
+- Service perimeters: name, perimeter type (regular/bridge), enforcement mode (enforced/dry-run), resources (projects)
+- Restricted services: which GCP service APIs are restricted in each perimeter
+- Ingress/egress rules: principal types, sources/targets, services, ACM access level conditions
+- Bridge perimeters: which regular perimeters are bridged, resource overlap, traffic patterns
+- ACM access levels: level name, conditions (IP ranges, device policy, identity), combining function
+- Serverless workloads: Cloud Functions, Cloud Run, Dataflow — confirmed API egress patterns, VPC Accessible Services configuration
+- Violation logs: GOOGLE_API_VIOLATION, POLICY_VIOLATION, DRY_RUN_VIOLATION — principal, service, direction
+
+## Safe workflow
+
+1. **Frame scope**
+   - Org and access policy confirmed:
+   - Perimeters in scope:
+   - Environment (prod/staging/dev):
+   - Enforcement mode status:
+   - Required outcome:
+   - Explicit non-goals:
+2. **Collect evidence**
+   - Prefer sanitized `gcloud access-context-manager perimeters list`, `gcloud access-context-manager perimeters describe`, or Terraform state exports.
+   - For violations: Cloud Logging exports filtered for `protoPayload.status.code=PERMISSION_DENIED` with VPC-SC context.
+   - Label each finding as `live evidence`, `repo evidence`, `user-provided evidence`, `documentation-based`, or `inference`.
+3. **Stress-test risk**
+   - Which perimeters are in enforcement mode without dry-run validation history?
+   - Which serverless workloads inside a perimeter have uncovered API egress paths?
+   - Which dry-run violations represent legitimate workflows vs. unexpected access?
+   - Which bridge perimeters increase blast radius unnecessarily?
+   - What evidence is missing?
+4. **Recommend the smallest safe action**
+   - Prefer dry-run first, minimal ingress/egress rules with ACM conditions, and staged enforcement rollout.
+   - If the safest action is to stop and gather dry-run violation evidence, say that plainly.
+
+## Output contract
+
+Return this structure:
+
+```markdown
+# GCP VPC Service Controls Review: <scope>
+## Executive verdict
+- Status: READY / READY WITH RISKS / NOT READY / NEEDS EVIDENCE
+- Biggest risk:
+- Evidence level:
+## Access policy and perimeter inventory
+| Perimeter | Type | Enforcement mode | Resources | Restricted services |
+|---|---|---|---|---|
+## Dry-run violation summary
+| Principal | Target service | Direction | Violation reason | Legitimate? |
+|---|---|---|---|---|
+## Bridge perimeter assessment
+| Bridge perimeter | Connects | Risk | Alternative |
+|---|---|---|---|
+## ACM access level review
+| Level name | Conditions | Applied to rules | Gap |
+|---|---|---|---|
+## Serverless workload blind spots
+| Workload | Type | API egress covered | Action needed |
+|---|---|---|---|
+## Recommended actions
+1. <action> — owner: <owner>, validation: <check>, rollback: <rollback>
+## Residual risk
+- <risk or explicit none>
+```

package/skills/gcp/gcp-waf-cost-optimization-review/SKILL.md

@@ -0,0 +1,173 @@
+---
+name: gcp-waf-cost-optimization-review
+description: "Evaluate GCP workload cost efficiency against the Google Cloud Well-Architected Framework cost optimization pillar — covering FinOps culture, cloud spending alignment with business value, resource rightsizing, commitment strategy, idle resource elimination, and continuous optimization. Use when reviewing cloud costs, designing cost-aware architectures, or identifying cost reduction opportunities in GCP."
+allowed-tools: Read Grep Glob
+metadata:
+  author: "github: Raishin"
+  version: "0.1.0"
+  updated: "2026-05-09"
+  category: finops
+---
+
+# GCP WAF Cost Optimization Review
+
+## Purpose
+
+Evaluate GCP workload cost efficiency against the Google Cloud Well-Architected Framework (WAF) cost optimization pillar. This skill supports the shift from CapEx to OpEx models, builds a FinOps culture with clear accountability, and drives continuous optimization aligned with business value.
+
+## When to use
+
+Use this skill for:
+
+- Reviewing current cloud costs and identifying optimization opportunities
+- Designing cost-aware architectures with managed services and right-sized resources
+- Auditing a workload against the four WAF cost optimization principles
+- Building cost attribution, visibility, and accountability structures
+- Evaluating commitment strategies and idle resource elimination
+
+## WAF Cost Optimization Pillar Overview
+
+The GCP Well-Architected Framework cost optimization pillar guides organizations through the shift from capital expenditure (CapEx) to operational expenditure (OpEx), where costs are incurred on demand and tightly coupled to delivered business value. The pillar emphasizes FinOps culture — shared ownership of cost between engineering, finance, and product — alongside tooling for visibility, accountability, rightsizing, and continuous optimization.
+
+## Core Principles
+
+### 1. Align Cloud Spending with Business Value
+Ensure that every dollar of cloud spend can be traced to a business outcome. Use resource labels and billing hierarchies to attribute costs to teams, products, and value streams. Evaluate cloud ROI by comparing cost against delivered user value.
+- Reference: https://cloud.google.com/architecture/framework/cost-optimization/align-cloud-spending-business-value
+
+### 2. Foster a Culture of Cost Awareness
+Embed cost accountability into engineering teams rather than treating it as a finance function. Provide developers with cost visibility for the resources they own, set team-level budgets, and include cost in architectural and code review decisions.
+- Reference: https://cloud.google.com/architecture/framework/cost-optimization/foster-culture-cost-awareness
+
+### 3. Optimize Resource Usage
+Select and configure GCP resources to match actual workload requirements. Apply rightsizing recommendations, use Spot VMs for fault-tolerant workloads, migrate to serverless or managed services where appropriate, and enforce storage lifecycle policies to eliminate unnecessary retention costs.
+- Reference: https://cloud.google.com/architecture/framework/cost-optimization/optimize-resource-usage
+
+### 4. Optimize Continuously
+Treat cost optimization as an ongoing discipline, not a one-time exercise. Establish regular review cadences, act on Recommender and Active Assist insights, track savings against baselines, and iterate on commitment strategies as workload patterns evolve.
+- Reference: https://cloud.google.com/architecture/framework/cost-optimization/optimize-continuously
+
+## Relevant GCP Products
+
+### Visibility
+- **Cloud Billing Reports** — spend dashboards, cost breakdowns, and trend analysis in the GCP Console
+- **BigQuery Billing Export** — export detailed billing data to BigQuery for custom analysis and Looker Studio dashboards
+- **Looker Studio** — visualization layer for billing data, enabling team-level and product-level cost dashboards
+- **Billing Alerts and Budgets** — automated alerts when spend exceeds defined thresholds per project or billing account
+
+### Automation and Recommendations
+- **Recommender / Active Assist** — rightsizing recommendations for Compute Engine, Cloud SQL, GKE, and more
+- **Cloud Hub Optimization** — centralized view of optimization opportunities across the organization
+- **FinOps Hub** — GCP-native FinOps dashboard aggregating savings opportunities and commitment coverage
+- **Billing Quotas** — enforce per-project API quotas to prevent runaway spend
+
+### Efficient Infrastructure
+- **Cloud Run / Cloud Run Functions** — serverless compute with per-request billing, eliminating idle compute costs
+- **GKE Autopilot** — managed GKE mode with per-pod billing and automatic node rightsizing
+- **Spot VMs** — preemptible compute at up to 91% discount for fault-tolerant batch and stateless workloads
+- **Committed Use Discounts (CUDs)** — 1-year and 3-year resource-based or spend-based commitments for predictable discount
+- **Cloud Storage Lifecycle Policies** — automatically transition or delete objects based on age, class, and access frequency
+
+### Governance
+- **Resource Manager (Org / Folder / Project)** — hierarchy for cost boundary enforcement and policy inheritance
+- **Labels** — key-value tags on resources enabling cost attribution to teams, products, and environments
+- **Organization Policy Service** — enforce label requirements, restrict resource types, and prevent cost-inefficient configurations
+
+## Assessment Question Bank
+
+### Cost in Design
+1. Are cost estimates produced before architectural decisions are finalized, not after deployment?
+2. Are managed and serverless services evaluated as the default before choosing self-managed VMs?
+3. Are storage classes and lifecycle policies defined at design time for all object storage workloads?
+4. Are development and staging environments sized smaller than production and shut down outside working hours?
+5. Are cost constraints treated as non-functional requirements alongside performance and reliability?
+6. Are Spot VMs or preemptible nodes used for batch, CI/CD, or other fault-tolerant workloads?
+
+### Team Cost Culture
+1. Do engineering teams have visibility into the costs of the resources they own?
+2. Are per-team or per-product cost budgets defined and communicated?
+3. Is cost included as a review criterion in architecture and code reviews?
+4. Are team cost targets tracked and reported in team-level dashboards?
+5. Is there a FinOps champion or cost optimization guild coordinating cross-team efforts?
+6. Are engineers recognized or incentivized for cost reduction contributions?
+
+### Cost Monitoring and Attribution
+1. Are all GCP resources labeled with team, product, environment, and cost center tags?
+2. Is BigQuery billing export enabled and used for detailed cost analysis?
+3. Are per-project billing budgets and alerts configured to surface anomalous spend?
+4. Is there a process for investigating and explaining billing anomalies within 24 hours?
+5. Are cost trends reviewed on a weekly or bi-weekly cadence?
+6. Are unit economics tracked (cost per user, cost per transaction, cost per GB processed)?
+
+### Compute Optimization
+1. Are Compute Engine rightsizing recommendations from Recommender reviewed and acted on monthly?
+2. Are sustained use discounts (SUDs) and committed use discounts (CUDs) coverage monitored and maintained?
+3. Are GKE workloads using bin-packing or Autopilot to eliminate wasted node capacity?
+4. Are Cloud Run or Cloud Run Functions used for workloads with variable or unpredictable request patterns?
+5. Are GPU and TPU resources released when not actively in use?
+6. Are dev/test VMs shut down automatically outside business hours?
+
+### Over-Provisioning Prevention
+1. Are Cloud SQL instances sized to actual p95 CPU and memory utilization, not peak-of-peak estimates?
+2. Are GKE resource requests and limits set accurately to reflect actual pod utilization?
+3. Are memory-optimized or compute-optimized machine families used where appropriate rather than general-purpose?
+4. Are autoscaling policies configured to scale in aggressively as well as scale out?
+5. Are network egress costs understood and minimized through routing and caching strategy?
+
+### Data-Driven Continuous Optimization
+1. Is there a monthly cost review meeting with finance, engineering, and product stakeholders?
+2. Are Active Assist and Recommender insights reviewed, accepted, or dismissed with documented rationale?
+3. Are savings realized from optimization tracked against baselines and reported to leadership?
+4. Is the CUD commitment strategy reviewed quarterly as workload patterns change?
+5. Are unattached persistent disks, unused IP addresses, and idle load balancers identified and removed?
+6. Are BigQuery slot reservations and on-demand spend reviewed against actual query patterns?
+
+## Validation Checklist
+
+### Cost Attribution
+- [ ] 100% of billable GCP resources labeled with team, product, environment, and cost-center labels
+- [ ] BigQuery billing export enabled on the billing account and queried regularly
+- [ ] Per-project billing budgets configured with email and Pub/Sub alerts
+- [ ] Unit economics defined and tracked (cost per user, cost per transaction)
+
+### Visibility and Monitoring
+- [ ] Looker Studio or equivalent cost dashboard available to all engineering teams
+- [ ] Billing anomaly alerts configured to notify within 24 hours of unexpected spend
+- [ ] Weekly or bi-weekly cost review cadence established
+
+### Rightsizing
+- [ ] Recommender rightsizing recommendations reviewed and acted on monthly for Compute Engine
+- [ ] GKE resource requests and limits set based on VPA recommendations or actual utilization
+- [ ] Cloud SQL instances sized to p95 CPU and memory utilization
+
+### Commitment Strategy
+- [ ] CUD coverage reviewed monthly against eligible committed workloads
+- [ ] Spend-based CUDs used where resource-based CUDs do not apply
+- [ ] SUDs and CUD coverage tracked in FinOps Hub or equivalent dashboard
+
+### Idle Resource Elimination
+- [ ] Unattached persistent disks identified and deleted or snapshotted
+- [ ] Unused static IP addresses released
+- [ ] Idle load balancers and forwarding rules removed
+- [ ] Dev/test environments shut down automatically outside business hours
+
+### Serverless and Managed Services
+- [ ] Serverless-first evaluation performed for all new compute workloads
+- [ ] Cloud Run or Cloud Run Functions used for variable-traffic services
+- [ ] GKE Autopilot evaluated for container workloads without node-level requirements
+
+### Storage Lifecycle
+- [ ] Cloud Storage lifecycle policies active on all buckets, transitioning to Nearline/Coldline/Archive by access pattern
+- [ ] BigQuery table partitioning and clustering applied to reduce query costs
+- [ ] Snapshot and backup retention policies defined and enforced
+
+## Response Shape
+
+1. **Scope** — workload name, GCP resource hierarchy scope, evidence level (live billing data / sanitized / documentation-based / inference)
+2. **Cost Attribution Assessment** — review of labeling coverage, billing export configuration, and cost visibility tooling
+3. **Visibility Gaps** — missing dashboards, alerts, or monitoring that reduce cost awareness
+4. **Rightsizing Opportunities** — specific compute, database, and storage resources identified as over-provisioned with estimated savings
+5. **Commitment Strategy** — review of CUD/SUD coverage, commitment gaps, and recommended commitment approach
+6. **Idle Resources** — unattached disks, unused IPs, idle load balancers, and orphaned resources identified
+7. **Managed Services Fit** — workloads that would reduce cost or operational overhead by moving to serverless or managed services
+8. **Prioritized Savings Actions** — ordered by estimated annual savings impact (High / Medium / Low), each with minimum required change, validation step, and rollback procedure

package/skills/gcp/gcp-waf-cost-optimization-review/metadata.json

@@ -0,0 +1,19 @@
+{
+  "id": "gcp-waf-cost-optimization-review",
+  "name": "GCP WAF Cost Optimization Review",
+  "type": "skill",
+  "provider": "gcp",
+  "harnesses": ["codex", "claude-code", "cursor", "gemini", "kiro", "other"],
+  "summary": "Evaluate GCP workload cost efficiency against the Google Cloud Well-Architected Framework cost optimization pillar, covering FinOps culture, spending alignment, resource rightsizing, commitment strategy, idle resource elimination, and continuous optimization.",
+  "source_type": "original",
+  "official_docs": [
+    "https://cloud.google.com/architecture/framework/cost-optimization",
+    "https://cloud.google.com/billing/docs/how-to/export-data-bigquery",
+    "https://cloud.google.com/recommender/docs/recommenders"
+  ],
+  "security_notes": "Read-only advisory. Do not cancel commitments, delete resources, or modify billing accounts without explicit user approval and confirmation of resource inventory.",
+  "last_verified": "2026-05-09",
+  "path": "skills/gcp/gcp-waf-cost-optimization-review",
+  "author": "github: Raishin",
+  "version": "0.1.0"
+}

package/skills/gcp/gcp-waf-reliability-review/SKILL.md

@@ -0,0 +1,209 @@
+---
+name: gcp-waf-reliability-review
+description: "Evaluate GCP workload reliability against the Google Cloud Well-Architected Framework reliability pillar — covering SLOs/error budgets, HA topology, horizontal scalability, observability, graceful degradation, failure testing, data recovery, and postmortems. Use when assessing availability requirements, designing resilient architectures, or auditing a GCP workload for reliability gaps."
+allowed-tools: Read Grep Glob
+metadata:
+  author: "github: Raishin"
+  version: "0.1.0"
+  updated: "2026-05-09"
+  category: resilience
+---
+
+# GCP WAF Reliability Review
+
+## Purpose
+
+Evaluate GCP workload reliability against the Google Cloud Well-Architected Framework (WAF) reliability pillar. This skill supports consistent performance, resilience to failures, and graceful recovery for workloads running on GCP.
+
+## When to use
+
+Use this skill for:
+
+- Assessing availability requirements and SLO definitions for a workload
+- Designing highly available, resilient architectures on GCP
+- Auditing a workload against the nine WAF reliability principles
+- Evaluating redundancy topology, observability coverage, and failure testing maturity
+- Reviewing postmortem culture and data recovery practices
+
+## WAF Reliability Pillar Overview
+
+The GCP Well-Architected Framework reliability pillar provides guidance across nine core principles. Together they ensure workloads deliver consistent performance to users, remain resilient under fault conditions, and recover gracefully from both partial and complete failures. The pillar emphasizes user-experience-driven SLOs, error budget discipline, horizontal scalability, and continuous improvement through postmortems.
+
+## Core Principles
+
+### 1. Define Reliability Based on User-Experience Goals
+Anchor reliability targets to user-observable outcomes rather than internal infrastructure metrics. Define SLIs that reflect what users actually care about — latency, availability, correctness, and throughput.
+- Reference: https://cloud.google.com/architecture/framework/reliability/define-reliability-based-on-user-experience-goals
+
+### 2. Set Realistic Targets for Reliability
+Establish SLOs and error budgets that are achievable, meaningful, and aligned with business risk tolerance. Avoid aspirational targets that drain engineering capacity without delivering user value.
+- Reference: https://cloud.google.com/architecture/framework/reliability/set-targets
+
+### 3. Build Highly Available Systems Through Resource Redundancy
+Eliminate single points of failure by distributing resources across multiple zones and regions. Design for fault isolation so that the failure of any single component does not cascade to a full system outage.
+- Reference: https://cloud.google.com/architecture/framework/reliability/build-highly-available-systems
+
+### 4. Take Advantage of Horizontal Scalability
+Design systems to scale out rather than up. Use managed instance groups, GKE node pools, and serverless platforms to handle load increases without manual intervention and without architectural bottlenecks.
+- Reference: https://cloud.google.com/architecture/framework/reliability/horizontal-scalability
+
+### 5. Detect Potential Failures by Using Observability
+Instrument workloads with metrics, logs, and traces that provide actionable signals before failures reach users. Use SLI-based alerting to distinguish user-impacting events from noise.
+- Reference: https://cloud.google.com/architecture/framework/reliability/observability
+
+### 6. Design for Graceful Degradation
+Architect systems to maintain partial functionality under failure conditions. Implement circuit breakers, retries with exponential backoff, bulkheads, rate limiting, and fallback paths to prevent cascading failures.
+- Reference: https://cloud.google.com/architecture/framework/reliability/graceful-degradation
+
+### 7. Perform Testing for Recovery from Failures
+Validate resilience assumptions through chaos engineering and game days. Test failure modes including zone outages, dependency timeouts, traffic surges, and misconfigurations in pre-production and, where safe, in production.
+- Reference: https://cloud.google.com/architecture/framework/reliability/perform-testing-for-recovery-from-failures
+
+### 8. Perform Testing for Recovery from Data Loss
+Validate backup and restore procedures regularly. Test recovery time objective (RTO) and recovery point objective (RPO) compliance under realistic failure scenarios, not just in tabletop exercises.
+- Reference: https://cloud.google.com/architecture/framework/reliability/perform-testing-for-recovery-from-data-loss
+
+### 9. Conduct Thorough Postmortems
+Build a blameless postmortem culture to systematically capture incident learnings. Track action items to completion and share findings to prevent recurrence across teams.
+- Reference: https://cloud.google.com/architecture/framework/reliability/conduct-postmortems
+
+## Relevant GCP Products
+
+- **Compute & Containers:** Compute Engine Managed Instance Groups (MIGs), Google Kubernetes Engine (GKE), Cloud Run, Cloud Run Functions
+- **Load Balancing & Networking:** Cloud Load Balancing (global and regional), Cloud CDN, Cloud DNS with routing policies, Traffic Director
+- **Data & Storage:** Cloud Storage (multi-region buckets), Cloud SQL with HA and read replicas, Cloud Spanner (multi-region), Bigtable, Firestore
+- **Observability:** Cloud Monitoring, Cloud Logging, Cloud Trace, Google Cloud Managed Service for Prometheus, Error Reporting, SLO monitoring
+- **Backup & Resilience:** Backup and DR Service, Cloud Storage versioning, Cloud SQL automated backups, Spanner PITR
+- **Autoscaling:** MIG autoscaler, GKE Horizontal Pod Autoscaler (HPA), GKE Vertical Pod Autoscaler (VPA), GKE cluster autoscaler, Cloud Run concurrency-based scaling
+
+## Assessment Question Bank
+
+### SLO/SLI Definition and Error Budgets
+1. Are SLIs defined based on user-observable outcomes (latency, availability, correctness) rather than infrastructure metrics?
+2. Is an SLO set for each user-facing service with an associated error budget?
+3. Is the error budget actively tracked and used to gate feature velocity vs. reliability investment?
+4. Are SLOs documented in a service-level agreement (SLA) or internal reliability contract?
+5. Are SLOs reviewed and updated when user expectations or product requirements change?
+6. Is there a process for alerting when error budget burn rate is too high?
+
+### Realistic Reliability Targets
+1. Were SLO targets derived from user research, business requirements, or dependency constraints rather than set arbitrarily?
+2. Is the cost of each additional nine (99.9% vs. 99.99%) understood and justified?
+3. Are dependencies' reliability levels accounted for when setting the workload's own SLO?
+4. Is there a tiering model distinguishing critical vs. non-critical services with different reliability targets?
+5. Are error budget policies defined (e.g., freeze new features when budget is exhausted)?
+
+### High Availability Topology
+1. Are workloads deployed across at least two availability zones within a region?
+2. Are stateful services (databases, caches) configured for multi-zone or multi-region replication?
+3. Are managed instance groups or GKE deployments configured with anti-affinity rules to spread replicas across zones?
+4. Is Cloud Load Balancing configured with health checks that remove unhealthy backends automatically?
+5. Are DNS failover or routing policies used to redirect traffic during regional impairments?
+6. Is there a documented recovery procedure for a full zone failure?
+7. Are global load balancers used for latency-sensitive workloads requiring cross-region failover?
+
+### Horizontal Scalability
+1. Are workloads designed to scale out (add instances) rather than scale up (increase instance size)?
+2. Are autoscaling policies configured and tested for all stateless compute tiers?
+3. Is there capacity headroom available to absorb unexpected traffic spikes without manual intervention?
+4. Are stateful components (databases, queues) able to scale horizontally or handle peak load without bottlenecks?
+5. Are scaling decisions based on meaningful metrics (request latency, queue depth) rather than just CPU utilization?
+6. Are scale-in operations safe — do they wait for in-flight requests to complete before terminating instances?
+
+### Observability
+1. Are the four golden signals (latency, traffic, errors, saturation) instrumented for each service?
+2. Are SLI metrics available in Cloud Monitoring with SLO policies configured?
+3. Is distributed tracing enabled to diagnose cross-service latency issues?
+4. Are logs structured and indexed for efficient querying during incidents?
+5. Are alerting policies calibrated to user-impacting events — not just infrastructure anomalies?
+6. Is there an on-call runbook for every critical alert?
+7. Is Managed Service for Prometheus used for workload-level metrics in GKE environments?
+8. Are dashboards available that show SLO burn rate in real time?
+
+### Graceful Degradation
+1. Are circuit breakers implemented for calls to external dependencies and downstream services?
+2. Are retries bounded with exponential backoff and jitter to prevent retry storms?
+3. Are rate limits and concurrency controls applied to protect services from overload?
+4. Are fallback paths defined — what does the system do when a non-critical dependency is unavailable?
+5. Are bulkheads or resource pools used to isolate failures in one subsystem from others?
+6. Are timeouts set on all synchronous outbound calls?
+7. Is load shedding implemented to preserve core functionality under extreme load?
+
+### Failure Recovery Testing
+1. Are chaos engineering experiments (e.g., zone failure simulation, dependency injection) performed in pre-production?
+2. Is a game day schedule maintained and followed at least annually for critical workloads?
+3. Are failure scenarios documented with expected behavior and actual results compared?
+4. Are runbooks validated by actually executing them during game days rather than just reviewing them?
+5. Is the blast radius of each experiment scoped and approved before execution?
+
+### Data Recovery Testing
+1. Are backup procedures automated and scheduled for all stateful services?
+2. Are backup restores tested on a scheduled cadence (e.g., monthly) — not just at setup time?
+3. Are RTO and RPO targets defined and validated through restore tests?
+4. Are backups stored in a separate project or region from the primary data to protect against account-level failures?
+5. Is point-in-time recovery (PITR) enabled for databases where fine-grained recovery is required?
+6. Are backup success/failure alerts configured and monitored?
+
+### Postmortems
+1. Is a blameless postmortem required for every P0 and P1 incident?
+2. Are postmortems completed within a defined SLA (e.g., 5 business days after incident resolution)?
+3. Are action items assigned owners and tracked to completion in a system of record?
+4. Are postmortem findings shared across teams to prevent similar incidents?
+5. Is there a process for identifying recurring themes across postmortems?
+6. Are follow-up reliability improvements validated before the next incident review cycle closes?
+
+## Validation Checklist
+
+### SLI/SLO Monitoring
+- [ ] SLIs defined for all user-facing services based on user-observable outcomes
+- [ ] SLO policies configured in Cloud Monitoring with error budget tracking
+- [ ] Error budget burn rate alerts configured and tested
+- [ ] Error budget policies documented (e.g., feature freeze when budget exhausted)
+
+### Cross-Zone Redundancy
+- [ ] All stateless compute tiers deployed across at least two zones
+- [ ] Stateful services (Cloud SQL, Spanner, Memorystore) configured for multi-zone HA
+- [ ] MIG or GKE anti-affinity rules preventing all replicas from landing in a single zone
+- [ ] Load balancer health checks removing unhealthy backends automatically
+
+### Autoscaling
+- [ ] Autoscaling configured for all stateless compute (MIG autoscaler, HPA, Cloud Run concurrency)
+- [ ] Scaling metrics reflect meaningful load signals (latency, queue depth) not just CPU
+- [ ] Scale-in operations validated to complete in-flight requests before instance termination
+
+### Health Checks
+- [ ] HTTP(S) or gRPC health checks configured on all backend services
+- [ ] Health check intervals and unhealthy thresholds tuned to detect failures quickly
+- [ ] Health check failures trigger automated backend removal
+
+### Backup Testing
+- [ ] Backup restore tested within the last 30 days for all critical stateful services
+- [ ] RTO and RPO targets documented and validated through restore tests
+- [ ] Backups stored in a separate project or region from primary data
+
+### Graceful Degradation Patterns
+- [ ] Circuit breakers implemented for all external and downstream service calls
+- [ ] Retries bounded with exponential backoff and jitter
+- [ ] Rate limiting and concurrency controls applied to protect from overload
+- [ ] Fallback paths defined and tested for all non-critical dependencies
+- [ ] Timeouts set on all synchronous outbound calls
+
+### Game Days and Chaos Engineering
+- [ ] Game day conducted within the last 12 months for all critical workloads
+- [ ] Chaos experiments scoped, approved, and results documented
+- [ ] Runbooks validated by execution rather than review only
+
+### Postmortem Process
+- [ ] Blameless postmortem required for all P0 and P1 incidents
+- [ ] Postmortem SLA defined (e.g., 5 business days) and met
+- [ ] Action items tracked to completion in a system of record
+
+## Response Shape
+
+1. **Scope** — workload name, GCP resource hierarchy scope, evidence level (live / sanitized / documentation-based / inference)
+2. **SLO/SLI Assessment** — review of SLI definitions, SLO targets, error budget tracking, and alerting calibration
+3. **HA Topology Review** — evaluation of redundancy patterns, load balancing configuration, and zone/region coverage
+4. **Observability Gaps** — missing metrics, alerts, dashboards, or tracing coverage that reduce incident detection capability
+5. **Failure Testing Status** — game day schedule, chaos experiment coverage, runbook validation status
+6. **Recommendations** — ordered by reliability risk (Critical / High / Medium / Low), each with minimum required change, validation step, and rollback procedure
+7. **Open Risks** — items that could not be assessed due to missing evidence, with recommended evidence to gather

package/skills/gcp/gcp-waf-reliability-review/metadata.json

@@ -0,0 +1,19 @@
+{
+  "id": "gcp-waf-reliability-review",
+  "name": "GCP WAF Reliability Review",
+  "type": "skill",
+  "provider": "gcp",
+  "harnesses": ["codex", "claude-code", "cursor", "gemini", "kiro", "other"],
+  "summary": "Evaluate GCP workload reliability against the Google Cloud Well-Architected Framework reliability pillar, covering SLOs, HA topology, horizontal scalability, observability, graceful degradation, failure testing, data recovery, and postmortems.",
+  "source_type": "original",
+  "official_docs": [
+    "https://cloud.google.com/architecture/framework/reliability",
+    "https://cloud.google.com/architecture/framework/reliability/build-highly-available-systems",
+    "https://cloud.google.com/monitoring/docs/monitoring_in_practice"
+  ],
+  "security_notes": "Read-only advisory. Do not modify production infrastructure or SLO configs without explicit approval. Treat all architecture info as potentially sensitive.",
+  "last_verified": "2026-05-09",
+  "path": "skills/gcp/gcp-waf-reliability-review",
+  "author": "github: Raishin",
+  "version": "0.1.0"
+}