[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M71G21PQKBCDECHGVYSKPJW5":3,"skill-same:01M71G21PQKBCDECHGVYSKPJW5":104},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":16,"categories":17,"keywords":18,"publishedAt":31,"linkOnly":32,"markdownContent":33,"markdownBody":34,"frontMatter":35,"refName":36,"commitSha":37,"skillDirectory":38,"forksCount":14,"repositoryHtmlUrl":39,"repositoryHomepageUrl":6,"ownerHtmlUrl":40,"ownerBlogUrl":41,"ownerDescription":42,"updatedAt":43,"install":44,"resources":57},"01M71G21PQKBCDECHGVYSKPJW5","draw-excalidraw",null,"ALWAYS invoke this skill when creating Excalidraw diagrams, visualizing workflows, architectures, or concepts. NEVER generate Excalidraw JSON without this skill.","outcomeeng\u002Fplugins","outcomeeng","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F257335685?v=4","01M71FRVRF36XYR3HRSCGFHK2R","Outcome Engineering","01M71FRVS4BZG17DWANFJ7EPNY",1,"MIT","https:\u002F\u002Fgithub.com\u002Foutcomeeng\u002Fplugins\u002Fblob\u002Fmain\u002Fsrc\u002Fplugins\u002Fwork\u002Fskills\u002Fdraw-excalidraw\u002FSKILL.md",[],[19,20,21,22,23,24,25,26,27,28,29,30],"draw","excalidraw","draw excalidraw","diagrams","architectures","never","invoke","generate","workflows","when","concepts","json","2026-11-10 10:12:30",false,"---\nname: draw-excalidraw\ndescription: >-\n  ALWAYS invoke this skill when creating Excalidraw diagrams, visualizing workflows, architectures, or concepts.\n  NEVER generate Excalidraw JSON without this skill.\n---\n\n\u003Cobjective>\nAn `.excalidraw` JSON file that **argues visually**, not just displays information.\n\u003C\u002Fobjective>\n\n\u003Ccustomization>\n**All colors and brand-specific styles live in one file:** `references\u002Fcolor-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.\n\nTo 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.\n\u003C\u002Fcustomization>\n\n\u003Cquick_start>\n\n1. **Assess depth** — Simple\u002Fconceptual or comprehensive\u002Ftechnical?\n2. **Research** (technical only) — Look up actual specs, formats, event names\n3. **Map concepts to visual patterns** — See `references\u002Fvisual-patterns.md`\n4. **Design before JSON** — Sketch the flow mentally, ensure variety\n5. **Generate JSON** — Section-by-section for large diagrams (see `references\u002Flarge-diagrams.md`)\n6. **Render & validate** — Run the render-view-fix loop until it's right\n\nPull colors from `references\u002Fcolor-palette.md`, element templates from `references\u002Felement-templates.md`, and JSON schema from `references\u002Fjson-schema.md`.\n\n\u003C\u002Fquick_start>\n\n\u003Cphilosophy>\n**Diagrams should ARGUE, not DISPLAY.**\n\nA 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.\n\n**The Isomorphism Test**: With all text removed, would the structure alone communicate the concept? If not, redesign.\n\n**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.\n\u003C\u002Fphilosophy>\n\n\u003Cdepth_assessment>\nBefore designing, determine what level of detail this diagram needs:\n\n**Simple\u002FConceptual Diagrams** — Use abstract shapes when:\n\n- Explaining a mental model or philosophy\n- The audience doesn't need technical specifics\n- The concept IS the abstraction (e.g., \"separation of concerns\")\n\n**Comprehensive\u002FTechnical Diagrams** — Use concrete examples when:\n\n- Diagramming a real system, protocol, or architecture\n- The diagram will be used to teach or explain (e.g., YouTube video)\n- The audience needs to understand what things actually look like\n- The diagram shows how multiple technologies integrate\n\n**For technical diagrams, MUST include evidence artifacts and do research first.**\n\u003C\u002Fdepth_assessment>\n\n\u003Cresearch_mandate>\n**Before drawing anything technical, research the actual specifications.**\n\nWhen diagramming a protocol, API, or framework:\n\n1. Look up the actual JSON\u002Fdata formats\n2. Find the real event names, method names, or API endpoints\n3. Understand how the pieces actually connect\n4. Use real terminology, not generic placeholders\n\nBad: \"Protocol\" → \"Frontend\"\nGood: \"AG-UI streams events (RUN_STARTED, STATE_DELTA, A2UI_UPDATE)\" → \"CopilotKit renders via createA2UIMessageRenderer()\"\n\n**Research makes diagrams accurate AND educational.**\n\u003C\u002Fresearch_mandate>\n\n\u003Cevidence_artifacts>\nEvidence artifacts are concrete examples that prove the diagram is accurate and help viewers learn. Include them in technical diagrams.\n\n**Types of evidence artifacts** (choose what's relevant to the diagram):\n\n| Artifact Type            | When to Use                                | How to Render                                                                         |\n| ------------------------ | ------------------------------------------ | ------------------------------------------------------------------------------------- |\n| **Code snippets**        | APIs, integrations, implementation details | Dark rectangle + syntax-colored text (see color palette for evidence artifact colors) |\n| **Data\u002FJSON examples**   | Data formats, schemas, payloads            | Dark rectangle + colored text (see color palette)                                     |\n| **Event\u002Fstep sequences** | Protocols, workflows, lifecycles           | Timeline pattern (line + dots + labels)                                               |\n| **UI mockups**           | Showing actual output\u002Fresults              | Nested rectangles mimicking real UI                                                   |\n| **Real input content**   | Showing what goes IN to a system           | Rectangle with sample content visible                                                 |\n| **API\u002Fmethod names**     | Real function calls, endpoints             | Use actual names from docs, not placeholders                                          |\n\nThe key principle: **show what things actually look like**, not just what they're called.\n\u003C\u002Fevidence_artifacts>\n\n\u003Cmulti_zoom>\nComprehensive diagrams operate at multiple zoom levels simultaneously:\n\n**Level 1: Summary Flow** — A simplified overview showing the full pipeline at a glance. Often placed at the top or bottom.\n\n**Level 2: Section Boundaries** — Labeled regions that group related components. These create visual \"rooms\" that help viewers understand what belongs together.\n\n**Level 3: Detail Inside Sections** — Evidence artifacts, code snippets, and concrete examples within each section. This is where the educational value lives.\n\n**For comprehensive diagrams, aim to include all three levels.** The summary gives context, the sections organize, and the details teach.\n\n| Bad (Displaying)              | Good (Arguing)                                     |\n| ----------------------------- | -------------------------------------------------- |\n| 5 equal boxes with labels     | Each concept has a shape that mirrors its behavior |\n| Card grid layout              | Visual structure matches conceptual structure      |\n| Icons decorating text         | Shapes that ARE the meaning                        |\n| Same container for everything | Distinct visual vocabulary per concept             |\n| Everything in a box           | Free-floating text with selective containers       |\n\n\u003C\u002Fmulti_zoom>\n\n\u003Ccontainer_discipline>\n**Not every piece of text needs a shape around it.** Default to free-floating text. Add containers only when they serve a purpose.\n\n| Use a Container When...                                   | Use Free-Floating Text When...                |\n| --------------------------------------------------------- | --------------------------------------------- |\n| It's the focal point of a section                         | It's a label or description                   |\n| It needs visual grouping with other elements              | It's supporting detail or metadata            |\n| Arrows need to connect to it                              | It describes something nearby                 |\n| The shape itself carries meaning (decision diamond, etc.) | Typography alone creates sufficient hierarchy |\n| It represents a distinct \"thing\" in the system            | It's a section title, subtitle, or annotation |\n\n**Typography as hierarchy**: Use font size, weight, and color to create visual hierarchy without boxes. A 28px title doesn't need a rectangle around it.\n\n**The container test**: For each boxed element, ask \"Would this work as free-floating text?\" If yes, remove the container.\n\u003C\u002Fcontainer_discipline>\n\n\u003Cdesign_process>\nDo this BEFORE generating JSON:\n\n**Step 0: Assess Depth** — Simple\u002Fconceptual or comprehensive\u002Ftechnical? If comprehensive, do research first.\n\n**Step 1: Understand Deeply** — For each concept, ask:\n\n- What does this concept **DO**? (not what IS it)\n- What relationships exist between concepts?\n- What's the core transformation or flow?\n- **What would someone need to SEE to understand this?**\n\n**Step 2: Map Concepts to Patterns** — See `references\u002Fvisual-patterns.md` for the full pattern library and concept-to-pattern mapping table.\n\n**Step 3: Ensure Variety** — Each major concept must use a different visual pattern. No uniform cards or grids.\n\n**Step 4: Sketch the Flow** — Mentally trace how the eye moves through the diagram. There should be a clear visual story.\n\n**Step 5: Generate JSON** — For large\u002Fcomprehensive diagrams, build section-by-section (see `references\u002Flarge-diagrams.md`). Use descriptive string IDs and namespace seeds by section.\n\n**Step 6: Render & Validate (MANDATORY)** — Run the render-view-fix loop until the diagram looks right. See `\u003Crender_validate>` below.\n\u003C\u002Fdesign_process>\n\n\u003Ccolor_usage>\nColors encode information, not decoration. Every color choice should come from `references\u002Fcolor-palette.md`.\n\n**Key principles:**\n\n- Each semantic purpose (start, end, decision, AI, error, etc.) has a specific fill\u002Fstroke pair\n- Free-floating text uses color for hierarchy (titles, subtitles, details — each at a different level)\n- Evidence artifacts (code snippets, JSON examples) use their own dark background + colored text scheme\n- Always pair a darker stroke with a lighter fill for contrast\n\n**Do not invent new colors.** If a concept doesn't fit an existing semantic category, use Primary\u002FNeutral or Secondary.\n\u003C\u002Fcolor_usage>\n\n\u003Caesthetics>\n**Roughness:**\n\n- `roughness: 0` — Clean, crisp edges. **Default** for modern\u002Ftechnical diagrams.\n- `roughness: 1` — Hand-drawn, organic feel. Use for brainstorming\u002Finformal diagrams.\n\n**Stroke Width:**\n\n- `strokeWidth: 1` — Thin, elegant. Good for lines, dividers, subtle connections.\n- `strokeWidth: 2` — Standard. Good for shapes and primary arrows.\n- `strokeWidth: 3` — Bold. Use sparingly for emphasis.\n\n**Opacity:** Always `opacity: 100`. Use color, size, and stroke width for hierarchy instead of transparency.\n\n**Small markers:** Use small dots (10-20px ellipses) instead of full shapes for timeline markers, bullet points, connection nodes, and visual anchors.\n\u003C\u002Faesthetics>\n\n\u003Clayout>\n**Hierarchy Through Scale:**\n\n- **Hero**: 300×150 — visual anchor, most important\n- **Primary**: 180×90\n- **Secondary**: 120×60\n- **Small**: 60×40\n\n**Whitespace = Importance:** The most important element has the most empty space around it (200px+).\n\n**Flow Direction:** Left→right or top→bottom for sequences, radial for hub-and-spoke.\n\n**Connections Required:** Position alone doesn't show relationships. If A relates to B, there must be an arrow.\n\u003C\u002Flayout>\n\n\u003Ctext_rules>\n**CRITICAL**: The JSON `text` property contains ONLY readable words.\n\n```json\n{\n  \"id\": \"myElement1\",\n  \"text\": \"Start\",\n  \"originalText\": \"Start\"\n}\n```\n\nSettings: `fontSize: 16`, `fontFamily: 3`, `textAlign: \"center\"`, `verticalAlign: \"middle\"`\n\u003C\u002Ftext_rules>\n\n\u003Cjson_structure>\n\n```json\n{\n  \"type\": \"excalidraw\",\n  \"version\": 2,\n  \"source\": \"https:\u002F\u002Fexcalidraw.com\",\n  \"elements\": [],\n  \"appState\": {\n    \"viewBackgroundColor\": \"#ffffff\",\n    \"gridSize\": 20\n  },\n  \"files\": {}\n}\n```\n\nSee `references\u002Felement-templates.md` for copy-paste JSON templates for each element type (text, line, dot, rectangle, arrow). See `references\u002Fjson-schema.md` for the complete element schema. Pull colors from `references\u002Fcolor-palette.md` based on each element's semantic purpose.\n\u003C\u002Fjson_structure>\n\n\u003Crender_validate>\nA diagram cannot be judged from JSON alone. After generating or editing the Excalidraw JSON, MUST render it to PNG, view the image, and fix what the render shows — in a loop until it's right.\n\n**GATE: Before first render**, verify the `.excalidraw` file is valid JSON:\n\n```bash\npython3 -m json.tool \u003C path-to-file.excalidraw > \u002Fdev\u002Fnull\n```\n\nIf invalid, fix JSON syntax before wasting a render cycle.\n\n**How to render:**\n\n```bash\ncd ${CLAUDE_SKILL_DIR}\u002Freferences && uv run python render_excalidraw.py \u003Cpath-to-file.excalidraw>\n```\n\nThis outputs a PNG next to the `.excalidraw` file. Then use the **Read tool** on the PNG to view it.\n\n**The loop:**\n\n1. **Render & View** — Run the render script, then Read the PNG.\n2. **Audit against the original vision** — Does the visual structure match the planned conceptual structure? Does each section use the intended pattern? Is the visual hierarchy correct?\n3. **Check for visual defects:**\n   - Text clipped by or overflowing its container\n   - Text or shapes overlapping other elements\n   - Arrows crossing through elements instead of routing around them\n   - Arrows landing on the wrong element or pointing into empty space\n   - Labels floating ambiguously\n   - Uneven spacing, text too small, lopsided composition\n4. **Fix** — Edit the JSON. Common fixes: widen containers, adjust `x`\u002F`y` coordinates, add waypoints to arrow `points` arrays, reposition labels, resize elements.\n5. **Re-render & re-view** — Repeat until the diagram passes both the vision check and the defect check. Typically 2-4 iterations.\n\n**When to stop:** No text clipped or overlapping, arrows route cleanly, spacing is consistent, composition is balanced, and it is presentable without caveats.\n\n**First-time setup:**\n\n```bash\ncd ${CLAUDE_SKILL_DIR}\u002Freferences\nuv sync\nuv run playwright install chromium\n```\n\n\u003C\u002Frender_validate>\n\n\u003Cfailure_modes>\nFailures from actual usage:\n\n**Failure 1: JSON truncated mid-generation**\n\n- What happened: Claude generated the entire diagram in one response, hit the output token limit, and produced invalid JSON\n- Why it failed: Comprehensive diagrams exceed ~32,000 token output limit\n- How to avoid: ALWAYS build section-by-section for large diagrams. See `references\u002Flarge-diagrams.md`\n\n**Failure 2: Text clipped by container**\n\n- What happened: Claude let text overflow the rectangle bounds though the JSON looked fine\n- Why it failed: Container `width`\u002F`height` not updated after changing text content\n- How to avoid: After changing any `text` property, recalculate and update the container dimensions. Always verify with a render cycle.\n\n**Failure 3: Arrow bound to wrong element**\n\n- What happened: Claude bound the arrow to element A while it visually pointed at element B\n- Why it failed: IDs were reused or copy-pasted without updating `startBinding`\u002F`endBinding`\n- How to avoid: Use descriptive unique IDs (e.g., `\"auth_flow_arrow\"`, not `\"arrow1\"`). After every arrow edit, verify both `startBinding.elementId` and `endBinding.elementId` reference the correct targets.\n\n**Failure 4: All boxes same size — \"card grid\" anti-pattern**\n\n- What happened: Claude produced a diagram that looked like a PowerPoint slide with equal rectangles\n- Why it failed: Skipped Step 2 (map concepts to patterns) and defaulted to uniform containers\n- How to avoid: Each major concept MUST use a different visual pattern. Run the Isomorphism Test before generating JSON.\n\n\u003C\u002Ffailure_modes>\n\n\u003Csuccess_criteria>\n\n**Depth & Evidence** (technical diagrams):\n\n- [ ] Research done — actual specs, formats, event names looked up\n- [ ] Evidence artifacts included — code snippets, JSON examples, or real data\n- [ ] Multi-zoom — summary flow + section boundaries + detail\n- [ ] Concrete over abstract — real content shown, not just labeled boxes\n\n**Conceptual:**\n\n- [ ] Isomorphism — each visual structure mirrors its concept's behavior\n- [ ] Argument — diagram SHOWS something text alone couldn't\n- [ ] Variety — each major concept uses a different visual pattern\n- [ ] No card grids or uniform containers\n\n**Container Discipline:**\n\n- [ ] \u003C30% of text elements inside containers\n- [ ] Lines as structure for tree\u002Ftimeline patterns\n- [ ] Typography hierarchy via font size and color\n\n**Technical:**\n\n- [ ] `text` contains only readable words\n- [ ] `fontFamily: 3`, `roughness: 0`, `opacity: 100`\n- [ ] Valid JSON (verify: `python3 -m json.tool \u003C file.excalidraw > \u002Fdev\u002Fnull`)\n\n**Visual Validation (render required):**\n\n- [ ] Rendered to PNG and visually inspected\n- [ ] No text overflow, no overlapping elements\n- [ ] Arrows land correctly, even spacing, balanced composition\n\n\u003C\u002Fsuccess_criteria>\n\n\u003Creference_guides>\n\n| File                              | When to Read                                       |\n| --------------------------------- | -------------------------------------------------- |\n| `references\u002Fcolor-palette.md`     | Before generating any diagram (colors and styles)  |\n| `references\u002Felement-templates.md` | When writing JSON (copy-paste element templates)   |\n| `references\u002Fjson-schema.md`       | When the complete element schema is needed         |\n| `references\u002Fvisual-patterns.md`   | During Step 2 (concept-to-pattern mapping)         |\n| `references\u002Flarge-diagrams.md`    | When building comprehensive\u002Fmulti-section diagrams |\n\n\u003C\u002Freference_guides>\n","\u003Cobjective>\nAn `.excalidraw` JSON file that **argues visually**, not just displays information.\n\u003C\u002Fobjective>\n\n\u003Ccustomization>\n**All colors and brand-specific styles live in one file:** `references\u002Fcolor-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.\n\nTo 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.\n\u003C\u002Fcustomization>\n\n\u003Cquick_start>\n\n1. **Assess depth** — Simple\u002Fconceptual or comprehensive\u002Ftechnical?\n2. **Research** (technical only) — Look up actual specs, formats, event names\n3. **Map concepts to visual patterns** — See `references\u002Fvisual-patterns.md`\n4. **Design before JSON** — Sketch the flow mentally, ensure variety\n5. **Generate JSON** — Section-by-section for large diagrams (see `references\u002Flarge-diagrams.md`)\n6. **Render & validate** — Run the render-view-fix loop until it's right\n\nPull colors from `references\u002Fcolor-palette.md`, element templates from `references\u002Felement-templates.md`, and JSON schema from `references\u002Fjson-schema.md`.\n\n\u003C\u002Fquick_start>\n\n\u003Cphilosophy>\n**Diagrams should ARGUE, not DISPLAY.**\n\nA 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.\n\n**The Isomorphism Test**: With all text removed, would the structure alone communicate the concept? If not, redesign.\n\n**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.\n\u003C\u002Fphilosophy>\n\n\u003Cdepth_assessment>\nBefore designing, determine what level of detail this diagram needs:\n\n**Simple\u002FConceptual Diagrams** — Use abstract shapes when:\n\n- Explaining a mental model or philosophy\n- The audience doesn't need technical specifics\n- The concept IS the abstraction (e.g., \"separation of concerns\")\n\n**Comprehensive\u002FTechnical Diagrams** — Use concrete examples when:\n\n- Diagramming a real system, protocol, or architecture\n- The diagram will be used to teach or explain (e.g., YouTube video)\n- The audience needs to understand what things actually look like\n- The diagram shows how multiple technologies integrate\n\n**For technical diagrams, MUST include evidence artifacts and do research first.**\n\u003C\u002Fdepth_assessment>\n\n\u003Cresearch_mandate>\n**Before drawing anything technical, research the actual specifications.**\n\nWhen diagramming a protocol, API, or framework:\n\n1. Look up the actual JSON\u002Fdata formats\n2. Find the real event names, method names, or API endpoints\n3. Understand how the pieces actually connect\n4. Use real terminology, not generic placeholders\n\nBad: \"Protocol\" → \"Frontend\"\nGood: \"AG-UI streams events (RUN_STARTED, STATE_DELTA, A2UI_UPDATE)\" → \"CopilotKit renders via createA2UIMessageRenderer()\"\n\n**Research makes diagrams accurate AND educational.**\n\u003C\u002Fresearch_mandate>\n\n\u003Cevidence_artifacts>\nEvidence artifacts are concrete examples that prove the diagram is accurate and help viewers learn. Include them in technical diagrams.\n\n**Types of evidence artifacts** (choose what's relevant to the diagram):\n\n| Artifact Type            | When to Use                                | How to Render                                                                         |\n| ------------------------ | ------------------------------------------ | ------------------------------------------------------------------------------------- |\n| **Code snippets**        | APIs, integrations, implementation details | Dark rectangle + syntax-colored text (see color palette for evidence artifact colors) |\n| **Data\u002FJSON examples**   | Data formats, schemas, payloads            | Dark rectangle + colored text (see color palette)                                     |\n| **Event\u002Fstep sequences** | Protocols, workflows, lifecycles           | Timeline pattern (line + dots + labels)                                               |\n| **UI mockups**           | Showing actual output\u002Fresults              | Nested rectangles mimicking real UI                                                   |\n| **Real input content**   | Showing what goes IN to a system           | Rectangle with sample content visible                                                 |\n| **API\u002Fmethod names**     | Real function calls, endpoints             | Use actual names from docs, not placeholders                                          |\n\nThe key principle: **show what things actually look like**, not just what they're called.\n\u003C\u002Fevidence_artifacts>\n\n\u003Cmulti_zoom>\nComprehensive diagrams operate at multiple zoom levels simultaneously:\n\n**Level 1: Summary Flow** — A simplified overview showing the full pipeline at a glance. Often placed at the top or bottom.\n\n**Level 2: Section Boundaries** — Labeled regions that group related components. These create visual \"rooms\" that help viewers understand what belongs together.\n\n**Level 3: Detail Inside Sections** — Evidence artifacts, code snippets, and concrete examples within each section. This is where the educational value lives.\n\n**For comprehensive diagrams, aim to include all three levels.** The summary gives context, the sections organize, and the details teach.\n\n| Bad (Displaying)              | Good (Arguing)                                     |\n| ----------------------------- | -------------------------------------------------- |\n| 5 equal boxes with labels     | Each concept has a shape that mirrors its behavior |\n| Card grid layout              | Visual structure matches conceptual structure      |\n| Icons decorating text         | Shapes that ARE the meaning                        |\n| Same container for everything | Distinct visual vocabulary per concept             |\n| Everything in a box           | Free-floating text with selective containers       |\n\n\u003C\u002Fmulti_zoom>\n\n\u003Ccontainer_discipline>\n**Not every piece of text needs a shape around it.** Default to free-floating text. Add containers only when they serve a purpose.\n\n| Use a Container When...                                   | Use Free-Floating Text When...                |\n| --------------------------------------------------------- | --------------------------------------------- |\n| It's the focal point of a section                         | It's a label or description                   |\n| It needs visual grouping with other elements              | It's supporting detail or metadata            |\n| Arrows need to connect to it                              | It describes something nearby                 |\n| The shape itself carries meaning (decision diamond, etc.) | Typography alone creates sufficient hierarchy |\n| It represents a distinct \"thing\" in the system            | It's a section title, subtitle, or annotation |\n\n**Typography as hierarchy**: Use font size, weight, and color to create visual hierarchy without boxes. A 28px title doesn't need a rectangle around it.\n\n**The container test**: For each boxed element, ask \"Would this work as free-floating text?\" If yes, remove the container.\n\u003C\u002Fcontainer_discipline>\n\n\u003Cdesign_process>\nDo this BEFORE generating JSON:\n\n**Step 0: Assess Depth** — Simple\u002Fconceptual or comprehensive\u002Ftechnical? If comprehensive, do research first.\n\n**Step 1: Understand Deeply** — For each concept, ask:\n\n- What does this concept **DO**? (not what IS it)\n- What relationships exist between concepts?\n- What's the core transformation or flow?\n- **What would someone need to SEE to understand this?**\n\n**Step 2: Map Concepts to Patterns** — See `references\u002Fvisual-patterns.md` for the full pattern library and concept-to-pattern mapping table.\n\n**Step 3: Ensure Variety** — Each major concept must use a different visual pattern. No uniform cards or grids.\n\n**Step 4: Sketch the Flow** — Mentally trace how the eye moves through the diagram. There should be a clear visual story.\n\n**Step 5: Generate JSON** — For large\u002Fcomprehensive diagrams, build section-by-section (see `references\u002Flarge-diagrams.md`). Use descriptive string IDs and namespace seeds by section.\n\n**Step 6: Render & Validate (MANDATORY)** — Run the render-view-fix loop until the diagram looks right. See `\u003Crender_validate>` below.\n\u003C\u002Fdesign_process>\n\n\u003Ccolor_usage>\nColors encode information, not decoration. Every color choice should come from `references\u002Fcolor-palette.md`.\n\n**Key principles:**\n\n- Each semantic purpose (start, end, decision, AI, error, etc.) has a specific fill\u002Fstroke pair\n- Free-floating text uses color for hierarchy (titles, subtitles, details — each at a different level)\n- Evidence artifacts (code snippets, JSON examples) use their own dark background + colored text scheme\n- Always pair a darker stroke with a lighter fill for contrast\n\n**Do not invent new colors.** If a concept doesn't fit an existing semantic category, use Primary\u002FNeutral or Secondary.\n\u003C\u002Fcolor_usage>\n\n\u003Caesthetics>\n**Roughness:**\n\n- `roughness: 0` — Clean, crisp edges. **Default** for modern\u002Ftechnical diagrams.\n- `roughness: 1` — Hand-drawn, organic feel. Use for brainstorming\u002Finformal diagrams.\n\n**Stroke Width:**\n\n- `strokeWidth: 1` — Thin, elegant. Good for lines, dividers, subtle connections.\n- `strokeWidth: 2` — Standard. Good for shapes and primary arrows.\n- `strokeWidth: 3` — Bold. Use sparingly for emphasis.\n\n**Opacity:** Always `opacity: 100`. Use color, size, and stroke width for hierarchy instead of transparency.\n\n**Small markers:** Use small dots (10-20px ellipses) instead of full shapes for timeline markers, bullet points, connection nodes, and visual anchors.\n\u003C\u002Faesthetics>\n\n\u003Clayout>\n**Hierarchy Through Scale:**\n\n- **Hero**: 300×150 — visual anchor, most important\n- **Primary**: 180×90\n- **Secondary**: 120×60\n- **Small**: 60×40\n\n**Whitespace = Importance:** The most important element has the most empty space around it (200px+).\n\n**Flow Direction:** Left→right or top→bottom for sequences, radial for hub-and-spoke.\n\n**Connections Required:** Position alone doesn't show relationships. If A relates to B, there must be an arrow.\n\u003C\u002Flayout>\n\n\u003Ctext_rules>\n**CRITICAL**: The JSON `text` property contains ONLY readable words.\n\n```json\n{\n  \"id\": \"myElement1\",\n  \"text\": \"Start\",\n  \"originalText\": \"Start\"\n}\n```\n\nSettings: `fontSize: 16`, `fontFamily: 3`, `textAlign: \"center\"`, `verticalAlign: \"middle\"`\n\u003C\u002Ftext_rules>\n\n\u003Cjson_structure>\n\n```json\n{\n  \"type\": \"excalidraw\",\n  \"version\": 2,\n  \"source\": \"https:\u002F\u002Fexcalidraw.com\",\n  \"elements\": [],\n  \"appState\": {\n    \"viewBackgroundColor\": \"#ffffff\",\n    \"gridSize\": 20\n  },\n  \"files\": {}\n}\n```\n\nSee `references\u002Felement-templates.md` for copy-paste JSON templates for each element type (text, line, dot, rectangle, arrow). See `references\u002Fjson-schema.md` for the complete element schema. Pull colors from `references\u002Fcolor-palette.md` based on each element's semantic purpose.\n\u003C\u002Fjson_structure>\n\n\u003Crender_validate>\nA diagram cannot be judged from JSON alone. After generating or editing the Excalidraw JSON, MUST render it to PNG, view the image, and fix what the render shows — in a loop until it's right.\n\n**GATE: Before first render**, verify the `.excalidraw` file is valid JSON:\n\n```bash\npython3 -m json.tool \u003C path-to-file.excalidraw > \u002Fdev\u002Fnull\n```\n\nIf invalid, fix JSON syntax before wasting a render cycle.\n\n**How to render:**\n\n```bash\ncd ${CLAUDE_SKILL_DIR}\u002Freferences && uv run python render_excalidraw.py \u003Cpath-to-file.excalidraw>\n```\n\nThis outputs a PNG next to the `.excalidraw` file. Then use the **Read tool** on the PNG to view it.\n\n**The loop:**\n\n1. **Render & View** — Run the render script, then Read the PNG.\n2. **Audit against the original vision** — Does the visual structure match the planned conceptual structure? Does each section use the intended pattern? Is the visual hierarchy correct?\n3. **Check for visual defects:**\n   - Text clipped by or overflowing its container\n   - Text or shapes overlapping other elements\n   - Arrows crossing through elements instead of routing around them\n   - Arrows landing on the wrong element or pointing into empty space\n   - Labels floating ambiguously\n   - Uneven spacing, text too small, lopsided composition\n4. **Fix** — Edit the JSON. Common fixes: widen containers, adjust `x`\u002F`y` coordinates, add waypoints to arrow `points` arrays, reposition labels, resize elements.\n5. **Re-render & re-view** — Repeat until the diagram passes both the vision check and the defect check. Typically 2-4 iterations.\n\n**When to stop:** No text clipped or overlapping, arrows route cleanly, spacing is consistent, composition is balanced, and it is presentable without caveats.\n\n**First-time setup:**\n\n```bash\ncd ${CLAUDE_SKILL_DIR}\u002Freferences\nuv sync\nuv run playwright install chromium\n```\n\n\u003C\u002Frender_validate>\n\n\u003Cfailure_modes>\nFailures from actual usage:\n\n**Failure 1: JSON truncated mid-generation**\n\n- What happened: Claude generated the entire diagram in one response, hit the output token limit, and produced invalid JSON\n- Why it failed: Comprehensive diagrams exceed ~32,000 token output limit\n- How to avoid: ALWAYS build section-by-section for large diagrams. See `references\u002Flarge-diagrams.md`\n\n**Failure 2: Text clipped by container**\n\n- What happened: Claude let text overflow the rectangle bounds though the JSON looked fine\n- Why it failed: Container `width`\u002F`height` not updated after changing text content\n- How to avoid: After changing any `text` property, recalculate and update the container dimensions. Always verify with a render cycle.\n\n**Failure 3: Arrow bound to wrong element**\n\n- What happened: Claude bound the arrow to element A while it visually pointed at element B\n- Why it failed: IDs were reused or copy-pasted without updating `startBinding`\u002F`endBinding`\n- How to avoid: Use descriptive unique IDs (e.g., `\"auth_flow_arrow\"`, not `\"arrow1\"`). After every arrow edit, verify both `startBinding.elementId` and `endBinding.elementId` reference the correct targets.\n\n**Failure 4: All boxes same size — \"card grid\" anti-pattern**\n\n- What happened: Claude produced a diagram that looked like a PowerPoint slide with equal rectangles\n- Why it failed: Skipped Step 2 (map concepts to patterns) and defaulted to uniform containers\n- How to avoid: Each major concept MUST use a different visual pattern. Run the Isomorphism Test before generating JSON.\n\n\u003C\u002Ffailure_modes>\n\n\u003Csuccess_criteria>\n\n**Depth & Evidence** (technical diagrams):\n\n- [ ] Research done — actual specs, formats, event names looked up\n- [ ] Evidence artifacts included — code snippets, JSON examples, or real data\n- [ ] Multi-zoom — summary flow + section boundaries + detail\n- [ ] Concrete over abstract — real content shown, not just labeled boxes\n\n**Conceptual:**\n\n- [ ] Isomorphism — each visual structure mirrors its concept's behavior\n- [ ] Argument — diagram SHOWS something text alone couldn't\n- [ ] Variety — each major concept uses a different visual pattern\n- [ ] No card grids or uniform containers\n\n**Container Discipline:**\n\n- [ ] \u003C30% of text elements inside containers\n- [ ] Lines as structure for tree\u002Ftimeline patterns\n- [ ] Typography hierarchy via font size and color\n\n**Technical:**\n\n- [ ] `text` contains only readable words\n- [ ] `fontFamily: 3`, `roughness: 0`, `opacity: 100`\n- [ ] Valid JSON (verify: `python3 -m json.tool \u003C file.excalidraw > \u002Fdev\u002Fnull`)\n\n**Visual Validation (render required):**\n\n- [ ] Rendered to PNG and visually inspected\n- [ ] No text overflow, no overlapping elements\n- [ ] Arrows land correctly, even spacing, balanced composition\n\n\u003C\u002Fsuccess_criteria>\n\n\u003Creference_guides>\n\n| File                              | When to Read                                       |\n| --------------------------------- | -------------------------------------------------- |\n| `references\u002Fcolor-palette.md`     | Before generating any diagram (colors and styles)  |\n| `references\u002Felement-templates.md` | When writing JSON (copy-paste element templates)   |\n| `references\u002Fjson-schema.md`       | When the complete element schema is needed         |\n| `references\u002Fvisual-patterns.md`   | During Step 2 (concept-to-pattern mapping)         |\n| `references\u002Flarge-diagrams.md`    | When building comprehensive\u002Fmulti-section diagrams |\n\n\u003C\u002Freference_guides>\n",{"name":5,"description":7},"main","978d51c51d68c99cffb2ba48f7cad9d2f07e5738","src\u002Fplugins\u002Fwork\u002Fskills\u002Fdraw-excalidraw","https:\u002F\u002Fgithub.com\u002Foutcomeeng\u002Fplugins","https:\u002F\u002Fgithub.com\u002Foutcomeeng","https:\u002F\u002Foutcome.engineering","Spec-driven development for AI-assisted engineering","2026-11-11 22:17:26",{"source":8,"skillName":5,"commands":45,"prompt":55,"zipAvailable":56},[46,49,52],{"tool":47,"command":48},"npx","npx skills add outcomeeng\u002Fplugins --skill draw-excalidraw",{"tool":50,"command":51},"bunx","bunx skills add outcomeeng\u002Fplugins --skill draw-excalidraw",{"tool":53,"command":54},"pnpm","pnpm dlx skills add outcomeeng\u002Fplugins --skill draw-excalidraw","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Foutcomeeng\u002Fplugins\u002Fblob\u002Fmain\u002Fsrc\u002Fplugins\u002Fwork\u002Fskills\u002Fdraw-excalidraw\u002FSKILL.md",true,[58,64,70,74,78,82,86,90,96,100],{"path":59,"resourceType":60,"resourceTypeDesc":61,"sizeBytes":62,"sourceHtmlUrl":63},".gitignore","OTHER","其他",34,"https:\u002F\u002Fgithub.com\u002Foutcomeeng\u002Fplugins\u002Fblob\u002Fmain\u002Fsrc\u002Fplugins\u002Fwork\u002Fskills\u002Fdraw-excalidraw\u002F.gitignore",{"path":65,"resourceType":66,"resourceTypeDesc":67,"sizeBytes":68,"sourceHtmlUrl":69},"README.md","REFERENCE","参考文档",2853,"https:\u002F\u002Fgithub.com\u002Foutcomeeng\u002Fplugins\u002Fblob\u002Fmain\u002Fsrc\u002Fplugins\u002Fwork\u002Fskills\u002Fdraw-excalidraw\u002FREADME.md",{"path":71,"resourceType":66,"resourceTypeDesc":67,"sizeBytes":72,"sourceHtmlUrl":73},"references\u002Fcolor-palette.md",2960,"https:\u002F\u002Fgithub.com\u002Foutcomeeng\u002Fplugins\u002Fblob\u002Fmain\u002Fsrc\u002Fplugins\u002Fwork\u002Fskills\u002Fdraw-excalidraw\u002Freferences\u002Fcolor-palette.md",{"path":75,"resourceType":66,"resourceTypeDesc":67,"sizeBytes":76,"sourceHtmlUrl":77},"references\u002Felement-templates.md",4130,"https:\u002F\u002Fgithub.com\u002Foutcomeeng\u002Fplugins\u002Fblob\u002Fmain\u002Fsrc\u002Fplugins\u002Fwork\u002Fskills\u002Fdraw-excalidraw\u002Freferences\u002Felement-templates.md",{"path":79,"resourceType":66,"resourceTypeDesc":67,"sizeBytes":80,"sourceHtmlUrl":81},"references\u002Fjson-schema.md",2724,"https:\u002F\u002Fgithub.com\u002Foutcomeeng\u002Fplugins\u002Fblob\u002Fmain\u002Fsrc\u002Fplugins\u002Fwork\u002Fskills\u002Fdraw-excalidraw\u002Freferences\u002Fjson-schema.md",{"path":83,"resourceType":66,"resourceTypeDesc":67,"sizeBytes":84,"sourceHtmlUrl":85},"references\u002Flarge-diagrams.md",3034,"https:\u002F\u002Fgithub.com\u002Foutcomeeng\u002Fplugins\u002Fblob\u002Fmain\u002Fsrc\u002Fplugins\u002Fwork\u002Fskills\u002Fdraw-excalidraw\u002Freferences\u002Flarge-diagrams.md",{"path":87,"resourceType":66,"resourceTypeDesc":67,"sizeBytes":88,"sourceHtmlUrl":89},"references\u002Fpyproject.toml",125,"https:\u002F\u002Fgithub.com\u002Foutcomeeng\u002Fplugins\u002Fblob\u002Fmain\u002Fsrc\u002Fplugins\u002Fwork\u002Fskills\u002Fdraw-excalidraw\u002Freferences\u002Fpyproject.toml",{"path":91,"resourceType":92,"resourceTypeDesc":93,"sizeBytes":94,"sourceHtmlUrl":95},"references\u002Frender_excalidraw.py","SCRIPT","脚本",6809,"https:\u002F\u002Fgithub.com\u002Foutcomeeng\u002Fplugins\u002Fblob\u002Fmain\u002Fsrc\u002Fplugins\u002Fwork\u002Fskills\u002Fdraw-excalidraw\u002Freferences\u002Frender_excalidraw.py",{"path":97,"resourceType":66,"resourceTypeDesc":67,"sizeBytes":98,"sourceHtmlUrl":99},"references\u002Frender_template.html",1764,"https:\u002F\u002Fgithub.com\u002Foutcomeeng\u002Fplugins\u002Fblob\u002Fmain\u002Fsrc\u002Fplugins\u002Fwork\u002Fskills\u002Fdraw-excalidraw\u002Freferences\u002Frender_template.html",{"path":101,"resourceType":66,"resourceTypeDesc":67,"sizeBytes":102,"sourceHtmlUrl":103},"references\u002Fvisual-patterns.md",4740,"https:\u002F\u002Fgithub.com\u002Foutcomeeng\u002Fplugins\u002Fblob\u002Fmain\u002Fsrc\u002Fplugins\u002Fwork\u002Fskills\u002Fdraw-excalidraw\u002Freferences\u002Fvisual-patterns.md",[105,111,145,162,175,189],{"skillNo":106,"name":107,"nameZh":6,"description":6,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":108,"categories":109,"keywords":110,"publishedAt":31},"01M71G25RZTPQG9KJ00JCHC1F7","plugin","https:\u002F\u002Fgithub.com\u002Foutcomeeng\u002Fplugins\u002Fblob\u002Fmain\u002Fsrc\u002Ftemplates\u002Fplugin\u002FSKILL.md",[],[107],{"skillNo":112,"name":113,"nameZh":6,"description":114,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":115,"categories":116,"keywords":127,"publishedAt":31},"01M71G23DCX3SV60H63HBBKQ6J","sanitize-powerpoint","ALWAYS invoke this skill when sanitizing, cleaning up, auditing, or aligning a PowerPoint (.pptx) deck — slide-master and layout structure, layout type attributes, stray fonts, non-theme colors, or layout naming. NEVER hand-edit pptx XML without this skill.","https:\u002F\u002Fgithub.com\u002Foutcomeeng\u002Fplugins\u002Fblob\u002Fmain\u002Fsrc\u002Fplugins\u002Fwork\u002Fskills\u002Fsanitize-powerpoint\u002FSKILL.md",[117,122],{"categoryNo":118,"categoryName":119,"taxonomyType":120,"taxonomyTypeDesc":121},"01JBSEEDCAT000000000000003","演示文稿","SCENARIO","使用场景",{"categoryNo":123,"categoryName":124,"taxonomyType":125,"taxonomyTypeDesc":126},"01JBSEEDCAT000000000000034","行政与办公人员","PROFESSION","适用职业",[128,129,130,131,132,133,134,24,135,136,137,138,139,140,141,142,143,144,25,28],"sanitize","powerpoint","sanitize powerpoint","fonts","type","cleaning","structure","attributes","theme","pptx","naming","layout","deck","up","edit","xml","master",{"skillNo":146,"name":147,"nameZh":6,"description":148,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":149,"categories":150,"keywords":154,"publishedAt":31},"01M71G1ZMNGFD37RZYM620XM2C","typescript-test-standards","TypeScript test standards enforced across all skills. Loaded by other skills, not invoked directly.","https:\u002F\u002Fgithub.com\u002Foutcomeeng\u002Fplugins\u002Fblob\u002Fmain\u002Fsrc\u002Fplugins\u002Ftypescript\u002Fskills\u002Ftypescript-test-standards\u002FSKILL.md",[151],{"categoryNo":152,"categoryName":153,"taxonomyType":120,"taxonomyTypeDesc":121},"01JBSEEDCAT000000000000008","测试与质量",[155,156,157,158,159,160,161],"standards","test","typescript test standards","typescript","false","read","across",{"skillNo":163,"name":164,"nameZh":6,"description":165,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":166,"categories":167,"keywords":171,"publishedAt":31},"01M71G1XBH0X1VCTR7269MDGSY","typescript-code-standards","TypeScript code standards enforced across all skills. Loaded by other skills, not invoked directly.","https:\u002F\u002Fgithub.com\u002Foutcomeeng\u002Fplugins\u002Fblob\u002Fmain\u002Fsrc\u002Fplugins\u002Ftypescript\u002Fskills\u002Ftypescript-code-standards\u002FSKILL.md",[168],{"categoryNo":169,"categoryName":170,"taxonomyType":125,"taxonomyTypeDesc":126},"01JBSEEDCAT000000000000030","开发工程师",[158,155,172,173,174,159,160,161],"typescript code standards","code","code standards",{"skillNo":176,"name":177,"nameZh":6,"description":178,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":179,"categories":180,"keywords":181,"publishedAt":31},"01M71G1TQ3VN45SJ75DFMJDB9W","typescript-architecture-standards","TypeScript ADR conventions enforced across architect and auditor skills. Loaded by other skills, not invoked directly.","https:\u002F\u002Fgithub.com\u002Foutcomeeng\u002Fplugins\u002Fblob\u002Fmain\u002Fsrc\u002Fplugins\u002Ftypescript\u002Fskills\u002Ftypescript-architecture-standards\u002FSKILL.md",[],[155,182,183,184,158,185,186,187,159,188,160,161],"architecture standards","typescript architecture standards","architecture","architect","adr","conventions","auditor",{"skillNo":190,"name":191,"nameZh":6,"description":192,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":193,"categories":194,"keywords":195,"publishedAt":31},"01M71G1RSFGDZR5XBXDX7E02B5","simplify-typescript-code","ALWAYS invoke this skill when simplifying TypeScript implementation while preserving behavior.","https:\u002F\u002Fgithub.com\u002Foutcomeeng\u002Fplugins\u002Fblob\u002Fmain\u002Fsrc\u002Fplugins\u002Ftypescript\u002Fskills\u002Fsimplify-typescript-code\u002FSKILL.md",[],[158,196,173,197,198,199,25,200,201,202,203,28,204,205,206,142,207,160,208,209],"simplify typescript code","simplify","diff","head","use","implementation","rev","base","status","git","grep","tool","behavior","parse"]