@raishin/vanguard-frontier-agentic 1.4.0 → 1.6.0

package/skills/gcp/gcp-support-incident-coordinator/SKILL.md

@@ -0,0 +1,59 @@
+---
+name: gcp-support-incident-coordinator
+description: Coordinate GCP support incidents — case creation with correct severity, Premium/Enhanced Support SLA enforcement, TAM escalation path, status page monitoring, internal stakeholder communication, and post-incident evidence packaging.
+allowed-tools: Read Grep Glob
+metadata:
+  author: "github: Raishin"
+  version: "0.1.0"
+  updated: "2026-05-09"
+  category: observability
+---
+
+# GCP Support Incident Coordinator
+
+## Purpose
+
+Act as the GCP support incident coordinator who ensures support cases are filed with the correct severity, evidence is scrubbed before submission, TAM escalation is triggered for P0, and the PIR is completed on time.
+
+## When to use
+
+Use this skill for:
+
+- GCP support case severity classification (Severity 1–4 mapping to business impact)
+- Premium/Enhanced Support SLA tracking and breach escalation
+- TAM contact protocol for P0 incidents (phone escalation over case portal)
+- Evidence collection and PII scrubbing checklist before support case submission
+- Managed Incident (MI) detection and coordination with Google's incident response
+- Stakeholder communication template for internal and customer-facing updates
+- Post-incident review (PIR) coordination within 5 business days for P0/P1
+- SLA credit documentation for breached response SLAs
+
+## Lean operating rules
+
+- Prefer live GCP evidence from sanitized Cloud Monitoring, Cloud Logging, and status.google.com output when available; otherwise use official Google Cloud documentation.
+- Support case severity must match business impact — filing Severity 3 for a production outage wastes SLA time; do not underclassify.
+- TAM escalation for P0 requires phone contact, not just case portal updates — case portal-only escalation for P0 is slower by design.
+- Evidence submitted to GCP support must be scrubbed — project IDs, regions, and service names are safe; raw logs with user data, credentials, or PII are not.
+- Check status.google.com and the support portal for Managed Incident declarations before assuming the issue is user-side.
+- PIR for P0/P1 is due within 5 business days — coordinate with GCP account team for joint PIR when the platform was involved.
+- Separate confirmed facts from inference. If state was not queried or shown, say so.
+- Challenge case severity downgrades without business impact justification, evidence submissions without PII scrubbing, and PIR deferrals past the 5-day window.
+- Keep the answer scoped, timely, and explicit about SLA timers and escalation triggers.
+- 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 support incident coordination, case creation, or PIR planning.
+- [Official sources](references/official-sources.md) — use when grounding GCP support SLA, Managed Incident, and status page behavior or checking the detailed source list.
+
+## Response minimum
+
+Return, at minimum:
+
+- the incident scope and GCP platform status check result,
+- the support case severity classification and evidence scrubbing checklist,
+- the TAM escalation trigger and contact method,
+- the SLA timer start and next follow-up deadline,
+- the assumptions or blockers that prevent stronger conclusions.

package/skills/gcp/gcp-support-incident-coordinator/metadata.json

@@ -0,0 +1,27 @@
+{
+  "id": "gcp-support-incident-coordinator",
+  "name": "GCP Support Incident Coordinator",
+  "type": "skill",
+  "provider": "gcp",
+  "harnesses": [
+    "codex",
+    "claude-code",
+    "cursor",
+    "gemini",
+    "kiro",
+    "other"
+  ],
+  "summary": "Coordinate GCP support incidents — case creation with correct severity, Premium/Enhanced Support SLA enforcement, TAM escalation path, status page monitoring, internal stakeholder communication, and post-incident evidence packaging.",
+  "source_type": "original",
+  "official_docs": [
+    "https://cloud.google.com/support/docs/overview",
+    "https://cloud.google.com/support/docs/severity-definitions",
+    "https://status.google.com/",
+    "https://cloud.google.com/support/docs/managed-incident"
+  ],
+  "security_notes": "GCP support case attachments are accessible to Google support engineers — never attach files containing customer PII, credentials, or unredacted production logs. Premium Support SLA is contractual — document SLA breach timestamps with case numbers for potential SLA credits.",
+  "last_verified": "2026-05-09",
+  "path": "skills/gcp/gcp-support-incident-coordinator",
+  "author": "github: Raishin",
+  "version": "0.1.0"
+}

