@raishin/vanguard-frontier-agentic 1.4.0 → 1.6.0

package/skills/gcp/gcp-gke-platform-operator/assets/hpa-example.yaml

@@ -0,0 +1,28 @@
+# Horizontal Pod Autoscaler example for a web service.
+# Scales between 2 and 20 replicas based on CPU utilization.
+# kubectl apply -f hpa-example.yaml
+apiVersion: autoscaling/v2
+kind: HorizontalPodAutoscaler
+metadata:
+  name: web-hpa
+  namespace: default
+spec:
+  scaleTargetRef:
+    apiVersion: apps/v1
+    kind: Deployment
+    name: web-deployment   # Replace with your deployment name
+  minReplicas: 2
+  maxReplicas: 20
+  metrics:
+    - type: Resource
+      resource:
+        name: cpu
+        target:
+          type: Utilization
+          averageUtilization: 70
+    - type: Resource
+      resource:
+        name: memory
+        target:
+          type: Utilization
+          averageUtilization: 80

package/skills/gcp/gcp-gke-platform-operator/assets/workload-identity-pod.yaml

@@ -0,0 +1,20 @@
+# Test pod for verifying Workload Identity Federation is correctly configured.
+# Replace KSA_NAME, NAMESPACE, and PROJECT_ID with actual values.
+# kubectl apply -f workload-identity-pod.yaml
+# Then: kubectl exec -it workload-identity-test -- gcloud auth list
+apiVersion: v1
+kind: Pod
+metadata:
+  name: workload-identity-test
+  namespace: default  # Replace with your namespace
+spec:
+  serviceAccountName: workload-identity-ksa  # Replace with your KSA name
+  containers:
+    - name: test
+      image: gcr.io/google.com/cloudsdktool/cloud-sdk:slim
+      command: ["sleep", "infinity"]
+      resources:
+        requests:
+          cpu: "100m"
+          memory: "128Mi"
+  restartPolicy: Never

package/skills/gcp/gcp-gke-platform-operator/metadata.json

@@ -0,0 +1,27 @@
+{
+  "id": "gcp-gke-platform-operator",
+  "name": "GCP GKE Platform Operator",
+  "type": "skill",
+  "provider": "gcp",
+  "harnesses": [
+    "codex",
+    "claude-code",
+    "cursor",
+    "gemini",
+    "kiro",
+    "other"
+  ],
+  "summary": "Operate GKE clusters (Standard and Autopilot), manage node pools, configure Workload Identity, enforce Binary Authorization, plan node pool upgrades, and review cluster security posture.",
+  "source_type": "original",
+  "official_docs": [
+    "https://cloud.google.com/kubernetes-engine/docs/concepts/cluster-architecture",
+    "https://cloud.google.com/kubernetes-engine/docs/how-to/workload-identity",
+    "https://cloud.google.com/binary-authorization/docs/overview",
+    "https://cloud.google.com/kubernetes-engine/docs/concepts/release-channels"
+  ],
+  "security_notes": "Binary Authorization must be set to WARN mode before ENFORCE mode — enforce mode will break deployments if images are unsigned. Always prefer Workload Identity over mounted SA key files.",
+  "last_verified": "2026-05-08",
+  "path": "skills/gcp/gcp-gke-platform-operator",
+  "author": "github: Raishin",
+  "version": "0.2.0"
+}

package/skills/gcp/gcp-gke-platform-operator/references/official-sources.md

@@ -0,0 +1,15 @@
+# Official sources
+
+Use this reference only when you need source grounding for GKE 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/kubernetes-engine/docs/concepts/cluster-architecture
+- https://cloud.google.com/kubernetes-engine/docs/how-to/workload-identity
+- https://cloud.google.com/binary-authorization/docs/overview
+- https://cloud.google.com/kubernetes-engine/docs/concepts/release-channels
+
+## Grounding rule
+
+Official documentation explains GKE cluster behavior. It does not prove the user's current node pool version, Workload Identity binding state, Binary Authorization policy, or release channel enrollment. Prefer live GCP CLI/API evidence or sanitized user-provided evidence for current-state claims.

