@raishin/vanguard-frontier-agentic 1.4.0 → 1.6.0

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

@@ -0,0 +1,106 @@
+---
+name: azure-waf-reliability-review
+description: "Review Azure workload reliability against the Well-Architected Framework Reliability pillar: availability targets, AZ/region topology, health monitoring, data resilience, deployment safety, and chaos testing."
+allowed-tools: Read Grep Glob
+metadata:
+  author: "github: Raishin"
+  version: "0.1.0"
+  updated: "2026-05-09"
+  category: resilience
+---
+
+# Azure WAF Reliability Review
+
+The Azure Well-Architected Framework Reliability pillar covers designing, building, and operating workloads that are resilient to failures, meet availability targets, and recover gracefully from disruptions.
+
+## 5 Reliability Design Principles
+
+1. **Design for business requirements** — translate business requirements into measurable reliability targets; define RTO, RPO, availability SLOs
+2. **Design for resilience** — ensure the workload survives fault conditions without complete outage; design for partial failure
+3. **Design for recovery** — assume failures will happen; implement automated recovery; test recovery procedures regularly
+4. **Design for operations** — build operations into the design; implement health modeling; use automated deployments
+5. **Keep it simple** — avoid design complexity that introduces reliability risks; use managed services to reduce operational burden
+
+## Azure Reliability Service Areas
+
+### Availability Zones
+- Zone-redundant services: ZRS Storage, Zone-redundant Azure SQL, AKS across zones
+- Zonal deployments: pin to specific zone for latency-sensitive workloads
+- Regional services: single-zone, not HA — use only for non-critical or dev/test workloads
+
+### Fault Tolerance
+- Azure Load Balancer (L4) — regional traffic distribution
+- Azure Application Gateway (L7) — zone-redundant HTTP/S load balancing with WAF
+- Azure Traffic Manager (DNS) — cross-region failover and weighted routing
+- Azure Front Door — global anycast with automatic failover
+
+### Scalability
+- VMSS (Virtual Machine Scale Sets) — VM-based horizontal scaling
+- Azure Kubernetes Service (KEDA, HPA) — pod and node autoscaling
+- Azure App Service autoscale — rule-based and metric-based scaling
+- Azure Functions consumption plan — event-driven serverless scaling
+
+### Data Resilience
+- Azure SQL Business Critical — 2 readable secondaries, zone-redundant by default
+- Cosmos DB — multi-region writes, configurable consistency (strong/bounded-staleness)
+- Azure Storage GRS/GZRS — geo-redundant and geo-zone-redundant replication
+- Azure Backup — VM, SQL, and file share backup with retention policies
+- Azure Site Recovery (ASR) — VM replication and orchestrated failover
+
+### Health Modeling
+- Azure Monitor — metrics, logs, and alerting platform
+- Application Insights — distributed tracing, availability tests, failure analysis
+- Azure Service Health alerts — planned maintenance, outage notifications, advisories
+- Resource Health API — per-resource health signal for automated remediation
+
+### Chaos Engineering
+- Azure Chaos Studio — inject faults: VM availability zone failure, AKS pod failure, network latency, dependency unavailability
+
+### Deployment Safety
+- App Service deployment slots — blue/green with slot swap and auto-swap
+- Azure Deployment Environments — consistent, governed environment templates
+- Traffic Manager weighted routing — canary deployment with percentage-based traffic split
+
+## Azure SLA Key Facts
+
+- Availability Zones: **99.99%** SLA for VMs when using ≥2 VMs across ≥2 AZs
+- Azure SQL Business Critical + zones: **99.995%**
+- Cosmos DB multi-region writes: **99.999%**
+- Single VM with Premium SSD: **99.9%** — NOT suitable for production HA
+- Traffic Manager: **99.99%**
+
+## Assessment Questions
+
+- What are the availability and reliability targets for the workload?
+- How do you ensure the workload can operate during a zone or region outage?
+- How do you implement health monitoring and proactive alerting?
+- How do you manage dependencies and limit blast radius of failures?
+- How do you test resilience and validate recovery procedures?
+- How do you design for graceful degradation under load or partial failure?
+- How do you implement safe deployment practices to minimize rollback risk?
+
+## Validation Checklist
+
+- [ ] SLOs defined with measurable SLIs monitored via Azure Monitor
+- [ ] All stateful services (VMs, databases) deployed across ≥2 Availability Zones
+- [ ] Azure Service Health alerts configured for all services in use
+- [ ] Autoscaling enabled for stateless compute (VMSS, App Service, AKS node pools)
+- [ ] Azure SQL or Cosmos DB multi-region replication configured for mission-critical data
+- [ ] Azure Backup or ASR configured for VMs, SQL databases, and critical storage
+- [ ] Deployment slots or Traffic Manager canary routing used for production deployments
+- [ ] Azure Chaos Studio experiments conducted to validate AZ failure recovery
+- [ ] Circuit breaker and retry patterns implemented for external service calls
+- [ ] RTO/RPO targets documented and validated via DR drill in the last 12 months
+
+## Response Shape
+
+Availability targets review → AZ/region topology → health monitoring → failure tolerance → data resilience → deployment safety → chaos testing status → recommendations → open risks
+
+## Official Documentation
+
+- https://learn.microsoft.com/azure/well-architected/reliability/
+- https://learn.microsoft.com/azure/reliability/availability-zones-overview
+
+## Security Notes
+
+Read-only advisory. Do not modify autoscaling policies, backup schedules, or Azure Site Recovery configurations without explicit approval.

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

