Architecture Diagram Designer

Architecture Diagramming Standard

by HoangNguyen0403 · MIT license · ★ 569 on GitHub

Draws architecture diagrams as editable draw.io files with a fixed house style, C4 levels, evidence-tagged shapes, and optional multi-view identity checks. Use when producing a system context, container, component, deployment, data…

---
name: common-architecture-diagramming
description: Draws architecture diagrams as editable draw.io files with a fixed house style, C4 levels, evidence-tagged shapes, and optional multi-view identity checks. Use when producing a system context, container, component, deployment, data flow, sequence, state, or ERD, or redrawing an ASCII or Mermaid one.
metadata:
  triggers:
    files:
      - "ARCHITECTURE.md"
      - "**/*.drawio"
      - "**/*.mermaid"
      - "docs/architecture/**"
    keywords:
      - diagram
      - c4
      - drawio
      - mermaid
      - erd
      - entity relationship
      - schema diagram

Overview

Never hand-write mxGraph XML. Write a spec; the scripts own every visual decision, so diagrams stay identical across authors, repositories, and sessions.

Manual install (npx, ZIP)

Claude Codenpx skills add HoangNguyen0403/agent-skills-standard --skill common-architecture-diagramming -g -a claude-code

Claude Code (degit)

npx degit HoangNguyen0403/agent-skills-standard/.agents/skills/common/common-architecture-diagramming#develop ~/.claude/skills/common-architecture-diagramming

Claude.ai / desktopZip the folder and upload it under Settings → Capabilities → Skills.

Codex, Cursor, other agentsPoint them at SKILL.md. The other files are plain text.

Connects with Agent Alley MCP · agentalley.io/mcp

Files included

SKILL.md5.0 KB

Read SKILL.md here

HoangNguyen0403/develop1 file shown

SKILL.md5.0 KB

Browse every file on GitHub↗

SKILL.md

Show the full text93 lines

common-architecture-diagramming/SKILL.md93 lines · 5.0 KB

PreviewCode

Outline

RawView on GitHub

Architecture Diagramming Standard

Priority: P1 (HIGH)

Pipeline

Never hand-write mxGraph XML. Write a spec; the scripts own every visual decision, so diagrams stay identical across authors, repositories, and sessions.

Write spec.json — schema in diagram-spec.md. For an ERD, generate it: python3 scripts/schema_to_spec.py db/schema.sql --title "<System> — ERD" -o spec.json
python3 scripts/validate_spec.py spec.json
python3 scripts/render_drawio.py spec.json -o docs/architecture/<slug>.drawio --strict (exit 2 = a layout finding; change the spec, per layout-rules.md)
For related views, optionally validate view-manifest.md: python3 scripts/validate_manifest.py view-manifest.json
Export the image: a draw.io MCP tool if the session has one, else python3 scripts/export_drawio.py docs/architecture/<slug>.drawio -f png -o docs/architecture/<slug>.png, else ship the .drawio and say the image was not exported. See export paths.
Inspect the exported image at normal reading size; strict validation cannot prove labels and edges are legible. Fix the spec and re-export before handoff.

The JSON spec is the semantic source of truth; .drawio is the editable presentation and the image is a copy for a deck. Generated XML records its own baseline; regeneration protects manual edits by default. Use --acknowledge-manual-edits only after returning semantic changes to the spec.

Guidelines

Name the audience and the decision before drawing anything.
One C4 level per diagram: context, container, or component, never mixed.
Pick the type from the message, not from habit. See diagram-selection.md.
Evidence and confidence are separate. Code citations are documented evidence, not runtime observations; use assumed or unverified for honest design uncertainty.
Put the number on the box. metric carries the load or SLO that sized the node, constraint says why it exists; never invent either.
Label every edge with its protocol or event; use style: async for events.
Cloud icons only where verified. gcp:* and aws:* are official icons; every other vendor is a cloud:* kind with the service named in sublabel. No Azure logos exist in the bundle, so Azure is always cloud:*.
Exec audience caps at 12 nodes. Past that, split by level or by flow.
Legend and title block are generated. Do not remove or duplicate them.
Refine in the spec, not by mutating generated XML. Regeneration preserves files with a valid own baseline, but refuses hand mutation until explicitly acknowledged.

Anti-Patterns

No hand-written XML: Write the spec, run the renderer.
No invented boxes: Omit what the evidence does not support.
No mixed levels: Table columns never appear in a context diagram.
No unlabeled arrows: State the protocol or the event.
No mystery acronyms: Expand every abbreviation on first use.
No orphan nodes: Connect it or cut it.

Red Flags

Thought	Reality
"It is one box, I will write the XML"	The renderer owns style, legend, and title block. Use it.
"Close enough, I will guess this service"	Guesses ship as facts. Omit the evidence and let it render UNVERIFIED.
"Managers want the whole system on one page"	Past 12 nodes they stop reading. Split it.

References

Diagram spec · View manifest · Style catalog · House style
Source extraction · Exec readability
C4 model · Cloud · Best practices
Layout rules · Checklist · Export paths and Mermaid fallback
Runnable examples: assets/fixtures/<type>.spec.json, one per diagram type, plus schema samples under assets/fixtures/schemas/.
Batch or delegated drawing: specialist-solution-diagrammer.