package/skills/gcp/gcp-support-incident-coordinator/references/official-sources.md

@@ -0,0 +1,17 @@
+# Official sources
+
+Use this reference only when you need source grounding for GCP support SLA, Managed Incident process, and status page behavior or the detailed source list.
+
+## Google Cloud documentation
+
+Use these as starting points, not as proof of the user's live GCP incident state:
+- https://cloud.google.com/support/docs/overview
+- https://cloud.google.com/support/docs/severity-definitions
+- https://status.google.com/
+- https://cloud.google.com/support/docs/managed-incident
+- https://cloud.google.com/support/docs/premium-support
+- https://cloud.google.com/support/docs/best-practices
+
+## Grounding rule
+
+Official documentation explains GCP support SLA tiers and Managed Incident behavior. It does not prove the current incident scope, whether a Managed Incident has been declared, or the user's TAM contact availability. Prefer live evidence (status.google.com check, support portal case status) over documentation-based assumptions during active support incidents.

package/skills/gcp/gcp-support-incident-coordinator/references/workflow-and-output.md

@@ -0,0 +1,64 @@
+# Workflow and output contract
+
+Use this reference only when performing the full support incident coordination, case creation checklist, TAM escalation, or PIR planning.
+
+## Coordination domains
+
+Check these areas before giving a case coordination verdict:
+- Incident scope: affected services, regions, user populations, and business impact
+- GCP platform status: status.google.com and Managed Incident (MI) declaration check
+- Case severity: Severity 1 (production down), 2 (major impact), 3 (partial impact), 4 (general guidance)
+- Evidence scrubbing: PII removal, credential removal, log sanitization before submission
+- TAM escalation: P0 requires phone contact; P1 may require case escalation flag
+- SLA tracking: Premium Sev1 = 15 min response, Sev2 = 4 hours, Sev3 = 8 hours, Sev4 = 24 hours
+- Communication cadence: internal stakeholder updates every 30 min for P0, 1 hour for P1
+- PIR coordination: within 5 business days for P0/P1, joint with GCP account team if platform involved
+
+## Safe workflow
+
+1. **Frame scope**
+   - Service(s) affected and user impact:
+   - First symptom and timestamp:
+   - GCP support tier (Premium/Enhanced/Standard):
+   - Business impact (revenue, users, SLA):
+2. **Check platform status**
+   - status.google.com — label result as live evidence.
+   - Support portal — check for active Managed Incident declaration.
+3. **Create support case**
+   - Set severity matching business impact.
+   - Attach only scrubbed evidence (no PII, no credentials).
+   - Record case number and creation timestamp.
+4. **Track SLA and escalate**
+   - Log expected first response deadline.
+   - If SLA breached: escalate to TAM via phone for P0, case portal escalation flag for P1+.
+   - Document SLA breach timestamp and case number for credit claim.
+
+## Output contract
+
+Return this structure:
+```markdown
+# GCP Support Incident Coordinator: <incident title>
+## Executive verdict
+- Incident scope: <affected services and user impact>
+- GCP platform status: <clean / MI declared / degradation>
+- Support case severity: Severity <1/2/3/4>
+- Evidence level:
+## Case creation checklist
+- [ ] Business impact documented
+- [ ] Evidence scrubbed (no PII, no credentials)
+- [ ] Case filed with correct severity
+- [ ] Case number recorded: <case number>
+- [ ] Case creation timestamp: <timestamp>
+## TAM escalation
+- TAM contact required: <yes/no> — trigger: <P0 default / SLA breach>
+- Contact method: <phone / case portal escalation flag>
+- SLA first response due: <timestamp>
+## Stakeholder communication
+- Next internal update: <time>
+- Template: "Incident update [<time>]: <service> experiencing <impact>. GCP case #<number> filed. Next update in <interval>."
+## Post-incident review
+- PIR due: <5 business days from resolution for P0/P1>
+- Joint PIR with GCP: <yes/no — required if platform involved>
+## Residual risk
+- <risk or explicit none>
+```

package/skills/gcp/gcp-ticket-triage-escalation-coordinator/SKILL.md

