gcp-architecture-discovery

GCP Architecture Discovery

Overview

This skill provides a discovery approach for GCP infrastructure. It discovers what's needed for the current investigation and caches results for future use.

RULE: ASYNCHRONOUS INVOCATION ONLY You MUST NEVER execute this skill in the main conversation thread. Because architecture discovery is a long-running, blocking task, you must ALWAYS invoke it as a background subagent, regardless of whether you are in an investigation, setting up a new project, or performing a routine audit. How to invoke: Use the invoke_subagent tool to spawn a clone of yourself (Subagent Type: self), and provide it with a prompt to execute this discovery workflow and notify you via send_message when complete. The main agent must continue its tasks immediately without waiting.

When to Use

• When investigating a failing service or starting an incident response.
• When an incident has been resolved and the system topology has changed (e.g., firewall blocked an IP, traffic diverted).
• When initializing a new GCP project for the first time.
• Identifying dependencies between services during incidents.
• Creating architecture diagrams for human and agent understanding.
• Auditing specific resource configurations.

Philosophy & Agent Mindset

The Architecture Graph is Your Mental Model. The discover.json and generated PNG represent how you see the system right now. Do not hesitate to update, rewrite, or expand the graph whenever you discover something new. For example: If you realize a Load Balancer connects to a different backend than previously drawn, overwrite it immediately.

Discovery Strategy (Adaptive Blast Radius) Exhaustive scans of an entire massive project waste time, but lazily scanning just one node causes you to miss critical infrastructure changes (e.g. altered firewalls, deleted databases, changed IAM policies).

• Find the Anchor: Start at the service or node experiencing the incident.
• Map the Full Blast Radius: You MUST aggressively discover and map ALL resources functionally or topologically connected to the anchor. This includes checking:
  • Upstream Load Balancers or API Gateways.
  • Surrounding Network boundaries (VPCs, Subnets, Firewalls, NATs). Did any rules change?
  • Downstream targets (Databases, Pub/Sub topics, Cloud Storage). Do they still exist?

🚨 CRITICAL RULE: NEVER stop after discovering just the single affected resource. You MUST forcefully map its entire surrounding ecosystem. Relying on old cache assumptions causes you to miss deleted, unmapped, or altered infrastructure.

• Update Cache: Merge the discovered ecosystem slice into the existing graph.