$npx -y skills add thomast1906/github-copilot-agent-skills --skill excalidraw-mcp-diagrammingCreate and edit diagrams on a live Excalidraw canvas using the Excalidraw MCP server. Use when asked to draw, diagram, sketch, or visualise architectures, workflows, data flows, system designs, flowcharts, mind maps, or sequence diagrams. Trigger phrases include "create an excali
| 1 | # Excalidraw MCP Diagramming |
| 2 | |
| 3 | Create diagrams on a live Excalidraw canvas that renders in the browser and |
| 4 | updates in real time. You are not generating a static file — you are painting |
| 5 | onto a shared whiteboard through MCP tools. The canvas persists between calls, |
| 6 | so what you put on it in one call is visible in the next screenshot. |
| 7 | |
| 8 | ## When to Use |
| 9 | |
| 10 | - The user asks to "create an excalidraw", "draw me a diagram", "make a flowchart", "visualise the system", or "diagram this architecture". |
| 11 | - The user wants an Excalidraw canvas output (not Draw.io / diagrams.net — use `drawio-mcp-diagramming` for that). |
| 12 | - The user wants to visualise an architecture, workflow, data flow, system design, mind map, or sequence diagram. |
| 13 | - The user asks to export a diagram to PNG, SVG, `.excalidraw` file, or a shareable URL. |
| 14 | - The user asks to update, change, or fix an existing Excalidraw diagram. |
| 15 | |
| 16 | ## Required MCP Server |
| 17 | |
| 18 | The `excalidraw` MCP server must be present in `.vscode/mcp.json`: |
| 19 | |
| 20 | ```json |
| 21 | { |
| 22 | "servers": { |
| 23 | "excalidraw": { |
| 24 | "type": "http", |
| 25 | "url": "https://mcp.excalidraw.com" |
| 26 | } |
| 27 | } |
| 28 | } |
| 29 | ``` |
| 30 | |
| 31 | If the MCP tools are not available, tell the user to add the server and reload |
| 32 | VS Code, then stop. |
| 33 | |
| 34 | ## Available Tools |
| 35 | |
| 36 | **Essential — use on every diagram:** |
| 37 | |
| 38 | | Tool | Purpose | When | |
| 39 | |---|---|---| |
| 40 | | `read_diagram_guide` | Returns server-side colour palette and sizing rules | First call — before any elements | |
| 41 | | `batch_create_elements` | Creates multiple shapes and arrows atomically | Main workhorse | |
| 42 | | `get_canvas_screenshot` | Returns a photo of the current canvas | After every change — verify before continuing | |
| 43 | | `clear_canvas` | Wipes all content | Start of every new diagram | |
| 44 | | `set_viewport` | Scrolls and zooms to fit content | After creating elements | |
| 45 | |
| 46 | **Secondary — use when needed:** |
| 47 | |
| 48 | | Tool | When | |
| 49 | |---|---| |
| 50 | | `create_from_mermaid` | Quick drafts — 3–8 node sequential flows | |
| 51 | | `update_element` | Small corrections (position, colour, text) | |
| 52 | | `export_to_image` | User requests PNG or SVG file | |
| 53 | | `export_scene` | User requests editable `.excalidraw` file | |
| 54 | | `export_to_excalidraw_url` | User wants a shareable link | |
| 55 | | `describe_scene` | Audit what is currently on the canvas | |
| 56 | |
| 57 | --- |
| 58 | |
| 59 | ## Workflow |
| 60 | |
| 61 | ### Step 1 — Choose the Creation Path |
| 62 | |
| 63 | **Mermaid path** — use for simple sequential flows (3–8 nodes, no zones): |
| 64 | |
| 65 | ``` |
| 66 | create_from_mermaid( |
| 67 | mermaidDiagram="graph TD; A[Frontend] -->|REST| B[API]; B -->|SQL| C[DB]" |
| 68 | ) |
| 69 | ``` |
| 70 | |
| 71 | Then jump to Step 6 (screenshot). Skip Steps 2–5. |
| 72 | |
| 73 | **Batch path** — use for everything else: layered architectures, data flows, |
| 74 | hub-and-spoke, any diagram needing zones or colour-coded roles. Continue below. |
| 75 | |
| 76 | ### Step 2 — Read the Design Guide |
| 77 | |
| 78 | ``` |
| 79 | read_diagram_guide() |
| 80 | ``` |
| 81 | |
| 82 | Retrieve the server's current colour palette and sizing rules. This call is |
| 83 | mandatory — the values may differ from the defaults in this skill. The server |
| 84 | guide takes precedence. |
| 85 | |
| 86 | ### Step 3 — Clear and Confirm Empty |
| 87 | |
| 88 | ``` |
| 89 | clear_canvas() |
| 90 | get_canvas_screenshot() // must verify the canvas is truly empty |
| 91 | ``` |
| 92 | |
| 93 | Previous diagrams leave ghost data even after `clear_canvas`. If any element |
| 94 | is visible in the screenshot, call `clear_canvas()` again before proceeding. |
| 95 | Do not skip this confirmation — ghost elements silently break arrow bindings |
| 96 | on new diagrams. |
| 97 | |
| 98 | ### Step 4 — Plan the Layout |
| 99 | |
| 100 | Before writing any JSON, decide: |
| 101 | |
| 102 | - **Which pattern?** — See [references/canvas-patterns.md](references/canvas-patterns.md) |
| 103 | for coordinate templates. Load it now if you are unsure which pattern fits. |
| 104 | - **Column spacing** — Labeled arrows need ≥150px clear gap between boxes. |
| 105 | Budget 440px column pitch (230px box + 210px gap) for labeled arrows. |
| 106 | - **Row pitch** — Allow ~350px per row (160px box height + 190px gap for |
| 107 | arrows, labels, and breathing room). |
| 108 | - **Zone positions** — Calculate zone backgrounds before placing shapes. |
| 109 | Zone background: `y = row_y - 50`, `height = box_height + 100`. |
| 110 | |
| 111 | Sketch coordinates to paper or comments before writing the batch payload. |
| 112 | |
| 113 | ### Step 5 — Create in One Batch |
| 114 | |
| 115 | Call `batch_create_elements` with **all elements in one payload**. Arrow |
| 116 | binding resolves at batch time — if the target shape and arrow are not in the |
| 117 | same call, the arrow will not connect. |
| 118 | |
| 119 | **Element order within the `elements` array matters for render layering:** |
| 120 | |
| 121 | 1. Zone backgrounds (large d |