package/skills/gcp/gcp-gke-platform-operator/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:
+- Cluster type (Standard vs. Autopilot), Kubernetes version, and release channel
+- Node pool inventory (machine type, count, version, auto-upgrade, auto-repair)
+- Workload Identity: every workload SA annotation vs. mounted key files
+- Binary Authorization: policy mode (WARN vs. ENFORCE), attestor configuration
+- Network policies enabled and Pod Security Standards enforced
+- RBAC: no cluster-admin bindings for non-bootstrap accounts
+- Logging and monitoring: Cloud Logging and Cloud Monitoring enabled
+
+## Safe workflow
+
+1. **Frame scope**
+   - Project/cluster name/region:
+   - Cluster type (Standard/Autopilot):
+   - Kubernetes version and release channel:
+   - 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**
+   - Which pods use mounted SA key files instead of Workload Identity?
+   - Is Binary Authorization in WARN or ENFORCE mode? Are all production images attested?
+   - Are node pools on a version more than 2 minor versions behind the cluster master?
+   - Are network policies deployed to all namespaces?
+   - 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 GKE Platform Operator: <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-iac-change-safety-review/SKILL.md

@@ -0,0 +1,58 @@
+---
+name: gcp-iac-change-safety-review
+description: Review Terraform and Deployment Manager changes targeting GCP — blast radius analysis, destroy-operation detection, cross-project impact, state file conflicts, org policy drift, and rollback plan completeness.
+allowed-tools: Read Grep Glob
+metadata:
+  author: "github: Raishin"
+  version: "0.1.0"
+  updated: "2026-05-09"
+  category: delivery
+---
+
+# GCP IaC Change Safety Review
+
+## Purpose
+
+Act as the GCP IaC safety reviewer who refuses to allow applies with high blast radius, missing rollback plans, or unresolved state conflicts.
+
+## When to use
+
+Use this skill for:
+
+- Terraform plan review for GCP resources — blast radius classification, destroy and recreate detection, and approval gate guidance
+- Deployment Manager preview output analysis — resource change scope and rollback feasibility
+- Cross-project and cross-folder module impact assessment — Shared VPC, org policy, and org-level IAM binding changes
+- State file conflict diagnosis — stale remote state detection, state lock analysis, and safe resolution paths
+- Org policy drift detection — comparison between declared policy and live gcloud org-policies output
+- Rollback plan completeness audit — verifying state backup, reverse plan feasibility, and recovery procedure completeness
+- Approval gate requirements — determining whether change needs single or dual approval based on blast radius
+
+## Lean operating rules
+
+- Prefer sanitized terraform plan output, gcloud asset inventory snapshots, and Deployment Manager preview output as live evidence; fall back to official docs.
+- Treat any plan containing "will be destroyed" or resource recreation as high-blast-radius — require explicit approval and rollback plan before proceeding.
+- Cross-project and cross-folder Terraform modules that touch Shared VPC, org policies, or IAM bindings at org level are org-wide blast radius — require dual approval.
+- State file conflicts (stale remote state, state lock held) must be resolved before any apply — never suggest force-unlock without understanding the lock holder.
+- Never ask for service account keys, project IDs, customer data, backend bucket credentials, or workspace-specific values unless sanitized and required.
+- Separate confirmed facts from inference. If plan output was not provided or shown, say so.
+- Challenge broad IAM roles, missing rollback plans, unresolved state locks, and undocumented org-level change scope.
+- 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 IaC change review, blast radius assessment, or formatting the final answer.
+- [Official sources](references/official-sources.md) — use when grounding GCP IaC service behavior or checking the detailed source list.
+
+## Response minimum
+
+Return, at minimum:
+
+- the change summary and target resources with evidence level,
+- the blast radius classification (low/medium/high/org-wide),
+- destroy and recreate operations detected,
+- state conflict and drift risks,
+- rollback plan completeness assessment,
+- the safest next actions and approval requirements.

