Claude Cursor GitHub Copilot Skill

gcp-change-impact-advisor

Pre-change blast radius analysis for GCP — cross-project resource dependency mapping, org policy cascade effects, Shared VPC peering impact, Service Account impersonation chain analysis, and safe change sequencing.

LLM Mart · 0 points · 0 views 0 listing impressions 0 install-command copies
Virus-scanned Reviewed automatically before listing.

Full trust report

Download vincentchuwaichow-vanguard-frontier-agentic-skills_gcp_gcp-change-impact-advisor-febe32a.zip · 4 KB
Part of vincentchuwaichow/vanguard-frontier-agentic — 293 skills

Install

skills CLI npx skills add https://github.com/VincentChuWaiChow/vanguard-frontier-agentic/tree/master/skills/gcp/gcp-change-impact-advisor
Claude Code claude plugin marketplace add https://llmmart.ai/marketplace.json && claude plugin install vincentchuwaichow-vanguard-frontier-agentic@llmmart
Git git clone https://github.com/VincentChuWaiChow/vanguard-frontier-agentic.git

The skills CLI installs just this skill, for any of its supported agents. Claude Code installs the whole vincentchuwaichow/vanguard-frontier-agentic collection as a plugin from our marketplace. Git is the plain clone.

Skill manifest

GCP Change Impact Advisor

Purpose

Act as the GCP change impact analyst who refuses to approve any change without first mapping the full blast radius across org hierarchy, Shared VPC service projects, and Service Account dependency chains.

When to use

Use this skill for:

  • Org policy change impact mapping (constraint propagation through folder and project hierarchy)
  • Shared VPC mutation impact analysis (host project changes affecting all attached service projects)
  • Service Account deletion or modification dependency tracing (impersonation chains, IAM policy bindings)
  • Cloud Asset Inventory API-driven cross-project dependency discovery
  • VPC peering topology mapping before any network-layer change
  • Safe change sequencing and approval gate definition
  • Rollback plan design for GCP resource changes

Lean operating rules

  • Prefer live GCP evidence from sanitized gcloud and Cloud Asset Inventory output when available; otherwise use official Google Cloud documentation.
  • Org policy changes cascade to all child folders and projects — always map the full org hierarchy affected before approving any org-level policy change.
  • Shared VPC changes (subnet additions, firewall rules, route changes) affect all service projects attached to the host project — enumerate service projects before any Shared VPC mutation.
  • Service Account deletion breaks all workloads that impersonate or are bound to that SA — always run gcloud asset search-all-iam-policies to find all policy bindings before deletion.
  • VPC peering is non-transitive — a change to VPC A does not automatically affect VPC C even if A peers with B and B peers with C; map the full peering topology before change.
  • Cloud Asset Inventory requires roles/cloudasset.viewer — confirm the reviewing principal holds this role before attempting dependency analysis.
  • Separate confirmed facts from inference. If state was not queried or shown, say so.
  • Challenge broad IAM roles, unverified dependency assumptions, destructive operations without blast radius analysis, and vague 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 — use when executing the full change impact analysis, dependency mapping, or formatting the final answer.
  • Official sources — use when grounding GCP resource dependency service behavior or checking the detailed source list.

Response minimum

Return, at minimum:

  • the scoped change target and evidence level,
  • the main blast radius risks (org policy cascade, Shared VPC service projects, SA impersonation chains),
  • the safest change sequencing with explicit approval gates,
  • validation or rollback notes where relevant,
  • the assumptions or blockers that prevent stronger conclusions.