@@ -0,0 +1,18 @@
+{
+  "id": "azure-waf-reliability-review",
+  "name": "Azure WAF Reliability Review",
+  "type": "skill",
+  "provider": "azure",
+  "harnesses": ["codex", "claude-code", "cursor", "gemini", "kiro", "other"],
+  "summary": "Review Azure workload reliability against the Well-Architected Framework Reliability pillar: availability targets, AZ/region topology, health monitoring, data resilience, deployment safety, and chaos testing.",
+  "source_type": "original",
+  "official_docs": [
+    "https://learn.microsoft.com/azure/well-architected/reliability/",
+    "https://learn.microsoft.com/azure/reliability/availability-zones-overview"
+  ],
+  "security_notes": "Read-only advisory. Do not modify autoscaling policies, backup schedules, or Azure Site Recovery configurations without explicit approval.",
+  "last_verified": "2026-05-09",
+  "path": "skills/azure/azure-waf-reliability-review",
+  "author": "github: Raishin",
+  "version": "0.1.0"
+}

package/skills/azure/azure-waf-security-review/SKILL.md

@@ -0,0 +1,83 @@
+---
+name: azure-waf-security-review
+description: "Review Azure workload security posture against the Well-Architected Framework Security pillar: identity and access, network boundaries, data protection, threat detection, DevSecOps maturity, and policy compliance."
+allowed-tools: Read Grep Glob
+metadata:
+  author: "github: Raishin"
+  version: "0.1.0"
+  updated: "2026-05-09"
+  category: security
+---
+
+# Azure WAF Security Review
+
+The Azure Well-Architected Framework Security pillar provides guidance for protecting workload data, systems, and assets while maintaining confidentiality and integrity.
+
+## 8 Security Design Principles
+
+1. **Plan your security readiness** — understand security requirements, threats, and compliance obligations before building
+2. **Design to protect confidentiality** — prevent exposure of sensitive data through encryption, access controls, and data classification
+3. **Design to protect integrity** — detect and prevent unauthorized access to systems and data; use identity-based access
+4. **Design to protect availability** — defend against attacks that deny access to workloads; use DDoS protection and redundancy
+5. **Sustain and evolve your security posture** — continuously monitor, learn from incidents, and improve defenses
+6. **Defense in depth** — layer multiple security controls so no single failure exposes the workload
+7. **Zero trust** — verify explicitly, use least privilege access, assume breach
+8. **Minimize the blast radius** — limit the scope of impact from security incidents
+
+## Azure Security Service Areas
+
+### Identity
+- Azure Active Directory (Entra ID), Conditional Access, MFA, Privileged Identity Management (PIM), Managed Identity
+
+### Network Security
+- Azure Firewall Premium, Azure Front Door + WAF, DDoS Protection Standard, Network Security Groups (NSG), Azure Private Link, Virtual Network Service Endpoints
+
+### Data Protection
+- Azure Key Vault (keys, secrets, certificates), Azure Disk Encryption, Storage Service Encryption, Always Encrypted (SQL), Microsoft Purview (data governance, sensitivity labels)
+
+### Threat Detection
+- Microsoft Defender for Cloud, Microsoft Sentinel (SIEM/SOAR), Azure Monitor, Defender for Servers/Containers/SQL/Storage/App Service
+
+### Governance
+- Azure Policy, Management Groups, Blueprints (deprecated → use Deployment Stacks), Microsoft Cloud Security Benchmark (MCSB)
+
+### DevSecOps
+- GitHub Advanced Security (CodeQL SAST, secret scanning), Microsoft Defender for DevOps, Container image scanning in ACR, Infrastructure scanning (PSRule for Azure, Checkov)
+
+## Assessment Questions
+
+- How do you manage identity and access to your workload resources?
+- How do you protect your network boundaries?
+- How do you classify and protect your data?
+- How do you detect and respond to security threats?
+- How do you ensure your workload and supply chain are free of vulnerabilities?
+- How do you enforce and validate compliance with security policies?
+- How do you segment access and contain blast radius?
+
+## Validation Checklist
+
+- [ ] All human access uses Entra ID — no local accounts or shared credentials on Azure resources
+- [ ] Managed Identity used for all Azure service-to-service access — no client secrets or certificates in code
+- [ ] MFA enforced via Conditional Access for all users with Azure RBAC assignments
+- [ ] PIM used for privileged roles (Owner, Contributor, User Access Administrator) with approval workflow and just-in-time access
+- [ ] Azure Policy assignments block public storage accounts, unapproved VM SKUs, non-compliant regions
+- [ ] Microsoft Defender for Cloud Standard tier enabled across all subscriptions; security score tracked
+- [ ] All storage accounts and Key Vaults use Private Endpoints — no public network access
+- [ ] Key Vault soft-delete and purge protection enabled for all key vaults
+- [ ] Azure Monitor diagnostic settings enabled for all critical resources; logs sent to Log Analytics
+- [ ] Microsoft Sentinel connected to Log Analytics workspace with MCSB analytics rules enabled
+- [ ] NSG Flow Logs enabled for all production VNets
+- [ ] Container images scanned in ACR; Defender for Containers enabled for AKS
+
+## Response Shape
+
+Identity and access posture → network security assessment → data protection → threat detection coverage → DevSecOps maturity → policy compliance → prioritized recommendations → open risks
+
+## Official Documentation
+
+- https://learn.microsoft.com/azure/well-architected/security/
+- https://learn.microsoft.com/security/benchmark/azure/
+
+## Security Notes
+
+Read-only advisory. Do not modify Entra ID policies, Conditional Access rules, Azure Policy, or Defender configurations without explicit approval.