package/skills/gcp/gcp-iac-change-safety-review/metadata.json

@@ -0,0 +1,28 @@
+{
+  "id": "gcp-iac-change-safety-review",
+  "name": "GCP IaC Change Safety Review",
+  "type": "skill",
+  "provider": "gcp",
+  "harnesses": [
+    "codex",
+    "claude-code",
+    "cursor",
+    "gemini",
+    "kiro",
+    "other"
+  ],
+  "summary": "Review Terraform and Deployment Manager changes targeting GCP — blast radius analysis, destroy-operation detection, cross-project impact, state file conflicts, org policy drift, and rollback plan completeness.",
+  "source_type": "original",
+  "official_docs": [
+    "https://cloud.google.com/docs/terraform/best-practices-for-terraform",
+    "https://cloud.google.com/deployment-manager/docs/configuration/preview-configuration-file",
+    "https://cloud.google.com/asset-inventory/docs/overview",
+    "https://cloud.google.com/iam/docs/org-policy-overview",
+    "https://developer.hashicorp.com/terraform/cli/commands/plan"
+  ],
+  "security_notes": "Terraform state files contain sensitive resource attributes — backend bucket must use CMEK and uniform bucket-level access. Org-level IAM and org policy changes via Terraform have org-wide blast radius — require dual approval and tested rollback. Force-unlocking state under an active apply causes corruption.",
+  "last_verified": "2026-05-09",
+  "path": "skills/gcp/gcp-iac-change-safety-review",
+  "author": "github: Raishin",
+  "version": "0.1.0"
+}

package/skills/gcp/gcp-iac-change-safety-review/references/official-sources.md

@@ -0,0 +1,18 @@
+# Official sources
+
+Use this reference only when you need source grounding for GCP IaC change safety service behavior or the detailed source list.
+
+## Google Cloud and Terraform documentation
+
+Use these as starting points, not as proof of the user's live GCP state:
+- https://cloud.google.com/docs/terraform/best-practices-for-terraform
+- https://cloud.google.com/deployment-manager/docs/configuration/preview-configuration-file
+- https://cloud.google.com/asset-inventory/docs/overview
+- https://cloud.google.com/iam/docs/org-policy-overview
+- https://developer.hashicorp.com/terraform/cli/commands/plan
+- https://developer.hashicorp.com/terraform/language/state/locking
+- https://cloud.google.com/storage/docs/uniform-bucket-level-access
+
+## Grounding rule
+
+Official documentation explains GCP IaC service behavior and Terraform CLI semantics. It does not prove the user's current state lock status, live org policy configuration, or blast radius of a specific plan. Prefer sanitized terraform plan output, gcloud asset inventory snapshots, or Deployment Manager preview output for current-state claims.

package/skills/gcp/gcp-iac-change-safety-review/references/workflow-and-output.md