Files (vanguard-frontier-agentic)
  • references
    • official-sources.md 1012 B
      # Official sources
      
      Use this reference only when you need source grounding for GCP change impact and resource dependency 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/asset-inventory/docs/overview
      - https://cloud.google.com/vpc/docs/shared-vpc
      - https://cloud.google.com/iam/docs/understanding-service-accounts
      - https://cloud.google.com/resource-manager/docs/organization-policy/overview
      - https://cloud.google.com/vpc/docs/vpc-peering
      - https://cloud.google.com/asset-inventory/docs/searching-iam-policies
      - https://cloud.google.com/resource-manager/docs/creating-managing-folders
      
      ## Grounding rule
      
      Official documentation explains GCP resource dependency and org policy behavior. It does not prove the user's current Shared VPC topology, SA impersonation chains, or org hierarchy. Prefer live GCP CLI/API evidence or sanitized user-provided evidence for current-state claims.
      
    • workflow-and-output.md 2.7 KB
      # Workflow and output contract
      
      Use this reference only when performing the full change impact analysis, dependency mapping, or safe sequencing review.
      
      ## Analysis domains
      
      Check these areas before giving a verdict:
      - Org policy cascade: constraint type (list vs. boolean), affected folder/project hierarchy, deny-override risk
      - Shared VPC impact: host project identification, enumeration of all service projects, subnet/firewall/route change scope
      - Service Account dependency chain: all IAM policy bindings, workload identity bindings, impersonation chains
      - Cloud Asset Inventory coverage: confirming `roles/cloudasset.viewer` is available before dependency analysis
      - VPC peering topology: direct peers only (non-transitive), route advertisement changes, firewall rule propagation
      - Change sequencing: dependencies between steps, blast radius reduction through staged rollout
      - Rollback design: reversibility of each change step, approval gates before irreversible actions
      
      ## Safe workflow
      
      1. **Frame scope**
         - Change type and target resource:
         - Environment (prod/non-prod):
         - Business criticality and owner:
         - 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 Google Cloud docs.
         - Label each finding as `live evidence`, `repo evidence`, `user-provided evidence`, `documentation-based`, or `inference`.
      3. **Stress-test blast radius**
         - What org folders and projects are in scope for org policy cascade?
         - What Shared VPC service projects are attached to the affected host project?
         - What workloads bind to or impersonate the affected Service Account?
         - What VPC peers are directly affected (not transitively)?
         - What evidence is missing?
      4. **Recommend the smallest safe action**
         - Prefer narrow scope, staged rollout, validation, and rollback.
         - Require explicit approval before irreversible changes (SA deletion, org policy enforcement mode).
         - If the safest action is to stop and gather evidence, say that plainly.
      
      ## Output contract
      
      Return this structure:
      ```markdown
      # GCP Change Impact Advisor: <change description>
      ## Executive verdict
      - Status: SAFE TO PROCEED / PROCEED WITH GATES / HIGH RISK / NEEDS EVIDENCE
      - Blast radius: <summary of affected resources and projects>
      - Biggest risk:
      - Evidence level:
      ## Scope and assumptions
      - Confirmed:
      - Unknown:
      - Out of scope:
      ## Findings
      | Severity | Finding | Evidence | Why it matters | Minimum safe action |
      |---|---|---|---|---|
      ## Safe change sequencing
      1. <step> — approval gate: <gate>, rollback: <rollback>
      ## Rollback plan
      - <step rollback or explicit irreversible note>
      ## Residual risk
      - <risk or explicit none>
      ```
      
  • metadata.json 1.2 KB
    {
      "id": "gcp-change-impact-advisor",
      "name": "GCP Change Impact Advisor",
      "type": "skill",
      "provider": "gcp",
      "harnesses": [
        "codex",
        "claude-code",
        "cursor",
        "gemini",
        "kiro",
        "other"
      ],
      "summary": "Pre-change blast radius analysis for GCP — cross-project resource dependency mapping, org policy cascade effects, Shared VPC peering impact, Service Account impersonation chain analysis, and safe change sequencing.",
      "source_type": "original",
      "official_docs": [
        "https://cloud.google.com/asset-inventory/docs/overview",
        "https://cloud.google.com/vpc/docs/shared-vpc",
        "https://cloud.google.com/iam/docs/understanding-service-accounts",
        "https://cloud.google.com/resource-manager/docs/organization-policy/overview",
        "https://cloud.google.com/vpc/docs/vpc-peering"
      ],
      "security_notes": "Cloud Asset Inventory requires roles/cloudasset.viewer — ensure the reviewing principal has this before attempting dependency analysis. Org policy changes with deny-override can lock out even org admins from specific resources — test in a non-production folder first.",
      "last_verified": "2026-05-09",
      "path": "skills/gcp/gcp-change-impact-advisor",
      "author": "github: VincentChuWaiChow",
      "version": "0.1.0"
    }
    
  • SKILL.md 3.4 KB
    ---
    name: gcp-change-impact-advisor
    description: Pre-change blast radius analysis for GCP — cross-project resource dependency mapping, org policy cascade effects, Shared VPC peering impact, Service Account impersonation chain analysis, and safe change sequencing.
    allowed-tools: Read Grep Glob
    metadata:
      author: "github: VincentChuWaiChow"
      version: "0.1.0"
      updated: "2026-05-09"
      category: platform
    ---
    
    # GCP Change Impact Advisor
    
    ## Purpose
    
    Act as the GCP change impact analyst who refuses to approve any change without first mapping the full blast radius across org hierarchy, Shared VPC service projects, and Service Account dependency chains.
    
    ## When to use
    
    Use this skill for:
    
    - Org policy change impact mapping (constraint propagation through folder and project hierarchy)
    - Shared VPC mutation impact analysis (host project changes affecting all attached service projects)
    - Service Account deletion or modification dependency tracing (impersonation chains, IAM policy bindings)
    - Cloud Asset Inventory API-driven cross-project dependency discovery
    - VPC peering topology mapping before any network-layer change
    - Safe change sequencing and approval gate definition
    - Rollback plan design for GCP resource changes
    
    ## Lean operating rules
    
    - Prefer live GCP evidence from sanitized `gcloud` and Cloud Asset Inventory output when available; otherwise use official Google Cloud documentation.
    - Org policy changes cascade to all child folders and projects — always map the full org hierarchy affected before approving any org-level policy change.
    - Shared VPC changes (subnet additions, firewall rules, route changes) affect all service projects attached to the host project — enumerate service projects before any Shared VPC mutation.
    - Service Account deletion breaks all workloads that impersonate or are bound to that SA — always run `gcloud asset search-all-iam-policies` to find all policy bindings before deletion.
    - VPC peering is non-transitive — a change to VPC A does not automatically affect VPC C even if A peers with B and B peers with C; map the full peering topology before change.
    - Cloud Asset Inventory requires `roles/cloudasset.viewer` — confirm the reviewing principal holds this role before attempting dependency analysis.
    - Separate confirmed facts from inference. If state was not queried or shown, say so.
    - Challenge broad IAM roles, unverified dependency assumptions, destructive operations without blast radius analysis, and vague 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 change impact analysis, dependency mapping, or formatting the final answer.
    - [Official sources](references/official-sources.md) — use when grounding GCP resource dependency service behavior or checking the detailed source list.
    
    ## Response minimum
    
    Return, at minimum:
    
    - the scoped change target and evidence level,
    - the main blast radius risks (org policy cascade, Shared VPC service projects, SA impersonation chains),
    - the safest change sequencing with explicit approval gates,
    - validation or rollback notes where relevant,
    - the assumptions or blockers that prevent stronger conclusions.
    

Comments (0)

Sign in to join the conversation.

No comments yet.

Reviews (0)

No reviews yet.

Related