package/skills/azure/azure-waf-security-review/metadata.json

@@ -0,0 +1,18 @@
+{
+  "id": "azure-waf-security-review",
+  "name": "Azure WAF Security Review",
+  "type": "skill",
+  "provider": "azure",
+  "harnesses": ["codex", "claude-code", "cursor", "gemini", "kiro", "other"],
+  "summary": "Review Azure workload security posture against the Well-Architected Framework Security pillar: identity and access, network boundaries, data protection, threat detection, DevSecOps maturity, and policy compliance.",
+  "source_type": "original",
+  "official_docs": [
+    "https://learn.microsoft.com/azure/well-architected/security/",
+    "https://learn.microsoft.com/security/benchmark/azure/"
+  ],
+  "security_notes": "Read-only advisory. Do not modify Entra ID policies, Conditional Access rules, Azure Policy, or Defender configurations without explicit approval.",
+  "last_verified": "2026-05-09",
+  "path": "skills/azure/azure-waf-security-review",
+  "author": "github: Raishin",
+  "version": "0.1.0"
+}

package/skills/gcp/README.md

@@ -0,0 +1,86 @@
+# 🟩 GCP Skills
+
+<p align="center">
+  <img src="../../assets/logos/cloud/gcp/google-cloud.svg" alt="Google Cloud logo" width="140" />
+</p>
+
+This folder contains GCP-focused skills curated for this marketplace.
+
+## Local marketplace portfolio
+
+As of **2026-05-09**, this folder contains **51** local GCP skills:
+
+- `gcp-alloydb-ai-developer`
+- `gcp-alloydb-cloudsql-dba`
+- `gcp-anthos-multicloud-architect`
+- `gcp-apigee-api-platform-operator`
+- `gcp-bigquery-cost-performance-analyst`
+- `gcp-certificate-manager-issuer-review`
+- `gcp-change-impact-advisor`
+- `gcp-cloud-auth-advisor`
+- `gcp-cloud-run-functions-operator`
+- `gcp-cloudbuild-deploy-cicd-operator`
+- `gcp-compliance-assured-workloads`
+- `gcp-compute-engine-operator`
+- `gcp-cost-anomaly-watch-coordinator`
+- `gcp-cost-finops-analyst`
+- `gcp-daily-operations-briefing-coordinator`
+- `gcp-data-pipeline-engineer`
+- `gcp-event-driven-architecture-review`
+- `gcp-firebase-developer`
+- `gcp-gcs-data-perimeter-governor`
+- `gcp-gemini-api-developer`
+- `gcp-gke-platform-operator`
+- `gcp-iac-change-safety-review`
+- `gcp-iam-least-privilege-review`
+- `gcp-landing-zone-architect`
+- `gcp-live-bigquery-dataset-deletion-guard`
+- `gcp-live-cloud-run-traffic-migration-guard`
+- `gcp-live-cost-budget-action-guard`
+- `gcp-live-gke-rollout-guard`
+- `gcp-live-iam-policy-change-guard`
+- `gcp-live-kms-key-destruction-guard`
+- `gcp-load-balancer-traffic-engineer`
+- `gcp-maestro`
+- `gcp-migration-cutover-architect`
+- `gcp-network-architect`
+- `gcp-networking-observability`
+- `gcp-observability-incident-responder`
+- `gcp-registry-artifact-governor`
+- `gcp-resilience-bcdr-review`
+- `gcp-resource-inventory-analyst`
+- `gcp-secret-kms-lifecycle-steward`
+- `gcp-security-posture-hardening`
+- `gcp-serverless-production-readiness`
+- `gcp-solution-architect`
+- `gcp-spanner-architect`
+- `gcp-support-incident-coordinator`
+- `gcp-ticket-triage-escalation-coordinator`
+- `gcp-vertex-ai-mlops-engineer`
+- `gcp-vpc-service-controls-architect`
+- `gcp-waf-cost-optimization-review`
+- `gcp-waf-reliability-review`
+- `gcp-waf-security-review`
+
+## Official upstream reference
+
+When adding or reviewing GCP skills, check the official Google skills repository first:
+
+- https://github.com/google/skills
+
+Use it as the primary upstream reference for GCP-specific workflow ideas, patterns, and alignment with Google-maintained guidance. This local portfolio was bootstrapped from that upstream repository's GKE, BigQuery, AlloyDB, Cloud Run, Firebase, Gemini API, and WAF-pillar skills.
+
+## Portfolio posture
+
+Role-based GCP skills for evidence-backed architecture, operations, security, networking, FinOps, and guarded live-environment operations.
+
+These skills are intentionally conservative:
+
+- prefer `gcloud` CLI and Cloud Console evidence for live GCP state grounding
+- prefer read-only discovery before mutation
+- require explicit project ID, region (or global scope for VPC), IAM principal, approval, rollback posture, and verification for guarded live actions
+- challenge overly broad IAM bindings, SA key sprawl, public GCS/BigQuery exposure, missing VPC Service Controls perimeters, and unclear resource ownership
+- note that GCP VPC is **global** — networking mutations can affect all regions; always confirm scope
+- use official GCP documentation and live `gcloud` CLI evidence when service behavior matters
+
+Run `npm run validate` after changing cataloged GCP skills.