@@ -0,0 +1,67 @@
+# Workflow and output contract
+
+Use this reference only when performing the full IaC change safety review, blast radius assessment, or approval gate evaluation.
+
+## Review domains
+
+Check these areas before giving a verdict:
+- Change summary: resource types, counts, and target projects/folders/org
+- Blast radius: low (single resource, no cross-project impact), medium (multiple resources, same project), high (multi-project or recreate), org-wide (org policy, Shared VPC, org IAM)
+- Destroy and recreate operations: any resource with "must be replaced" or "will be destroyed" flags
+- Cross-project and org-level impact: Shared VPC host/service project bindings, org policy constraints, org-level IAM bindings
+- State file conflicts: stale remote state, held state locks, workspace mismatch
+- Org policy drift: declared constraints vs. live gcloud org-policies output
+- Rollback plan: pre-apply state backup, reverse plan feasibility, documented recovery steps, owner
+
+## Safe workflow
+
+1. **Frame scope**
+   - Target project/folder/org and environment:
+   - Change type (Terraform plan / Deployment Manager preview):
+   - Required outcome:
+   - Explicit non-goals:
+2. **Collect evidence**
+   - Prefer sanitized terraform plan output or Deployment Manager preview as live evidence.
+   - Otherwise inspect repository IaC/config, sanitized user evidence, or official docs.
+   - Label each finding as `live evidence`, `repo evidence`, `user-provided evidence`, `documentation-based`, or `inference`.
+3. **Stress-test risk**
+   - What resources are being destroyed or recreated?
+   - What changes cross project or org boundaries?
+   - Is the state file locked or stale?
+   - Is a rollback plan documented and feasible?
+   - 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 or approval, say that plainly.
+
+## Output contract
+
+Return this structure:
+```markdown
+# GCP IaC Change Safety Review: <scope>
+## Executive verdict
+- Status: SAFE TO APPLY / APPLY WITH CONDITIONS / BLOCKED / NEEDS EVIDENCE
+- Blast radius: low / medium / high / org-wide
+- Biggest risk:
+- Evidence level:
+## Scope and assumptions
+- Confirmed:
+- Unknown:
+- Out of scope:
+## Findings
+| Severity | Finding | Evidence | Why it matters | Minimum safe action |
+|---|---|---|---|---|
+## Destroy and recreate operations
+- <resource or explicit none>
+## Rollback plan assessment
+- Pre-apply state backup: <confirmed / not confirmed>
+- Reverse plan feasible: <yes / no / unknown>
+- Recovery steps documented: <yes / no>
+## Approval requirements
+- Required approvers: <single / dual / escalation>
+- Rationale:
+## Recommended actions
+1. <action> — owner: <owner>, validation: <check>, rollback: <rollback>
+## Residual risk
+- <risk or explicit none>
+```

package/skills/gcp/gcp-iam-least-privilege-review/SKILL.md

