create_diagram
ClaudeCreates and displays an interactive draw.io diagram. Accepts either draw.io XML or Mermaid.js syntax — provide exactly one. Format decision — this is the first thing to settle before you write anything: if the diagram type appears on the Mermaid list below, use
mermaid. Only use xml when the diagram type isn't on that list (UI mockups, floorplans, cloud/network/electrical architecture with stencils, hand-placed UML, etc.) or when the user has explicitly asked for draw.io XML. Use Mermaid for the following diagram types (all rendered natively, no upstream mermaid runtime): - flowchart / graph (TD, LR, …) - sequenceDiagram - classDiagram - stateDiagram / stateDiagram-v2 - erDiagram - gantt - pie - journey (user-journey) - gitGraph - mindmap - timeline - quadrantChart - xychart-beta - sankey-beta - requirementDiagram - C4Context / C4Container / C4Component - block-beta - architecture-beta - packet-beta - kanban - radar-beta - treemap-beta - treeview-beta (draw.io-specific) - venn (draw.io-specific) — syntax: venn then set A ["Label"] for each set, union A,B for declared overlaps (informational), and text A / text A,B followed by ["Region label"] for text inside a region. Do NOT use A AND B[...] or A["..."] shorthand — those lines are ignored. - ishikawa (draw.io-specific) - zenuml Strong default: use Mermaid for every diagram type on that list above. Mermaid is simpler, more reliable, and the native Mermaid layout handles positioning and routing for you. For a flowchart, state diagram, sequence, ER, class, gantt, gitGraph, mindmap, etc. — reach for the mermaid parameter, not xml. Do not default to XML for flowcharts. Use XML when the diagram type isn't on the Mermaid list above OR when the user explicitly asks for XML / draw.io format. Typical cases where XML is the right choice: - UI mockups / wireframes / screen designs — buttons, form fields, sidebars, modal dialogs (shape=mxgraph.bootstrap.*, shape=mxgraph.ios.*, shape=mxgraph.android.*) - Floor plans / seating charts / room layouts — rooms, doors, furniture (shape=mxgraph.floorplan.*) - Cloud architecture with AWS / Azure / GCP / Kubernetes icons (shape=mxgraph.aws4.*, shape=mxgraph.azure.*, shape=mxgraph.gcp2.*, shape=mxgraph.kubernetes.*) - Network topology with Cisco / Rack / networking shapes (shape=mxgraph.cisco*.*, shape=mxgraph.rack.*, shape=mxgraph.networking.*) - P&ID / electrical / engineering schematics (shape=mxgraph.pid2.*, shape=mxgraph.electrical.*, shape=mxgraph.mscae.*) - Swimlanes / pools with custom colors and hand-placed contents - UML class / component / deployment diagrams where positioning carries meaning - Venn diagrams, quadrant charts, concept maps with custom regions — anything where hand-placed geometry is the point - Any diagram requiring specific colors, fonts, stencils, or layouts that Mermaid can't control precisely Call search_shapes first when you need industry icons (AWS / Azure / Cisco / P&ID / Kubernetes / floorplan / mockup / electrical) or brand logos / pictorial concept icons (e.g. 'react', 'slack', 'shopping cart') to find the correct style string for each shape. --- XML reasoning discipline (applies ONLY when you chose XML — skip this whole section if you're using Mermaid): Your job in XML is declaring logical structure — nodes, edges, labels, groupings. Follow these steps in order: (1) Decide `postLayout` and `routing` FIRST, before writing any XML. If the XML diagram is a flowchart, state diagram, decision tree, or any directional/hierarchical process diagram (which you should rarely be writing as XML — prefer Mermaid), you MUST pass postLayout: "elk" (add direction: "horizontal" when the flow is drawn left-to-right; it defaults to vertical). Omit postLayout only when the layout carries hand-crafted meaning (swimlanes, containers, architecture, UML) — the typical reason you chose XML in the first place. When postLayout is set, your x/y coordinates only need to express rough direction; ELK re-lays out the…