package/skills/gcp/gcp-alloydb-ai-developer/SKILL.md

@@ -0,0 +1,87 @@
+---
+name: gcp-alloydb-ai-developer
+description: "Design and build AI-powered applications on AlloyDB for PostgreSQL using AlloyDB AI — covering vector search, hybrid search (vector + full-text), AI SQL functions (ai_generate, ai_classify, ai_score, ai_embed), model endpoint management, and the AlloyDB Omni edge runtime. Prefer gcp-alloydb-cloudsql-dba for cluster operations, backup, HA, and DBA tasks; use this skill when the request is primarily about AlloyDB AI search, SQL AI functions, or embedding pipelines."
+allowed-tools: Read Grep Glob
+metadata:
+  author: "github: Raishin"
+  version: "0.1.0"
+  updated: "2026-05-09"
+  category: data
+---
+
+# GCP AlloyDB AI Developer
+
+## Overview
+
+AlloyDB AI is a collection of features built into AlloyDB for PostgreSQL that enables AI-powered search and SQL-native inference — including pgvector integration for vector similarity search, hybrid search combining vector + full-text BM25 scoring, AI SQL functions that invoke hosted models directly from SQL queries, and model endpoint management for custom or Vertex AI models.
+
+## Core AlloyDB AI Capabilities
+
+1. **Vector search with pgvector** — store and query embeddings using `<=>`, `<->`, `<#>` operators; HNSW and IVFFlat index types
+2. **Hybrid search** — combine pgvector cosine similarity with full-text search (tsvector/tsquery) for more relevant retrieval
+3. **AI SQL functions** — `google_ml.predict_row()`, `google_ml.embedding()`, `ai.generate_text()`, `ai.classify()`, `ai.score()` — invoke AI models from SQL without leaving the database
+4. **Model endpoint management** — register Vertex AI model endpoints or Gemini models as AlloyDB model resources; control access via IAM
+5. **AlloyDB Omni** — run AlloyDB (including AlloyDB AI) on-premises or at the edge in a container
+
+## Quick Start (pgvector + hybrid search)
+
+```sql
+-- Enable extensions
+CREATE EXTENSION vector;
+CREATE EXTENSION google_ml_integration;
+
+-- Create table with embedding column
+CREATE TABLE documents (
+  id BIGSERIAL PRIMARY KEY,
+  content TEXT,
+  embedding vector(768)
+);
+
+-- Generate embeddings using AlloyDB AI function
+UPDATE documents
+SET embedding = google_ml.embedding('text-embedding-004', content);
+
+-- Vector similarity search
+SELECT id, content, embedding <=> $1 AS distance
+FROM documents
+ORDER BY distance LIMIT 10;
+
+-- Hybrid search (vector + BM25 full-text)
+SELECT id, content,
+  (1 - (embedding <=> $1)) * 0.7 + ts_rank(to_tsvector(content), query) * 0.3 AS score
+FROM documents, to_tsquery($2) query
+WHERE to_tsvector(content) @@ query
+ORDER BY score DESC LIMIT 10;
+```
+
+## Reference Directory
+
+Load only when needed:
+
+| Scenario | Trigger Keywords | Reference |
+|---|---|---|
+| Vector search setup | pgvector, embedding, similarity, HNSW, IVFFlat | references/vector-search.md |
+| AI SQL functions | ai_generate, ai_classify, google_ml, predict_row | references/ai-functions.md |
+| Hybrid search | hybrid, BM25, full-text, combined search | references/hybrid-search.md |
+| Model endpoints | Vertex AI model, custom model, endpoint, model registry | references/model-endpoints.md |
+| AlloyDB Omni | on-premises, edge, container, Omni | references/alloydb-omni.md |
+| IAM & security | auth, service account, IAM, private IP, PSC | references/iam-security.md |
+
+## Key Rules
+
+- Always use pgvector's HNSW index for production vector search — IVFFlat requires manual reindexing as data grows
+- The `google_ml_integration` extension must be enabled and the AlloyDB service account granted `roles/aiplatform.user` to call Vertex AI models from SQL
+- Hybrid search weight tuning (e.g., 0.7 vector + 0.3 BM25) should be validated against your retrieval quality metrics — defaults are starting points
+- AlloyDB AI functions execute synchronously within SQL transactions — avoid calling slow models in high-frequency OLTP paths
+- AlloyDB Omni supports AlloyDB AI locally without Google Cloud connectivity — ideal for edge inference with pre-loaded models
+- Separate the embedding pipeline (batch UPDATE) from the query path — do not regenerate embeddings on every SELECT
+
+## Official Docs
+
+- https://cloud.google.com/alloydb/docs/ai/overview
+- https://cloud.google.com/alloydb/docs/ai/vector-embeddings
+- https://cloud.google.com/alloydb/docs/omni/overview
+
+## Security Notes
+
+Read-only planning and advisory. Do not modify production AlloyDB schemas, model endpoint registrations, or IAM bindings without explicit approval.