@@ -0,0 +1,58 @@
+---
+name: gcp-iam-least-privilege-review
+description: Audit GCP IAM bindings across the resource hierarchy (org/folder/project), identify overprivileged Service Accounts, review Workload Identity Federation configurations, evaluate org policy conditions, and recommend least-privilege remediation. Prefer gcp-secret-kms-lifecycle-steward for KMS/Secret Manager lifecycle design and gcp-vpc-service-controls-architect for perimeter access policy posture unless the request is primarily IAM binding surgery.
+allowed-tools: Read Grep Glob
+metadata:
+  author: "github: Raishin"
+  version: "0.1.0"
+  updated: "2026-05-08"
+  category: security
+---
+
+# GCP IAM Least Privilege Review
+
+## Purpose
+
+Act as the GCP IAM reviewer who assumes every org-level binding, SA key, and missing condition is a future incident until proven otherwise.
+
+## When to use
+
+Use this skill for:
+
+- IAM binding review at org, folder, or project level
+- Service Account design, impersonation chains, and key file audits
+- Workload Identity Federation configuration and migration from key-based auth
+- Org policy constraint gap analysis (`iam.disableServiceAccountKeyCreation`, `iam.allowedPolicyMemberDomains`, `constraints/iam.disableWorkloadIdentityClusterCreation`)
+- Custom role design, basic role replacement, and predefined role right-sizing
+- IAM condition design and review
+
+## Core Responsibilities
+
+- **Confirm hierarchy scope first.** IAM bindings in GCP cascade downward: a binding at org level applies to all folders, projects, and resources within. Never evaluate a binding in isolation without confirming where in the hierarchy it is set.
+- **Treat `iam.serviceAccounts.actAs` as impersonation.** Any principal with this permission on a Service Account can perform all actions that SA is authorized to do. Flag every binding granting this permission and verify it is least-privilege scoped.
+- **Flag every SA key file as high risk.** Service Account key files are long-lived, unrevocable until manually deleted, and bypass Workload Identity Federation controls. Always recommend migrating to WIF and flag key creation as a gap when the org policy `iam.disableServiceAccountKeyCreation` is absent.
+- **Prefer Workload Identity Federation.** WIF eliminates key file management and supports short-lived credential exchange. For GKE workloads prefer Workload Identity (bound to a KSA). For external workloads prefer WIF provider pools. Flag any key-based auth path that WIF can replace.
+- **Distinguish basic, predefined, and custom roles.** Basic roles (`roles/owner`, `roles/editor`, `roles/viewer`) grant hundreds of permissions and are legacy constructs — flag them in any production or sensitive binding. Predefined roles should still be reviewed for scope excess. Custom roles should be audited for permission creep.
+- **Flag org-level `securityAdmin` and `owner` bindings as critical.** `roles/iam.securityAdmin` at org level can modify any IAM policy in the org. `roles/owner` at org level has full control. Both are blast-radius findings requiring immediate escalation.
+- **Evaluate IAM conditions.** Condition-less bindings on sensitive roles indicate a gap. Recommend conditions scoping by resource type, resource name prefix, or request time where applicable. Note that conditions are not available on all resource types.
+- **Separate org policies from IAM bindings.** Org policies are preventive controls enforced by the Resource Manager — they block actions regardless of IAM. A missing org policy is a separate gap from an overprivileged IAM binding. Both must be addressed.
+- **Never request credentials.** Do not ask for SA key JSON, access tokens, project IDs tied to production workloads, customer data, org IDs, or any credential material. Work from sanitized exports, Terraform/Deployment Manager IaC, or structured user descriptions.
+- **Separate confirmed facts from inference.** If the current IAM state was not shown or queried, say so explicitly. Label each finding as `live evidence`, `user-provided sanitized evidence`, `documentation-based`, or `inference`.
+- **Keep scope tight and rollback explicit.** Every remediation recommendation must include the minimum change required, the validation step to confirm it worked, and the rollback procedure if the change breaks a dependent workload.
+
+## 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 GCP service behavior or checking the detailed source list.
+
+## Response minimum
+
+Return, at minimum:
+
+- the resource hierarchy scope and evidence level,
+- the overprivileged binding inventory and SA key findings,
+- the WIF assessment and org policy gaps,
+- the safest next actions with validation steps,
+- the assumptions or blockers that prevent stronger conclusions.

package/skills/gcp/gcp-iam-least-privilege-review/metadata.json

@@ -0,0 +1,28 @@
+{
+  "id": "gcp-iam-least-privilege-review",
+  "name": "GCP IAM Least Privilege Review",
+  "type": "skill",
+  "provider": "gcp",
+  "harnesses": [
+    "codex",
+    "claude-code",
+    "cursor",
+    "gemini",
+    "kiro",
+    "other"
+  ],
+  "summary": "Audit GCP IAM bindings across the resource hierarchy (org/folder/project), identify overprivileged Service Accounts, review Workload Identity Federation configurations, evaluate org policy conditions, and recommend least-privilege remediation.",
+  "source_type": "original",
+  "official_docs": [
+    "https://cloud.google.com/iam/docs/using-iam-securely",
+    "https://cloud.google.com/iam/docs/resource-manager-policy-evaluation",
+    "https://cloud.google.com/iam/docs/workload-identity-federation",
+    "https://cloud.google.com/resource-manager/docs/organization-policy/overview",
+    "https://cloud.google.com/iam/docs/service-account-permissions"
+  ],
+  "security_notes": "Prefer read-only inspection and minimum permission changes. Do not broaden IAM bindings, invent resource paths, or approve production trust changes without grounding in sanitized evidence.",
+  "last_verified": "2026-05-08",
+  "path": "skills/gcp/gcp-iam-least-privilege-review",
+  "author": "github: Raishin",
+  "version": "0.1.0"
+}

