I tried creating a "GCP Architecture Diagram Skill" with Claude Code — Fundamental Differences in Icon Formats Revealed Through Porting an AWS Skill

Introduction

I previously created a custom skill for Claude Code that automatically generates AWS architecture diagrams in Draw.io format. It's a skill where you simply say "Draw an AWS architecture diagram" and a .drawio file with accurate icons is output.

Since the AWS version was so useful, I decided to "build the same thing for GCP."

To cut to the chase, GCP's Draw.io icons work fundamentally differently from AWS, and a simple port won't cut it. While AWS icons only need a single line of shape reference, GCP icons embed Base64-encoded SVG data inline directly into the style attribute. This article explains how I addressed that difference.

Background: How the AWS Version Works

Let me briefly explain how the existing AWS skill operates.

Directory Structure

.claude/skills/aws-architecture-diagram/
├── SKILL.md                    # Main instruction file
├── references/
│   ├── aws-icons-compute.md    # Icon definitions for EC2, Lambda, ECS, etc.
│   ├── aws-icons-networking.md # VPC, CloudFront, Route 53, etc.
│   ├── layout-guidelines.md    # Layout rules
│   └── ...（7 files）
└── templates/
    └── base.drawio.xml         # Draw.io skeleton template

AWS Icon Notation

AWS Draw.io icons can be specified with a short shape reference:

<mxCell style="...shape=mxgraph.aws4.resourceIcon;resIcon=mxgraph.aws4.lambda;"
        vertex="1" parent="grp-subnet">
  <mxGeometry width="48" height="48" as="geometry" />
</mxCell>

The key part is resIcon=mxgraph.aws4.lambda. Since it's a reference to the AWS stencil library built into Draw.io, you only need to know the icon name. This is easy for LLMs to work with, and the reference files stay lightweight.

The GCP Icon Problem: Inline SVG Approach

When I examined the Draw.io source code to build a GCP version, I found a fundamental difference.

GCP Icon Notation

<mxCell style="...shape=image;image=data:image/svg+xml,PHN2ZyB4bWxucz0i..."
        vertex="1" parent="grp-region">
  <mxGeometry width="42" height="42" as="geometry" />
</mxCell>

image=data:image/svg+xml,PHN2Gy... — this is the actual Base64-encoded SVG data. Rather than using stencil references like AWS, Draw.io's GCP2 library embeds each icon's SVG image data directly into the style attribute.

What This Means for LLMs

In other words, it's impossible for an LLM to generate GCP icon style strings from memory or guesswork. A single wrong character in the Base64-encoded SVG will corrupt the icon and prevent it from displaying.

Researching Industry Approaches

I looked into whether anyone had already built a "GCP Draw.io skill."

Article by Ruban Siva / Google Cloud

An approach combining Draw.io and MCP to automatically generate GCP architecture diagrams was introduced in something close to the official Google Cloud blog. The key point was building a component library in advance and copying exact style strings from it.

Agents365 / drawio-skill

A Draw.io skill published on GitHub that includes a shapesearch.py with over 10,000 shape definitions. However, it adds a Python dependency, and GCP icon coverage was unclear.

The Approach I Adopted

Based on both research findings, I decided that the same pattern as the AWS version — storing complete style strings in pre-extracted reference files — was the most reliable approach. The LLM just copies and pastes style strings from the reference files, so it doesn't need to "understand" Base64 SVG at all.

Implementation: Extracting Icons from Draw.io Source

Source of SVG Data

Draw.io's GCP icons are stored in two files in the jgraph/drawio GitHub repository:

• Sidebar-GCP2.js (2,432 lines) — 163 modern GCP icons (inline SVG format)
• gcp2.xml — ~200 stencil shapes (general-purpose icons)

The content of Sidebar-GCP2.js consists of functions that register icons by palette:

// addGCP2IconsComputePalette, addGCP2IconsNetworkingPalette, ...
this.createVertexTemplateEntry(
  'editableCssRules=.*;sketch=0;html=1;...image=data:image/svg+xml,PHN2Gy...',
  42, 42, 'Compute Engine', null, null, null, ...
);

The goal was to extract the style string, width, height, and label from each createVertexTemplateEntry call.

Extraction Script

I wrote a Python script to parse Sidebar-GCP2.js and extract 163 icons across 16 categories:

PALETTES = {
    "addGCP2IconsAIAndMachineLearningPalette": ("gcp-icons-ai-ml.md", "AI / Machine Learning"),
    "addGCP2IconsComputePalette": ("gcp-icons-compute.md", "Compute"),
    "addGCP2IconsNetworkingPalette": ("gcp-icons-networking.md", "Networking"),
    # ... 16 palettes
}

I used regular expressions to extract entries from each palette function and wrote them to category-specific Markdown files. The output format was aligned with the AWS version:

### Cloud Run

- **Width**: 34
- **Height**: 42
- **Style**: `editableCssRules=.*;sketch=0;html=1;...image=data:image/svg+xml,PHN2Gy...`

The style strings are stored completely as-is, without any modification. No line breaks, no indentation. Changing even a single character would break the icons.

Structure of the Completed Skill

The final directory structure is as follows:

.claude/skills/gcp-architecture-diagram/
├── SKILL.md                              # Main instruction file (212 lines)
├── templates/
│   └── base.drawio.xml                   # Draw.io template (shared with AWS version)
└── references/
    ├── layout-guidelines.md              # GCP-specific layout rules
    ├── gcp-icons-common.md               # Zones, paths, GCP logo, general icons
    ├── gcp-icons-compute.md              # Compute Engine, GKE, etc. (11 icons)
    ├── gcp-icons-serverless.md           # Cloud Functions, Cloud Run, etc. (5 icons)
    ├── gcp-icons-databases.md            # Cloud SQL, Spanner, etc. (9 icons)
    ├── gcp-icons-storage.md              # Cloud Storage, Filestore, etc. (4 icons)
    ├── gcp-icons-networking.md           # VPC, Load Balancing, etc. (19 icons)
    ├── gcp-icons-data-analytics.md       # BigQuery, Dataflow, etc. (16 icons)
    ├── gcp-icons-ai-ml.md                # Vertex AI, AutoML, etc. (29 icons)
    ├── gcp-icons-security.md             # IAM, KMS, Chronicle, etc. (10 icons)
    ├── gcp-icons-operations.md           # Logging, Monitoring, etc. (17 icons)
    ├── gcp-icons-cicd.md                 # Cloud Build, Artifact Registry, etc. (15 icons)
    ├── gcp-icons-integration.md          # Eventarc, Workflows, etc. (7 icons)
    ├── gcp-icons-api-management.md       # Apigee, Endpoints, etc. (5 icons)
    ├── gcp-icons-migration.md            # Transfer Appliance, etc. (7 icons)
    ├── gcp-icons-hybrid-multicloud.md    # Anthos, etc. (4 icons)
    ├── gcp-icons-iot.md                  # Cloud IoT Core (1 icon)
    └── gcp-icons-opensource.md            # OSS-related icons (4 icons)

Total: 20 files, 163 icons, approximately 380KB

The AWS version had 7 reference files, so the GCP version grew significantly to 18 reference files. This is because the GCP2 library has more granular category divisions.

Key Design Differences from the AWS Version

Container Nesting Hierarchy

In GCP, the project is the top-level container, with VPC Networks inside it. In AWS, Cloud is the outermost layer, with VPCs nested under Regions.

Container Styles

AWS has individual shapes per group, but GCP uses a single common shape shape=mxgraph.gcp2.zones and simply changes fillColor to differentiate them:

Edge Colors

AWS tends to use orange tones, while GCP uses Google brand colors:

Managed Services Pattern

GCP's managed services (BigQuery, Vertex AI, Cloud Storage, etc.) exist outside the VPC. To represent this visually, I designed a Two-box layout pattern:

+--- Google Cloud Project --------------------------------+
|                                                          |
|  +--- VPC Network ---+   +--- Managed Services --------+|
|  | GKE, Compute     |   | Cloud SQL, BigQuery,         ||
|  | Engine, etc.     | →  | Vertex AI, Cloud Storage    ||
|  +-------------------+   | (GCP-managed, outside VPC)  ||
|                           +-----------------------------+|
+----------------------------------------------------------+

User-deployed resources go in the VPC box, and GCP-managed services are placed in a dashed-border box. Arrows connect sources to targets directly, with details about Private Google Access and Private Service Connect documented in a companion guide.

Test: Three-Tier Serverless Architecture

To verify the skill works, I generated a simple three-tier configuration:

Users → Cloud Load Balancing → Cloud Run → Cloud SQL / Cloud Storage

Key things verified in the generated Draw.io file:

1. Icon rendering — GCP-colored icons for Cloud Load Balancing, Cloud Run, Cloud SQL, and Cloud Storage display correctly
2. Container nesting — Project (gray) → VPC (blue) → Region (green) are properly nested
3. GCP logo — A small Google Cloud logo appears in the upper-left of the project container
4. Edges — Google Blue (#4284F3) orthogonal routing arrows connect correctly

Design Choices

SKILL.md Design

I built on the AWS version's SKILL.md and added GCP-specific elements:

• 15 rules — Verbatim copying of style strings, exact size specifications, GCP logo placement, etc.
• Non-Technical Audience Mode — Numbered edges (①②③④) for generating diagrams aimed at non-technical audiences
• Managed Services pattern — A layout pattern that visualizes the boundary between VPC resources and managed services

Unified Reference File Format

Using the same format for both AWS and GCP versions makes it easier for LLMs to learn them as a "pattern":

### Service Name

- **Width**: 42
- **Height**: 42
- **Style**: `complete style string...`

Whether the style string contains a shape reference or Base64 SVG doesn't matter to the LLM — it's just "something to copy and paste."

Cell ID Convention

For maintainability, I established a convention of assigning descriptive IDs to drawing elements:

• Groups: grp-project, grp-vpc, grp-region, grp-zone-a
• Icons: svc-gke, svc-cloud-sql, svc-bigquery
• Edges: edge-1, edge-2
• Logo: logo-gcp

What I Learned

The Same Pattern Can Apply to Different Providers

While AWS and GCP icon formats are fundamentally different, the skill design pattern of "copying style strings from reference files" worked for both. All the LLM needs to do is "read the right file and copy the right value." There's no need to "understand" Base64 SVG.

It's Important to Investigate Icon Formats First

When building a Draw.io skill, you should first verify the icon format of the target library. The reference file design differs significantly between stencil-reference types (AWS, Azure) and inline-SVG types (GCP). Reading the Sidebar-related JS files in Draw.io's GitHub repository (jgraph/drawio) is the most reliable approach.

Never Touch the SVG Data

The Base64 SVG data in GCP icons must never be modified — not during extraction, not when storing in reference files. Adding line breaks, re-encoding, trimming — any of these will corrupt the icons. "Don't touch it" is the rule.

Summary

I built a skill that lets you simply say "Draw a GCP architecture diagram" in Claude Code and get an accurate Draw.io file as output. There was a technical barrier in the difference between AWS and GCP icon formats (shape reference vs. inline SVG), but I solved it by pre-extracting SVG data from Draw.io's source code and storing it in reference files.

With a skill set of 20 files, 163 icons, and approximately 380KB, the skill covers nearly all major GCP services. By aligning the design pattern with the AWS version, the same approach should be applicable when building an Azure version in the future.