package/skills/gcp/gcp-alloydb-ai-developer/metadata.json

@@ -0,0 +1,19 @@
+{
+  "id": "gcp-alloydb-ai-developer",
+  "name": "GCP AlloyDB AI Developer",
+  "type": "skill",
+  "provider": "gcp",
+  "harnesses": ["codex", "claude-code", "cursor", "gemini", "kiro", "other"],
+  "summary": "Design and build AI-powered applications on AlloyDB for PostgreSQL using AlloyDB AI — covering vector search, hybrid search, AI SQL functions, model endpoint management, and the AlloyDB Omni edge runtime.",
+  "source_type": "original",
+  "official_docs": [
+    "https://cloud.google.com/alloydb/docs/ai/overview",
+    "https://cloud.google.com/alloydb/docs/ai/vector-embeddings",
+    "https://cloud.google.com/alloydb/docs/omni/overview"
+  ],
+  "security_notes": "Read-only planning and advisory. Do not modify production AlloyDB schemas, model endpoint registrations, or IAM bindings without explicit approval.",
+  "last_verified": "2026-05-09",
+  "path": "skills/gcp/gcp-alloydb-ai-developer",
+  "author": "github: Raishin",
+  "version": "0.1.0"
+}

package/skills/gcp/gcp-alloydb-cloudsql-dba/SKILL.md