1	---
2	name: common-architecture-diagramming
3	description: Draws architecture diagrams as editable draw.io files with a fixed house style, C4 levels, evidence-tagged shapes, and optional multi-view identity checks. Use when producing a system context, container, component, deployment, data flow, sequence, state, or ERD, or redrawing an ASCII or Mermaid one.
4	metadata:
5	triggers:
6	files:
7	- "ARCHITECTURE.md"
8	- "*/.drawio"
9	- "*/.mermaid"
10	- "docs/architecture/**"
11	keywords:
12	- diagram
13	- c4
14	- drawio
15	- mermaid
16	- erd
17	- entity relationship
18	- schema diagram
19	- aws
20	- architecture diagram
21	- solution architecture
22	- system context
23	- deployment diagram
24	---
25	# Architecture Diagramming Standard
26
27	## Priority: P1 (HIGH)
28
29	## Pipeline
30
31	Never hand-write mxGraph XML. Write a spec; the scripts own every visual decision,
32	so diagrams stay identical across authors, repositories, and sessions.
33
34	1. Write `spec.json` — schema in [diagram-spec.md](references/diagram-spec.md). For an ERD,
35	generate it: `python3 scripts/schema_to_spec.py db/schema.sql --title "<System> — ERD" -o spec.json`
36	2. `python3 scripts/validate_spec.py spec.json`
37	3. `python3 scripts/render_drawio.py spec.json -o docs/architecture/<slug>.drawio --strict`
38	(exit 2 = a layout finding; change the spec, per [layout-rules.md](references/layout-rules.md))
39	4. For related views, optionally validate [view-manifest.md](references/view-manifest.md):
40	`python3 scripts/validate_manifest.py view-manifest.json`
41	5. Export the image: a draw.io MCP tool if the session has one, else
42	`python3 scripts/export_drawio.py docs/architecture/<slug>.drawio -f png -o docs/architecture/<slug>.png`,
43	else ship the `.drawio` and say the image was not exported. See [export paths](references/mermaid-fallback.md).
44	6. Inspect the exported image at normal reading size; strict validation cannot prove labels and edges are legible. Fix the spec and re-export before handoff.
45
46	The JSON spec is the semantic source of truth; `.drawio` is the editable presentation and the
47	image is a copy for a deck. Generated XML records its own baseline; regeneration protects
48	manual edits by default. Use `--acknowledge-manual-edits` only after returning semantic changes to the spec.
49
50	## Guidelines
51
52	- Name the audience and the decision before drawing anything.
53	- One C4 level per diagram: context, container, or component, never mixed.
54	- Pick the type from the message, not from habit. See [diagram-selection.md](references/diagram-selection.md).
55	- Evidence and confidence are separate. Code citations are documented evidence, not runtime
56	observations; use `assumed` or `unverified` for honest design uncertainty.
57	- Put the number on the box. `metric` carries the load or SLO that sized the node,
58	`constraint` says why it exists; never invent either.
59	- Label every edge with its protocol or event; use `style: async` for events.
60	- Cloud icons only where verified. `gcp:` and `aws:` are official icons; every other
61	vendor is a `cloud:*` kind with the service named in `sublabel`. No Azure logos exist in
62	the bundle, so Azure is always `cloud:*`.
63	- Exec audience caps at 12 nodes. Past that, split by level or by flow.
64	- Legend and title block are generated. Do not remove or duplicate them.
65	- Refine in the spec, not by mutating generated XML. Regeneration preserves files with a
66	valid own baseline, but refuses hand mutation until explicitly acknowledged.
67
68	## Anti-Patterns
69
70	- No hand-written XML: Write the spec, run the renderer.
71	- No invented boxes: Omit what the evidence does not support.
72	- No mixed levels: Table columns never appear in a context diagram.
73	- No unlabeled arrows: State the protocol or the event.
74	- No mystery acronyms: Expand every abbreviation on first use.
75	- No orphan nodes: Connect it or cut it.
76
77	## Red Flags
78
79	\| Thought \| Reality \|
80	\|---------\|---------\|
81	\| "It is one box, I will write the XML" \| The renderer owns style, legend, and title block. Use it. \|
82	\| "Close enough, I will guess this service" \| Guesses ship as facts. Omit the evidence and let it render UNVERIFIED. \|
83	\| "Managers want the whole system on one page" \| Past 12 nodes they stop reading. Split it. \|
84
85	## References
86
87	- [Diagram spec](references/diagram-spec.md) · [View manifest](references/view-manifest.md) · [Style catalog](references/style-catalog.md) · [House style](references/house-style.md)
88	- [Source extraction](references/source-extraction.md) · [Exec readability](references/exec-readability.md)
89	- [C4 model](references/c4-model.md) · [Cloud](references/cloud-architecture.md) · [Best practices](references/best-practices.md)
90	- [Layout rules](references/layout-rules.md) · [Checklist](references/checklist.md) · [Export paths and Mermaid fallback](references/mermaid-fallback.md)
91	- Runnable examples: `assets/fixtures/<type>.spec.json`, one per diagram type, plus schema samples under `assets/fixtures/schemas/`.
92	- Batch or delegated drawing: `specialist-solution-diagrammer`.
93