excalidraw
Excalidraw files contain verbose JSON with token costs of 4,000 to 22,000 per file, making direct parsing in main context expensive relative to actionable information. Use this skill to delegate all Excalidraw operations to subagents whenever users mention diagrams, flowcharts, architecture visualization, or file paths containing `.excalidraw` or `.excalidraw.json`, ensuring main context remains available for substantive work.
git clone --depth 1 https://github.com/softaworks/agent-toolkit /tmp/excalidraw && cp -r /tmp/excalidraw/skills/excalidraw ~/.claude/skills/excalidrawSKILL.md
# Excalidraw Subagent Delegation ## Overview **Core principle:** Main agents NEVER read Excalidraw files directly. Always delegate to subagents to isolate context consumption. Excalidraw files are JSON with high token cost but low information density. Single files range from 4k-22k tokens (largest can exceed read tool limits). Reading multiple diagrams quickly exhausts context budget (7 files = 67k tokens = 33% of budget). ## The Problem Excalidraw JSON structure: - Each shape has 20+ properties (x, y, width, height, strokeColor, seed, version, etc.) - Most properties are visual metadata (positioning, styling, roughness) - Actual content: text labels and element relationships (<10% of file) - **Signal-to-noise ratio is extremely low** Example: 14-element diagram = 596 lines, 16K, ~4k tokens. 79-element diagram = 2,916 lines, 88K, ~22k tokens (exceeds read limit). ## When to Use **Trigger on ANY of these:** - File path contains `.excalidraw` or `.excalidraw.json` - User requests: "explain/update/create diagram", "show architecture", "visualize flow" - User mentions: "flowchart", "architecture diagram", "Excalidraw file" - Architecture/design documentation tasks involving visual artifacts **Use delegation even for:** - "Small" files (smallest is 4k tokens - still significant) - "Quick checks" (checking component names still loads full JSON) - Single file operations (isolation prevents context pollution) - Modifications (don't need full format understanding in main context) ## Delegation Pattern ### Main Agent Responsibilities **NEVER:** - ❌ Use Read tool on *.excalidraw files - ❌ Parse Excalidraw JSON in main context - ❌ Load multiple diagrams for comparison - ❌ Inspect file to "understand the format" **ALWAYS:** - ✅ Delegate ALL Excalidraw operations to subagents - ✅ Provide clear task description to subagent - ✅ Request text-only summaries (not raw JSON) - ✅ Keep diagram analysis isolated from main work ### Subagent Task Templates #### Read/Understand Operation ``` Task: Extract and explain the components in [file.excalidraw.json] Approach: 1. Read the Excalidraw JSON 2. Extract only text elements (ignore positioning/styling) 3. Identify relationships between components 4. Summarize architecture/flow Return: - List of components/services with descriptions - Connection/dependency relationships - Key insights about the architecture - DO NOT return raw JSON or verbose element details ``` #### Modify Operation ``` Task: Add [component] to [file.excalidraw.json], connected to [existing-component] Approach: 1. Read file to identify existing elements 2. Find [existing-component] and its position 3. Create new element JSON for [component] 4. Add arrow elements for connections 5. Write updated file Return: - Confirmation of changes made - Position of new element - IDs of created elements ``` #### Create Operation ``` Task: Create new Excalidraw diagram showing [description] Approach: 1. Design layout for [number] components 2. Create rectangle elements with text labels 3. Add arrows showing relationships 4. Use consistent styling (colors, fonts) 5. Write to [file.excalidraw.json] Return: - Confirmation of file created - Summary of components included - File location ``` #### Compare Operation ``` Task: Compare architecture approaches in [file1] vs [file2] Approach: 1. Read both files 2. Extract text labels from each 3. Identify structural differences 4. Compare component relationships Return: - Key differences in architecture - Components unique to each approach - Relationship/flow differences - DO NOT return full element details from both files ``` ## Common Rationalizations (STOP and Delegate Instead) | Excuse | Reality | What to Do | |--------|---------|------------| | "Direct reading is most efficient" | Consumes 4k-22k tokens unnecessarily | Delegate to subagent | | "It's token-efficient to read directly" | Baseline tests showed 9-45% budget used | Always delegate | | "This is optimal for one-time analysis" | "One-time" still pollutes main context | Subagent isolation | | "The JSON is straightforward" | Simplicity ≠ token efficiency | Delegate anyway | | "I need to understand the format" | Format understanding not needed in main agent | Subagent handles format | | "Within reasonable bounds" (18k tokens) | "Reasonable" is subjective rationalization | Hard rule: delegate | | "Just a quick check of components" | "Quick check" still loads full JSON | Extract text via subagent | | "File is small (16K)" | 4k tokens is NOT small | Size threshold doesn't matter | ## Red Flags - STOP and Delegate Catch yourself about to: - Use Read tool on .excalidraw file - "Quickly check" what components exist - "Understand the structure" before modifying - Load file to "see what's there" - Compare multiple diagrams side-by-side - Parse JSON to "extract just the text" **All of these mean: Use Task tool with subagent instead.** ## Quick Reference | Operation | Main Agent Action | Subagent Returns | |-----------|-------------------|------------------| | **Understand diagram** | Delegate with "Extract and explain" template | Component list + relationships | | **Modify diagram** | Delegate with "Add [X] connected to [Y]" template | Confirmation + changes made | | **Create diagram** | Delegate with "Create showing [description]" template | File location + summary | | **Compare diagrams** | Delegate with "Compare [A] vs [B]" template | Key differences (not raw JSON) | ## Token Analysis (Why This Matters) Real data from baseline testing: | Scenario | Without Delegation | With Delegation | Savings | |----------|-------------------|-----------------|---------| | Single large file | 22k tokens (45% budget) | ~500 tokens (subagent summary) | 98% | | Two-file comparison | 18k tokens (9% budget) | ~800 tokens (diff summary) | 96% | | Modification task | 14k tokens (7% budget) | ~300 tokens (confirmation) | 98% | **Context pollution impact:** - Reading all 7 project diagrams: 67k tokens (33%
Refactor bloated AGENTS.md, CLAUDE.md, or similar agent instruction files to follow progressive disclosure principles. Splits monolithic files into organized, linked documentation.
Use this agent when you need to visualize UI concepts through ASCII mockups before implementation. Examples: <example>Context: User has an idea for a dashboard layout with data tables and charts. user: 'I want to create a dashboard that shows user analytics with a sidebar navigation, main content area with charts, and a data table below' assistant: 'I'll use the ascii-ui-mockup-generator agent to create multiple ASCII mockup variations for your dashboard concept.' <commentary>The user wants to visualize a UI concept, so use the ascii-ui-mockup-generator to create multiple ASCII representations they can choose from.</commentary></example> <example>Context: User is designing a form layout with multiple input fields. user: 'I need a contact form with name, email, message fields and a submit button' assistant: 'Let me use the ascii-ui-mockup-generator to create several ASCII mockup options for your contact form layout.' <commentary>Since the user needs to visualize form layouts, use the ascii-ui-mockup-generator to provide multiple ASCII design options.</commentary></example>
Create API handoff documentation for frontend developers. Use when backend work is complete and needs to be documented for frontend integration, or user says 'create handoff', 'document API', 'frontend handoff', or 'API documentation'.
Generate architecture documentation using C4 model Mermaid diagrams. Use when asked to create architecture diagrams, document system architecture, visualize software structure, create C4 diagrams, or generate context/container/component/deployment diagrams. Triggers include "architecture diagram", "C4 diagram", "system context", "container diagram", "component diagram", "deployment diagram", "document architecture", "visualize architecture".
codebase-pattern-finder is a useful subagent_type for finding similar implementations, usage examples, or existing patterns that can be modeled after. It will give you concrete code examples based on what you're looking for! It's sorta like codebase-locator, but it will not only tell you the location of files, it will also give you code details!
Use when the user asks to run Codex CLI (codex exec, codex resume) or references OpenAI Codex for code analysis, refactoring, or automated editing. Uses GPT-5.2 by default for state-of-the-art software engineering.
Create a detailed implementation plan using Codex 5.2 with high reasoning
This skill should be used when creating a Claude Code slash command. Use when users ask to "create a command", "make a slash command", "add a command", or want to document a workflow as a reusable command. Essential for creating optimized, agent-executable slash commands with proper structure and best practices.