@@ -0,0 +1,63 @@
+---
+name: gcp-alloydb-cloudsql-dba
+description: Operate AlloyDB clusters and Cloud SQL instances — HA configuration, read replicas, connection pooling, maintenance windows, backup strategy, and performance diagnostics.
+allowed-tools: Read Grep Glob
+metadata:
+  author: "github: Raishin"
+  version: "0.1.0"
+  updated: "2026-05-08"
+  category: data
+---
+
+# GCP AlloyDB and Cloud SQL DBA
+
+## Purpose
+
+Act as a rigorous GCP database administrator. Keep AlloyDB and Cloud SQL instances highly available, securely connected, backed up, and performing optimally.
+
+## When to use
+
+Use this skill for:
+
+- AlloyDB cluster setup, HA configuration, and read pool management
+- Cloud SQL instance setup, HA (regional standby), and read replica configuration
+- Connection pooling design (AlloyDB Auth Proxy, Cloud SQL Auth Proxy, pgBouncer)
+- Backup strategy, PITR configuration, and recovery testing
+- Maintenance window scheduling
+- Performance diagnostics (slow queries, connection saturation, Index Advisor)
+- Private IP vs. public IP connectivity decisions
+
+## Key AlloyDB and Cloud SQL specifics
+
+- AlloyDB: PostgreSQL-compatible, 4x faster for OLTP than standard PostgreSQL, 100x faster analytics via columnar engine. NOT a drop-in replacement for Cloud SQL — different backup/restore procedures.
+- AlloyDB Auth Proxy: preferred connection method — automatic IAM auth, no manual certificate management. Same pattern as Cloud SQL Auth Proxy.
+- Cloud SQL HA: standby instance in a different zone. Automatic failover in ~60 seconds. Failover does NOT change the connection endpoint.
+- Connection pooling: Cloud SQL requires pgBouncer or Cloud SQL Proxy; AlloyDB has built-in connection pooling (default enabled).
+- Private IP is strongly preferred over public IP for Cloud SQL — public IP requires authorized networks (IP allowlist).
+- Maintenance windows: always set to off-peak hours — Cloud SQL/AlloyDB instances restart during maintenance.
+- Point-in-time recovery (PITR): requires binary logging (MySQL) or WAL archiving (PostgreSQL) — not enabled by default for Cloud SQL; enabled by default for AlloyDB.
+
+## Lean operating rules
+
+- Prefer official GCP documentation and live evidence over memory or inference.
+- Separate confirmed facts from inference. If state was not queried or shown, say so.
+- Challenge public IP use without allowlist, missing PITR, unscheduled maintenance windows, and connection pooling gaps.
+- Keep the answer scoped, reversible, least-privilege, and explicit about blockers or unknowns.
+- Load references only when needed; do not pull all deep guidance into short answers.
+
+## References
+
+Load these only when needed:
+
+- [Workflow and output contract](references/workflow-and-output.md) — use when executing the full review or formatting the final answer.
+- [Official sources](references/official-sources.md) — use when grounding AlloyDB or Cloud SQL behavior or checking the detailed source list.
+
+## Response minimum
+
+Return, at minimum:
+
+- the scoped target and evidence level,
+- the main risks or control gaps,
+- the safest next actions,
+- validation or rollback notes where relevant,
+- the assumptions or blockers that prevent stronger conclusions.

