$npx -y skills add coleam00/excalidraw-diagram-skill --skill excalidraw-diagramCreate Excalidraw diagram JSON files that make visual arguments. Use when the user wants to visualize workflows, architectures, or concepts.
| 1 | # Excalidraw Diagram Creator |
| 2 | |
| 3 | Generate `.excalidraw` JSON files that **argue visually**, not just display information. |
| 4 | |
| 5 | **Setup:** If the user asks you to set up this skill (renderer, dependencies, etc.), see `README.md` for instructions. |
| 6 | |
| 7 | ## Customization |
| 8 | |
| 9 | **All colors and brand-specific styles live in one file:** `references/color-palette.md`. Read it before generating any diagram and use it as the single source of truth for all color choices — shape fills, strokes, text colors, evidence artifact backgrounds, everything. |
| 10 | |
| 11 | To make this skill produce diagrams in your own brand style, edit `color-palette.md`. Everything else in this file is universal design methodology and Excalidraw best practices. |
| 12 | |
| 13 | --- |
| 14 | |
| 15 | ## Core Philosophy |
| 16 | |
| 17 | **Diagrams should ARGUE, not DISPLAY.** |
| 18 | |
| 19 | A diagram isn't formatted text. It's a visual argument that shows relationships, causality, and flow that words alone can't express. The shape should BE the meaning. |
| 20 | |
| 21 | **The Isomorphism Test**: If you removed all text, would the structure alone communicate the concept? If not, redesign. |
| 22 | |
| 23 | **The Education Test**: Could someone learn something concrete from this diagram, or does it just label boxes? A good diagram teaches—it shows actual formats, real event names, concrete examples. |
| 24 | |
| 25 | --- |
| 26 | |
| 27 | ## Depth Assessment (Do This First) |
| 28 | |
| 29 | Before designing, determine what level of detail this diagram needs: |
| 30 | |
| 31 | ### Simple/Conceptual Diagrams |
| 32 | Use abstract shapes when: |
| 33 | - Explaining a mental model or philosophy |
| 34 | - The audience doesn't need technical specifics |
| 35 | - The concept IS the abstraction (e.g., "separation of concerns") |
| 36 | |
| 37 | ### Comprehensive/Technical Diagrams |
| 38 | Use concrete examples when: |
| 39 | - Diagramming a real system, protocol, or architecture |
| 40 | - The diagram will be used to teach or explain (e.g., YouTube video) |
| 41 | - The audience needs to understand what things actually look like |
| 42 | - You're showing how multiple technologies integrate |
| 43 | |
| 44 | **For technical diagrams, you MUST include evidence artifacts** (see below). |
| 45 | |
| 46 | --- |
| 47 | |
| 48 | ## Research Mandate (For Technical Diagrams) |
| 49 | |
| 50 | **Before drawing anything technical, research the actual specifications.** |
| 51 | |
| 52 | If you're diagramming a protocol, API, or framework: |
| 53 | 1. Look up the actual JSON/data formats |
| 54 | 2. Find the real event names, method names, or API endpoints |
| 55 | 3. Understand how the pieces actually connect |
| 56 | 4. Use real terminology, not generic placeholders |
| 57 | |
| 58 | Bad: "Protocol" → "Frontend" |
| 59 | Good: "AG-UI streams events (RUN_STARTED, STATE_DELTA, A2UI_UPDATE)" → "CopilotKit renders via createA2UIMessageRenderer()" |
| 60 | |
| 61 | **Research makes diagrams accurate AND educational.** |
| 62 | |
| 63 | --- |
| 64 | |
| 65 | ## Evidence Artifacts |
| 66 | |
| 67 | Evidence artifacts are concrete examples that prove your diagram is accurate and help viewers learn. Include them in technical diagrams. |
| 68 | |
| 69 | **Types of evidence artifacts** (choose what's relevant to your diagram): |
| 70 | |
| 71 | | Artifact Type | When to Use | How to Render | |
| 72 | |---------------|-------------|---------------| |
| 73 | | **Code snippets** | APIs, integrations, implementation details | Dark rectangle + syntax-colored text (see color palette for evidence artifact colors) | |
| 74 | | **Data/JSON examples** | Data formats, schemas, payloads | Dark rectangle + colored text (see color palette) | |
| 75 | | **Event/step sequences** | Protocols, workflows, lifecycles | Timeline pattern (line + dots + labels) | |
| 76 | | **UI mockups** | Showing actual output/results | Nested rectangles mimicking real UI | |
| 77 | | **Real input content** | Showing what goes IN to a system | Rectangle with sample content visible | |
| 78 | | **API/method names** | Real function calls, endpoints | Use actual names from docs, not placeholders | |
| 79 | |
| 80 | **Example**: For a diagram about a streaming protocol, you might show: |
| 81 | - The actual event names from the spec (not just "Event 1", "Event 2") |
| 82 | - A code snippet showing how to connect |
| 83 | - What the streamed data actually looks like |
| 84 | |
| 85 | **Example**: For a diagram about a data transformation pipeline: |
| 86 | - Show sample input data (actual format, not "Input") |
| 87 | - Show sample output data (actual format, not "Output") |
| 88 | - Show intermediate states if relevant |
| 89 | |
| 90 | The key principle: **show what things actually look like**, not just what they're called. |
| 91 | |
| 92 | --- |
| 93 | |
| 94 | ## Multi-Zoom Architecture |
| 95 | |
| 96 | Comprehensive diagrams operate at multiple zoom levels simultaneously. Think of it like a map that shows both the country borders AND the street names. |
| 97 | |
| 98 | ### Level 1: Summary Flow |
| 99 | A simplified overview showing the full pipeline or process at a glance. Often placed at the top or bottom of the diagram. |
| 100 | |
| 101 | *Example*: `Input → Processing → Output` or `Client → Server → Database` |
| 102 | |
| 103 | ### Level 2: Section Boundaries |
| 104 | Labeled regions that group related components. These create visual "rooms" that help viewers understand what belongs together. |
| 105 | |
| 106 | *Example*: Grouping by responsibility (Backend / Frontend), by phase (Setup / Execution / Cleanup), or by team (User / System / External) |
| 107 | |
| 108 | ## |