@@ -0,0 +1,58 @@
+---
+name: gcp-ticket-triage-escalation-coordinator
+description: Triage GCP operational alerts, incidents, and support tickets — P0/P1/P2/P3 classification, GCP Premium/Enhanced Support SLA enforcement, war room coordination, evidence collection from Cloud Monitoring and Cloud Logging, and safe escalation paths.
+allowed-tools: Read Grep Glob
+metadata:
+  author: "github: Raishin"
+  version: "0.1.0"
+  updated: "2026-05-09"
+  category: observability
+---
+
+# GCP Ticket Triage Escalation Coordinator
+
+## Purpose
+
+Act as the GCP incident triage coordinator who refuses to delay escalation waiting for root cause and insists on parallel evidence collection and mitigation tracks from the first minute of a P0.
+
+## When to use
+
+Use this skill for:
+
+- P0/P1/P2/P3 incident classification based on business impact and GCP service scope
+- GCP Premium/Enhanced Support SLA tracking and TAM escalation coordination
+- War room formation and stakeholder communication planning
+- Cloud Monitoring and Cloud Logging evidence collection checklists
+- GCP platform status page triage (status.google.com) to distinguish platform vs. user-side incidents
+- Alert policy interpretation and root cause hypothesis generation
+- Post-incident review scheduling and action item assignment
+
+## Lean operating rules
+
+- Prefer live GCP evidence from sanitized Cloud Monitoring and Cloud Logging output when available; otherwise use official Google Cloud documentation.
+- P0 (complete service outage with business impact) requires immediate war room formation and Severity 1 GCP support ticket — do not wait for root cause before escalating.
+- GCP Premium Support SLA for Severity 1 is 15-minute initial response — escalate to TAM via phone if no case response within 15 minutes.
+- Evidence collection and mitigation run in parallel — never sacrifice evidence for speed; you need it for the post-incident review.
+- Always check status.google.com before concluding the issue is user-side — GCP platform incidents are common.
+- Cloud Monitoring alerts fire on metric conditions — interpret them in the context of related metrics and logs, not in isolation.
+- Separate confirmed facts from inference. If state was not queried or shown, say so.
+- Challenge delayed escalation, missing evidence trails, single-track mitigation (mitigation only, no evidence), and conclusions drawn from alert conditions alone.
+- Keep the answer scoped, timely, and explicit about escalation triggers and SLA timers.
+- 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 triage, escalation coordination, or post-incident review planning.
+- [Official sources](references/official-sources.md) — use when grounding GCP support SLA, monitoring, and logging service behavior or checking the detailed source list.
+
+## Response minimum
+
+Return, at minimum:
+
+- the incident classification (P0/P1/P2/P3) and evidence level,
+- the GCP platform status check result,
+- the parallel evidence collection and mitigation tracks,
+- the escalation path with SLA timer start,
+- the assumptions or blockers that prevent stronger conclusions.

package/skills/gcp/gcp-ticket-triage-escalation-coordinator/metadata.json

@@ -0,0 +1,27 @@
+{
+  "id": "gcp-ticket-triage-escalation-coordinator",
+  "name": "GCP Ticket Triage Escalation Coordinator",
+  "type": "skill",
+  "provider": "gcp",
+  "harnesses": [
+    "codex",
+    "claude-code",
+    "cursor",
+    "gemini",
+    "kiro",
+    "other"
+  ],
+  "summary": "Triage GCP operational alerts, incidents, and support tickets — P0/P1/P2/P3 classification, GCP Premium/Enhanced Support SLA enforcement, war room coordination, evidence collection from Cloud Monitoring and Cloud Logging, and safe escalation paths.",
+  "source_type": "original",
+  "official_docs": [
+    "https://cloud.google.com/support/docs/severity-definitions",
+    "https://cloud.google.com/monitoring/alerts/using-alerting-ui",
+    "https://cloud.google.com/logging/docs/view/logs-explorer-interface",
+    "https://status.google.com/"
+  ],
+  "security_notes": "GCP support tickets may require sharing sanitized logs or configuration — scrub project IDs, IP addresses, and customer data before sharing with Google support. War room communication channels must be secure — use dedicated incident Slack/Meet channels, not public ones.",
+  "last_verified": "2026-05-09",
+  "path": "skills/gcp/gcp-ticket-triage-escalation-coordinator",
+  "author": "github: Raishin",
+  "version": "0.1.0"
+}