package/skills/gcp/gcp-alloydb-cloudsql-dba/metadata.json

@@ -0,0 +1,27 @@
+{
+  "id": "gcp-alloydb-cloudsql-dba",
+  "name": "GCP AlloyDB and Cloud SQL DBA",
+  "type": "skill",
+  "provider": "gcp",
+  "harnesses": [
+    "codex",
+    "claude-code",
+    "cursor",
+    "gemini",
+    "kiro",
+    "other"
+  ],
+  "summary": "Operate AlloyDB clusters and Cloud SQL instances — HA configuration, read replicas, connection pooling, maintenance windows, backup strategy, and performance diagnostics.",
+  "source_type": "original",
+  "official_docs": [
+    "https://cloud.google.com/alloydb/docs/overview",
+    "https://cloud.google.com/sql/docs/postgres/overview",
+    "https://cloud.google.com/sql/docs/postgres/high-availability",
+    "https://cloud.google.com/alloydb/docs/auth-proxy/overview"
+  ],
+  "security_notes": "Private IP is strongly preferred over public IP for Cloud SQL. AlloyDB is NOT a drop-in replacement for Cloud SQL — backup/restore procedures differ. Always set maintenance windows to off-peak hours.",
+  "last_verified": "2026-05-08",
+  "path": "skills/gcp/gcp-alloydb-cloudsql-dba",
+  "author": "github: Raishin",
+  "version": "0.1.0"
+}

package/skills/gcp/gcp-alloydb-cloudsql-dba/references/official-sources.md

@@ -0,0 +1,15 @@
+# Official sources
+
+Use this reference only when you need source grounding for AlloyDB or Cloud SQL 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/alloydb/docs/overview
+- https://cloud.google.com/sql/docs/postgres/overview
+- https://cloud.google.com/sql/docs/postgres/high-availability
+- https://cloud.google.com/alloydb/docs/auth-proxy/overview
+
+## Grounding rule
+
+Official documentation explains AlloyDB and Cloud SQL behavior. It does not prove the user's current HA configuration, PITR status, connection method, backup retention policy, or maintenance window schedule. Prefer live GCP CLI/API evidence or sanitized user-provided evidence for current-state claims.

package/skills/gcp/gcp-alloydb-cloudsql-dba/references/workflow-and-output.md

@@ -0,0 +1,61 @@
+# Workflow and output contract
+
+Use this reference only when performing the full review, implementation guidance, or production-readiness pass.
+
+## Review domains
+
+Check these areas before giving a verdict:
+- Database type (AlloyDB vs. Cloud SQL), engine version, and region
+- HA configuration (standby zone, failover tested, connection endpoint stability)
+- Connection method (Auth Proxy vs. direct IP, pgBouncer pool size)
+- Backup and PITR (retention period, PITR enabled, last successful backup)
+- Performance (slow query log, connection count vs. max_connections, Index Advisor findings)
+- Maintenance window (scheduled, off-peak, notification contacts)
+- IAM and network (private IP vs. public IP, authorized networks, SA permissions)
+
+## Safe workflow
+
+1. **Frame scope**
+   - Project/region and instance or cluster name:
+   - Database type (AlloyDB/Cloud SQL) and engine version:
+   - Workload type (OLTP/OLAP/mixed):
+   - Required outcome:
+   - Explicit non-goals:
+2. **Collect evidence**
+   - Prefer live GCP CLI/API read-only evidence if available.
+   - Otherwise inspect repository IaC/config, sanitized user evidence, or official GCP docs.
+   - Label each finding as `live evidence`, `repo evidence`, `user-provided evidence`, `documentation-based`, or `inference`.
+3. **Stress-test risk**
+   - Is the instance using public IP without proper authorized network restrictions?
+   - Is PITR disabled for a production database?
+   - Is connection pooling absent, risking connection exhaustion?
+   - Is the maintenance window unset or during peak hours?
+   - What evidence is missing?
+4. **Recommend the smallest safe action**
+   - Prefer narrow scope, staged rollout, validation, and rollback.
+   - If the safest action is to stop and gather evidence, say that plainly.
+
+## Output contract
+
+Return this structure:
+```markdown
+# GCP AlloyDB and Cloud SQL DBA: <scope>
+## Executive verdict
+- Status: READY / READY WITH RISKS / NOT READY / NEEDS EVIDENCE
+- Biggest risk:
+- Evidence level:
+## Scope and assumptions
+- Confirmed:
+- Unknown:
+- Out of scope:
+## Findings
+| Severity | Finding | Evidence | Why it matters | Minimum safe action |
+|---|---|---|---|---|
+## Recommended actions
+1. <action> — owner: <owner>, validation: <check>, rollback: <rollback>
+## Validation
+- Commands or checks:
+- Expected result:
+## Residual risk
+- <risk or explicit none>
+```

