$npx -y skills add AlexAI-MCP/hermes-CCC --skill excalidrawCreate and export diagrams with Excalidraw - whiteboard-style sketches, flowcharts, architecture diagrams via MCP or CLI.
| 1 | # Excalidraw |
| 2 | |
| 3 | ## Purpose |
| 4 | |
| 5 | - Use this skill to create lightweight diagrams, sketches, and whiteboard-style visuals quickly. |
| 6 | - Prefer Excalidraw when the output should feel hand-drawn, fast to edit, and easy to embed into notes or design docs. |
| 7 | - This skill works well for architecture reviews, brainstorming, flowcharts, and teaching visuals. |
| 8 | - In this environment, Excalidraw MCP tooling is already available. |
| 9 | |
| 10 | ## Core Mental Model |
| 11 | |
| 12 | - Describe the diagram you want in plain language. |
| 13 | - Claude can translate that description into an Excalidraw JSON scene specification. |
| 14 | - The scene can then be rendered in a view, exported, saved as a checkpoint, or shared through Excalidraw. |
| 15 | - Treat the JSON spec as the source of truth for reproducible diagram generation. |
| 16 | |
| 17 | ## MCP Integration |
| 18 | |
| 19 | - Use `mcp__claude_ai_excalidraw__create_view` to generate or render a diagram view from a structured scene. |
| 20 | - Use `mcp__claude_ai_excalidraw__export_to_excalidraw` to export the scene into a format compatible with Excalidraw workflows. |
| 21 | - Use `save_checkpoint` to preserve an intermediate diagram state before large edits. |
| 22 | - Use `read_checkpoint` to reload a previously saved scene when you need to continue, branch, or recover. |
| 23 | - A good workflow is: describe -> generate JSON -> create view -> inspect -> checkpoint -> revise -> export. |
| 24 | |
| 25 | ## What To Ask For |
| 26 | |
| 27 | - "Draw a system architecture diagram for a FastAPI app backed by Postgres and Redis." |
| 28 | - "Create a flowchart for user sign-up with email verification." |
| 29 | - "Sketch an ERD with users, teams, memberships, and permissions." |
| 30 | - "Make a sequence diagram for browser -> API -> worker -> database." |
| 31 | - "Turn this process into a whiteboard-style diagram with short labels and arrows." |
| 32 | |
| 33 | ## Describe First, Then Refine |
| 34 | |
| 35 | - Start with the intent of the diagram, not low-level coordinates. |
| 36 | - Include the major entities, the relationships, and the desired reading direction. |
| 37 | - Mention whether you want a rough sketch, a cleaner box-and-arrow layout, or a board-like visual. |
| 38 | - If the first result is too dense, ask for fewer labels or more spacing. |
| 39 | - If the first result is too vague, specify grouping, order, and arrow directions. |
| 40 | |
| 41 | ## Scene Building Blocks |
| 42 | |
| 43 | - `rectangle`: best for services, systems, containers, and grouped components. |
| 44 | - `ellipse`: useful for external actors, start/end states, or soft conceptual nodes. |
| 45 | - `arrow`: best for directional relationships, calls, control flow, and data movement. |
| 46 | - `line`: useful for visual separators, boundaries, or non-directional links. |
| 47 | - `text`: labels, notes, titles, annotations, and step numbers. |
| 48 | - `diamond`: decision points in a flowchart or branching logic. |
| 49 | |
| 50 | ## Common Diagram Types |
| 51 | |
| 52 | ### System Architecture |
| 53 | |
| 54 | - Use rectangles for services, databases, queues, and external providers. |
| 55 | - Use arrows to show request flow, event flow, and data movement. |
| 56 | - Group related services into logical zones such as frontend, backend, storage, and third-party systems. |
| 57 | - Add short text notes for protocols like HTTP, gRPC, Kafka, or WebSocket. |
| 58 | |
| 59 | ### Flowchart |
| 60 | |
| 61 | - Use rectangles for actions. |
| 62 | - Use diamonds for decisions. |
| 63 | - Use arrows for the main control path. |
| 64 | - Keep text short and action-oriented. |
| 65 | - Prefer top-to-bottom or left-to-right consistency. |
| 66 | |
| 67 | ### ERD |
| 68 | |
| 69 | - Use rectangles to represent tables or entities. |
| 70 | - Put the entity name at the top and key fields below as text. |
| 71 | - Use arrows or simple connecting lines to show relationships. |
| 72 | - Label one-to-many or many-to-many edges with short text if needed. |
| 73 | - Keep column lists focused on primary keys, foreign keys, and the fields relevant to the explanation. |
| 74 | |
| 75 | ### Sequence Diagram |
| 76 | |
| 77 | - Use text labels for actors across the top. |
| 78 | - Use vertical lines or repeated arrows to indicate message order. |
| 79 | - Use arrows with labels like `POST /login`, `enqueue job`, or `ACK`. |
| 80 | - Number key steps if the interaction is long. |
| 81 | - Keep parallel flows separated visually rather than forcing too many crossing arrows. |
| 82 | |
| 83 | ## Practical Prompt Patterns |
| 84 | |
| 85 | - "Create a whiteboard-style architecture diagram with six boxes and directional arrows." |
| 86 | - "Make the frontend, API, and worker visually separated into columns." |
| 87 | - "Use a decision diamond after payment validation." |
| 88 | - "Add labels to arrows showing request type and payload." |
| 89 | - "Keep the style sketchy and informal, suitable for an engineering design note." |
| 90 | |
| 91 | ## Suggested JSON Planning |
| 92 | |
| 93 | - Think in terms of elements, labels, and relationships. |
| 94 | - Define each node first. |
| 95 | - Define the connectors second. |
| 96 | - Add titles and notes last. |
| 97 | - Keep IDs stable if you expect to revise the same diagram repeatedly. |
| 98 | |
| 99 | ## Revision Workflow |
| 100 | |
| 101 | - Generate the initial scene from a natural-language description. |
| 102 | - Rend |