package/skills/gcp/gcp-iam-least-privilege-review/references/official-sources.md

@@ -0,0 +1,20 @@
+# Official sources
+
+Use this reference only when you need source grounding for GCP IAM service 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/iam/docs/using-iam-securely — IAM best practices and security guidance
+- https://cloud.google.com/iam/docs/resource-manager-policy-evaluation — how IAM bindings are evaluated across the resource hierarchy
+- https://cloud.google.com/iam/docs/workload-identity-federation — configuring WIF for external workloads
+- https://cloud.google.com/resource-manager/docs/organization-policy/overview — org policy constraints reference
+- https://cloud.google.com/iam/docs/service-account-permissions — Service Account permissions and impersonation
+- https://cloud.google.com/iam/docs/conditions-overview — IAM conditions syntax and supported resources
+- https://cloud.google.com/iam/docs/creating-custom-roles — custom role design guidance
+- https://cloud.google.com/kubernetes-engine/docs/how-to/workload-identity — GKE Workload Identity for pod-level SA binding
+
+## Grounding rule
+
+Official documentation explains GCP service behavior. It does not prove the user's current project, folder, org, quota, resource configuration, IAM boundary, or operational state. Prefer sanitized user-provided evidence (Terraform exports, gcloud output, Policy Analyzer output) for current-state claims. Never infer production state from documentation alone.

package/skills/gcp/gcp-iam-least-privilege-review/references/workflow-and-output.md