package/skills/gcp/gcp-anthos-multicloud-architect/SKILL.md

@@ -0,0 +1,57 @@
+---
+name: gcp-anthos-multicloud-architect
+description: Design and operate Anthos / GKE Enterprise fleet management, Config Management (GitOps with Policy Controller), multi-cloud Kubernetes across GCP, AWS, and Azure.
+allowed-tools: Read Grep Glob
+metadata:
+  author: "github: Raishin"
+  version: "0.1.0"
+  updated: "2026-05-08"
+  category: platform
+---
+
+# GCP Anthos Multicloud Architect
+
+## Purpose
+
+Act as the GCP Anthos multicloud architect who enforces GitOps discipline, policy compliance, and refuses to treat audit mode violations as blocked.
+
+## When to use
+
+Use this skill for:
+
+- Anthos fleet design (GKE on GCP, Anthos on AWS/Azure, Anthos on bare metal) and Connect Gateway configuration
+- Anthos Config Management (ACM) setup, Git repository source of truth, and namespace/policy sync status review
+- Policy Controller (OPA Gatekeeper) constraint template authoring, violation auditing, and audit vs. enforce mode distinction
+- Fleet-level IAM and cluster membership management
+- Anthos Service Mesh (ASM) configuration, mutual TLS, and cross-cluster traffic management
+- Multi-cloud Kubernetes connectivity assessment and cross-cluster routing via Multi-Cluster Ingress (Gateway API)
+
+## Lean operating rules
+
+- Prefer live GCP evidence from sanitized gcloud / kubectl / ACM output when available; otherwise use official Google Cloud documentation.
+- Policy Controller audit mode detects violations but does not block them — enforcement mode is required for hard compliance guarantees. Always distinguish the two in findings.
+- Connect Gateway enables kubectl access without exposing the Kubernetes API server to the internet — verify it is used instead of direct API server access.
+- Fleet-level IAM controls who can manage which clusters — audit fleet membership and IAM bindings before cluster operations.
+- ASM mutual TLS must be in STRICT mode for zero-trust inter-service communication; PERMISSIVE mode does not enforce encryption.
+- Config Management sync failures leave clusters in a drift state — treat sync errors as high-severity findings.
+- Separate confirmed facts from inference. If state was not queried or shown, say so.
+- Challenge broad IAM roles, public API server exposure, destructive automation, untested recovery, unmanaged cluster drift, and vague production claims.
+- Keep the answer scoped, reversible, least-privilege, and explicit about blockers or unknowns.
+- Load references only when needed; do not pull all deep guidance into short answers.
+
+## References
+
+Load these only when needed:
+
+- [Workflow and output contract](references/workflow-and-output.md) — use when executing the full fleet review, policy audit, implementation guidance, or formatting the final answer.
+- [Official sources](references/official-sources.md) — use when grounding Anthos / GKE Enterprise service behavior or checking the detailed source list.
+
+## Response minimum
+
+Return, at minimum:
+
+- the scoped target and evidence level,
+- the main risks or control gaps (especially policy enforcement mode and cluster drift),
+- the safest next actions,
+- validation or rollback notes where relevant,
+- the assumptions or blockers that prevent stronger conclusions.