package/skills/gcp/gcp-ticket-triage-escalation-coordinator/references/official-sources.md

@@ -0,0 +1,18 @@
+# Official sources
+
+Use this reference only when you need source grounding for GCP support SLA, incident management, monitoring, and logging service behavior or the detailed source list.
+
+## Google Cloud documentation
+
+Use these as starting points, not as proof of the user's live GCP incident state:
+- https://cloud.google.com/support/docs/severity-definitions
+- https://cloud.google.com/monitoring/alerts/using-alerting-ui
+- https://cloud.google.com/logging/docs/view/logs-explorer-interface
+- https://status.google.com/
+- https://cloud.google.com/support/docs/overview
+- https://cloud.google.com/support/docs/managed-incident
+- https://cloud.google.com/trace/docs/overview
+
+## Grounding rule
+
+Official documentation explains GCP support SLA tiers and monitoring service behavior. It does not prove the user's current incident scope, alert root cause, or platform status. Prefer live evidence (status.google.com check, sanitized monitoring output) over documentation-based assumptions during active incidents.

package/skills/gcp/gcp-ticket-triage-escalation-coordinator/references/workflow-and-output.md

@@ -0,0 +1,71 @@
+# Workflow and output contract
+
+Use this reference only when performing the full triage, escalation coordination, war room management, or post-incident review planning.
+
+## Triage domains
+
+Check these areas before classifying an incident:
+- Impact scope: user-facing vs. internal, percentage of traffic affected, geographic scope
+- GCP platform status: status.google.com check for active incidents or degradations in relevant services/regions
+- P-level classification: P0 (complete outage, business impact), P1 (major impact, partial outage), P2 (partial impact, degraded service), P3 (minor impact, workaround available)
+- Evidence trails: Cloud Monitoring dashboards, Cloud Logging queries, Cloud Trace, structured error logs
+- Mitigation options: rollback, traffic rerouting, feature flag disable, capacity scaling
+- Escalation triggers: support case severity, TAM contact, executive notification
+- War room structure: incident commander, communications lead, mitigation engineer, evidence collector
+
+## Safe workflow
+
+1. **Frame scope**
+   - Service(s) affected and impact radius:
+   - First symptom observed and timestamp:
+   - Business impact (revenue, users, SLA):
+   - Escalation owner and incident commander:
+2. **Collect evidence in parallel with mitigation**
+   - Check status.google.com immediately — label result as live evidence.
+   - Pull Cloud Monitoring dashboards for error rate, latency, saturation.
+   - Query Cloud Logging for error spikes correlated with incident start time.
+   - Label each finding as `live evidence`, `user-provided evidence`, `documentation-based`, or `inference`.
+3. **Classify and escalate**
+   - P0: immediate war room + Severity 1 GCP support case + TAM contact.
+   - P1: Severity 2 GCP support case + engineering lead notification.
+   - P2: Severity 3 GCP support case + team notification.
+   - P3: Severity 4 GCP support case + ticket tracking.
+4. **Track SLA timers**
+   - Premium Severity 1: 15-minute initial response SLA — escalate to TAM if breached.
+   - Log case creation timestamp and first response timestamp.
+
+## Output contract
+
+Return this structure:
+```markdown
+# GCP Ticket Triage Escalation Coordinator: <incident title>
+## Executive verdict
+- Priority: P0 / P1 / P2 / P3
+- Impact: <summary of affected users, services, regions>
+- GCP platform status: <clean / degradation detected / incident active>
+- Evidence level:
+## Scope and assumptions
+- Confirmed:
+- Unknown:
+- Out of scope:
+## Evidence collection checklist
+- [ ] status.google.com checked
+- [ ] Cloud Monitoring error rate dashboard reviewed
+- [ ] Cloud Logging error spike query executed
+- [ ] Cloud Trace sampled for latency distribution
+## Mitigation options
+1. <option> — risk: <risk>, rollback: <rollback>
+## Escalation path
+- GCP support case: Severity <1/2/3/4>, case created at: <timestamp>
+- TAM contact required: <yes/no> — trigger: <SLA breach / P0 default>
+- SLA timer: <start time> — response due by: <deadline>
+## War room and stakeholders
+- Incident commander: <owner>
+- Communications lead: <owner>
+- Next stakeholder update: <time>
+## Post-incident review
+- PIR due: <5 business days from resolution for P0/P1>
+- Action items: <TBD at resolution>
+## Residual risk
+- <risk or explicit none>
+```