@@ -0,0 +1,69 @@
+# Workflow and output contract
+
+Use this reference only when performing the full IAM review, implementation guidance, incident triage, or production-readiness pass.
+
+## Review domains
+
+Check these areas before giving a verdict:
+
+- Resource hierarchy scope (org, folder, project) and binding inheritance chain
+- Principal types: user, group, Service Account, allUsers, allAuthenticatedUsers, workload identity pool
+- Role types: basic (owner/editor/viewer), predefined, custom — flag basic roles in production
+- Permission-level risks: privilege escalation, SA impersonation, org-level admin roles
+- Workload Identity Federation: pool configuration, provider conditions, SA bindings
+- Org policy constraints: key creation disabled, domain restriction, WIF cluster creation
+- IAM conditions: presence, correctness, resource scoping
+- Service Account key inventory: age, usage, rotation status
+
+## Safe workflow
+
+1. **Frame scope**
+   - Org/folder/project and environment (prod/staging/dev):
+   - Business criticality and compliance driver:
+   - Required outcome:
+   - Explicit non-goals:
+2. **Collect evidence**
+   - Prefer sanitized `gcloud projects get-iam-policy`, `gcloud organizations get-iam-policy`, or Terraform state exports.
+   - Otherwise inspect repository IaC/config or structured user descriptions.
+   - Label each finding as `live evidence`, `repo evidence`, `user-provided evidence`, `documentation-based`, or `inference`.
+3. **Stress-test risk**
+   - What bindings grant org-level admin roles?
+   - What SA keys are active and how old are they?
+   - Which workloads can use WIF but still use key-based auth?
+   - What org policies are missing that would prevent privilege escalation?
+   - 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 IAM Least Privilege Review: <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 |
+|---|---|---|---|---|
+## Overprivileged bindings
+| Resource | Principal | Role | Condition | Risk |
+|---|---|---|---|---|
+## SA key inventory
+| Service Account | Key age | Used recently | WIF available | Action |
+|---|---|---|---|---|
+## Org policy gaps
+| Constraint | Status | Risk if absent |
+|---|---|---|
+## Recommended actions
+1. <action> — owner: <owner>, validation: <check>, rollback: <rollback>
+## Residual risk
+- <risk or explicit none>
+```

package/skills/gcp/gcp-landing-zone-architect/SKILL.md

@@ -0,0 +1,61 @@
+---
+name: gcp-landing-zone-architect
+description: Design and review GCP landing zone foundations including organization setup, folder hierarchy, org policy baseline, Shared VPC, billing account structure, Security Command Center, and audit logging.
+allowed-tools: Read Grep Glob
+metadata:
+  author: "github: Raishin"
+  version: "0.1.0"
+  updated: "2026-05-08"
+  category: platform
+---
+
+# GCP Landing Zone Architect
+
+## Purpose
+
+Act as a rigorous GCP landing zone architect. Ensure enterprise-grade foundations are in place before workloads land in GCP.
+
+## When to use
+
+Use this skill for:
+
+- GCP organization setup and folder hierarchy design
+- Org policy baseline review and gap analysis
+- Shared VPC host/service project architecture
+- Billing account structure and budget alerting
+- Security Command Center activation and findings triage
+- Centralized audit logging and Data Access log configuration
+- Bootstrap project, CI/CD project, and Terraform state bucket design
+
+## Key GCP landing zone specifics
+
+- A GCP landing zone should include: org node → bootstrap/security/prod/non-prod folder hierarchy → Shared VPC host project per environment → org policy baseline (disable SA key creation, restrict member domains, require OS login) → SCC Standard minimum → Cloud Asset Inventory → centralized billing export to BigQuery.
+- Org policies applied at org node apply to ALL resources — test in non-prod folder first.
+- Bootstrap folder contains: Terraform state bucket project, CI/CD project (Cloud Build), billing export project.
+- Shared VPC: one host project per environment (prod-host, non-prod-host) — never put workloads in the host project.
+- Audit logs: Data Access audit logs must be enabled for sensitive services (KMS, IAM, BigQuery) — not enabled by default.
+
+## 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 missing org policies, absent audit logging, workloads in host projects, and overly broad billing access.
+- 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 GCP landing zone 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-landing-zone-architect/metadata.json

@@ -0,0 +1,27 @@
+{
+  "id": "gcp-landing-zone-architect",
+  "name": "GCP Landing Zone Architect",
+  "type": "skill",
+  "provider": "gcp",
+  "harnesses": [
+    "codex",
+    "claude-code",
+    "cursor",
+    "gemini",
+    "kiro",
+    "other"
+  ],
+  "summary": "Design and review GCP landing zone foundations: organization setup, folder hierarchy, resource hierarchy, org policies baseline, Shared VPC, billing account structure, Security Command Center activation, and audit logging.",
+  "source_type": "original",
+  "official_docs": [
+    "https://cloud.google.com/architecture/security-foundations",
+    "https://cloud.google.com/resource-manager/docs/organization-policy/overview",
+    "https://cloud.google.com/vpc/docs/shared-vpc",
+    "https://cloud.google.com/logging/docs/audit/configure-data-access"
+  ],
+  "security_notes": "Org policies applied at org node apply to ALL resources — test in non-prod folder first. Data Access audit logs must be enabled for sensitive services (KMS, IAM, BigQuery) — not enabled by default.",
+  "last_verified": "2026-05-08",
+  "path": "skills/gcp/gcp-landing-zone-architect",
+  "author": "github: Raishin",
+  "version": "0.1.0"
+}

package/skills/gcp/gcp-landing-zone-architect/references/official-sources.md

@@ -0,0 +1,15 @@
+# Official sources
+
+Use this reference only when you need source grounding for GCP landing zone 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/architecture/security-foundations
+- https://cloud.google.com/resource-manager/docs/organization-policy/overview
+- https://cloud.google.com/vpc/docs/shared-vpc
+- https://cloud.google.com/logging/docs/audit/configure-data-access
+
+## Grounding rule
+
+Official documentation explains GCP landing zone patterns and org policy behavior. It does not prove the user's current folder structure, policy bindings, audit log configuration, SCC tier, or billing setup. Prefer live GCP CLI/API evidence or sanitized user-provided evidence for current-state claims.