package/skills/gcp/gcp-vertex-ai-mlops-engineer/SKILL.md

@@ -0,0 +1,81 @@
+---
+name: gcp-vertex-ai-mlops-engineer
+description: Manage Vertex AI Training jobs (GPU/TPU cost governance), Vertex AI Pipelines, Model Registry, Feature Store, Endpoints, and Gemini API integration for production MLOps.
+allowed-tools: Read Grep Glob
+metadata:
+  author: "github: Raishin"
+  version: "0.2.0"
+  updated: "2026-05-09"
+  category: ai
+---
+
+# GCP Vertex AI MLOps Engineer
+
+## Purpose
+
+Act as the GCP Vertex AI MLOps engineer who enforces cost governance, prevents silent data corruption, and refuses to treat inference as production evidence.
+
+## SDK Guidance
+
+### MLOps platform operations (model training, pipelines, experiments)
+Use `google-cloud-aiplatform` Python SDK for:
+- Vertex AI Pipelines (Kubeflow Pipelines)
+- Vertex AI Training (custom jobs, hyperparameter tuning)
+- Vertex AI Model Registry, Endpoints, Feature Store
+- Vertex AI Experiments and Metadata
+
+```python
+from google.cloud import aiplatform
+aiplatform.init(project="my-project", location="us-central1")
+```
+
+### Inference / Gemini API calls from application code
+For calling hosted Gemini models from application code (NOT from pipeline components), use the **unified Gen AI SDK** instead — the `google-cloud-aiplatform` SDK for inference is deprecated:
+
+| Task | Correct SDK |
+|---|---|
+| Training, pipelines, model registry, feature store | `google-cloud-aiplatform` |
+| Calling Gemini models from application code | `google-genai` (Python) / `@google/genai` (JS) |
+| Migrating from `google-generativeai` or `@google-cloud/vertexai` | Migrate to `google-genai` / `@google/genai` |
+
+The unified Gen AI SDK (`google-genai`) targets the Agent Platform (formerly Vertex AI) endpoint when `GOOGLE_GENAI_USE_VERTEXAI=true` is set.
+
+## When to use
+
+Use this skill for:
+
+- Vertex AI Training job cost audits (GPU/TPU, A100/H100 hang detection, max_run_time enforcement)
+- Vertex AI Pipelines design, execution health, and KFP v2 / TFX pipeline component cost review
+- Model Registry version management, traffic split configuration, and A/B testing on Endpoints
+- Feature Store freshness audits (online vs. offline store sync, silent corruption risk)
+- Gemini API via Vertex AI enterprise integration (SLA, data privacy, vs. AI Studio differences)
+- Managed Datasets and AutoML vs. custom training trade-off analysis
+
+## Lean operating rules
+
+- Prefer live GCP evidence from sanitized gcloud / Vertex AI SDK output when available; otherwise use official Google Cloud documentation.
+- Training jobs have NO automatic cost cap — a hung GPU job (A100/H100) can cost $30-$120/hour undetected. Always verify max_run_time is set.
+- Feature Store write operations are not reversible. Incorrect feature values silently corrupt training data — require validation before writes.
+- Gemini API via Vertex AI has enterprise SLAs and data privacy commitments not present in Gemini via AI Studio; always confirm which endpoint is in use.
+- Pipeline components run in separate containers — each container is a separate Compute charge; include container cost in pipeline cost estimates.
+- Separate confirmed facts from inference. If state was not queried or shown, say so.
+- Challenge broad IAM roles, public endpoints, destructive automation, untested recovery, hidden cost, 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 review, MLOps audit, implementation guidance, or formatting the final answer.
+- [Official sources](references/official-sources.md) — use when grounding GCP Vertex AI 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 cost and data correctness),
+- the safest next actions,
+- validation or rollback notes where relevant,
+- the assumptions or blockers that prevent stronger conclusions.

package/skills/gcp/gcp-vertex-ai-mlops-engineer/metadata.json

@@ -0,0 +1,27 @@
+{
+  "id": "gcp-vertex-ai-mlops-engineer",
+  "name": "GCP Vertex AI MLOps Engineer",
+  "type": "skill",
+  "provider": "gcp",
+  "harnesses": [
+    "codex",
+    "claude-code",
+    "cursor",
+    "gemini",
+    "kiro",
+    "other"
+  ],
+  "summary": "Manage Vertex AI Training jobs (GPU/TPU cost governance), Vertex AI Pipelines, Model Registry, Feature Store, Endpoints, and Gemini API integration for production MLOps.",
+  "source_type": "original",
+  "official_docs": [
+    "https://cloud.google.com/vertex-ai/docs/start/introduction-unified-platform",
+    "https://cloud.google.com/vertex-ai/docs/pipelines/introduction",
+    "https://cloud.google.com/vertex-ai/docs/model-registry/introduction",
+    "https://cloud.google.com/vertex-ai/docs/featurestore/overview"
+  ],
+  "security_notes": "Training jobs have no automatic cost cap — always verify max_run_time is set. Feature Store writes are irreversible and can silently corrupt training data. Gemini via Vertex AI has different privacy commitments than via AI Studio.",
+  "last_verified": "2026-05-08",
+  "path": "skills/gcp/gcp-vertex-ai-mlops-engineer",
+  "author": "github: Raishin",
+  "version": "0.2.0"
+}

package/skills/gcp/gcp-vertex-ai-mlops-engineer/references/official-sources.md

@@ -0,0 +1,18 @@
+# Official sources
+
+Use this reference only when you need source grounding for GCP Vertex AI service behavior or the detailed source list.
+
+## Google Cloud documentation
+
+Use these as starting points, not as proof of the user's live GCP state:
+- https://cloud.google.com/vertex-ai/docs/start/introduction-unified-platform
+- https://cloud.google.com/vertex-ai/docs/pipelines/introduction
+- https://cloud.google.com/vertex-ai/docs/model-registry/introduction
+- https://cloud.google.com/vertex-ai/docs/featurestore/overview
+- https://cloud.google.com/vertex-ai/docs/training/custom-training
+- https://cloud.google.com/vertex-ai/docs/predictions/overview
+- https://cloud.google.com/vertex-ai/docs/generative-ai/start/quickstarts/quickstart-multimodal
+
+## Grounding rule
+
+Official documentation explains GCP Vertex AI service behavior. It does not prove the user's current project, quota, resource configuration, IAM boundary, pricing, or operational state. Prefer live GCP CLI/SDK evidence or sanitized user-provided evidence for current-state claims.

package/skills/gcp/gcp-vertex-ai-mlops-engineer/references/workflow-and-output.md

@@ -0,0 +1,60 @@
+# Workflow and output contract
+
+Use this reference only when performing the full MLOps review, cost audit, implementation guidance, or production-readiness pass.
+
+## Review domains
+
+Check these areas before giving a verdict:
+- Training job inventory: status, accelerator type, estimated cost, max_run_time presence
+- Pipeline execution: component status, container charges, failed runs, retry behavior
+- Model Registry: version count, deployed versions, aliases, deprecation policy
+- Endpoints: traffic split percentages, latency percentiles, autoscaling config
+- Feature Store: online/offline sync lag, feature freshness, write validation gates
+- Gemini API: which endpoint (Vertex AI vs. AI Studio), SLA tier, data privacy commitment
+- IAM: service account permissions, Workload Identity Federation, over-privilege gaps
+
+## Safe workflow
+
+1. **Frame scope**
+   - Project/region/environment:
+   - Business criticality and owner:
+   - Data classification and compliance driver:
+   - Required outcome:
+   - Explicit non-goals:
+2. **Collect evidence**
+   - Prefer live GCP CLI/SDK read-only evidence if available.
+   - Otherwise inspect repository IaC/config, sanitized user evidence, or official Google Cloud docs.
+   - Label each finding as `live evidence`, `repo evidence`, `user-provided evidence`, `documentation-based`, or `inference`.
+3. **Stress-test risk**
+   - What training jobs lack max_run_time and could hang indefinitely?
+   - What Feature Store writes lack validation and could silently corrupt training data?
+   - What IAM bindings grant broader access than needed?
+   - 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 Vertex AI MLOps Engineer: <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-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"
+}