[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M69ACZ6XTYXY3RWNWN2EDW7P":3,"skill-same:01M69ACZ6XTYXY3RWNWN2EDW7P":94},{"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":23,"linkOnly":24,"markdownContent":25,"markdownBody":26,"frontMatter":27,"refName":28,"commitSha":29,"skillDirectory":30,"forksCount":31,"repositoryHtmlUrl":32,"repositoryHomepageUrl":33,"ownerHtmlUrl":34,"ownerBlogUrl":35,"ownerDescription":36,"updatedAt":37,"install":38,"resources":51},"01M69ACZ6XTYXY3RWNWN2EDW7P","excalidraw-diagram",null,"Create Excalidraw diagram JSON files that make visual arguments. Use when the user wants to visualize workflows, architectures, or concepts.","microsoft\u002Ffrontier-ai-governance-rvas","microsoft","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F6154722?v=4","01M698VYDXZ6JW5WH3CRV650R8","Microsoft","01M69AAY34KYZNT0DYKTD5AX5X",1,"MIT","https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Ffrontier-ai-governance-rvas\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Fexcalidraw-diagram\u002FSKILL.md",[],[19,20,21,22],"excalidraw diagram","diagram","visualize","workflows","2026-11-10 10:12:30",false,"---\nname: excalidraw-diagram\ndescription: Create Excalidraw diagram JSON files that make visual arguments. Use when the user wants to visualize workflows, architectures, or concepts.\n---\n\n# Excalidraw Diagram Creator\n\nGenerate `.excalidraw` JSON files that **argue visually**, not just display information.\n\n**Setup:** If the user asks you to set up this skill (renderer, dependencies, etc.), see `README.md` for instructions.\n\n## Customization\n\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\n---\n\n## Core Philosophy\n\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**: If you removed all text, 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\n---\n\n## Depth Assessment (Do This First)\n\nBefore designing, determine what level of detail this diagram needs:\n\n### Simple\u002FConceptual Diagrams\nUse abstract shapes when:\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\nUse concrete examples when:\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- You're showing how multiple technologies integrate\n\n**For technical diagrams, you MUST include evidence artifacts** (see below).\n\n---\n\n## Research Mandate (For Technical Diagrams)\n\n**Before drawing anything technical, research the actual specifications.**\n\nIf you're diagramming a protocol, API, or framework:\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\n---\n\n## Evidence Artifacts\n\nEvidence artifacts are concrete examples that prove your diagram is accurate and help viewers learn. Include them in technical diagrams.\n\n**Types of evidence artifacts** (choose what's relevant to your 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\n**Example**: For a diagram about a streaming protocol, you might show:\n- The actual event names from the spec (not just \"Event 1\", \"Event 2\")\n- A code snippet showing how to connect\n- What the streamed data actually looks like\n\n**Example**: For a diagram about a data transformation pipeline:\n- Show sample input data (actual format, not \"Input\")\n- Show sample output data (actual format, not \"Output\")\n- Show intermediate states if relevant\n\nThe key principle: **show what things actually look like**, not just what they're called.\n\n---\n\n## Multi-Zoom Architecture\n\nComprehensive diagrams operate at multiple zoom levels simultaneously. Think of it like a map that shows both the country borders AND the street names.\n\n### Level 1: Summary Flow\nA simplified overview showing the full pipeline or process at a glance. Often placed at the top or bottom of the diagram.\n\n*Example*: `Input → Processing → Output` or `Client → Server → Database`\n\n### Level 2: Section Boundaries\nLabeled regions that group related components. These create visual \"rooms\" that help viewers understand what belongs together.\n\n*Example*: Grouping by responsibility (Backend \u002F Frontend), by phase (Setup \u002F Execution \u002F Cleanup), or by team (User \u002F System \u002F External)\n\n### Level 3: Detail Inside Sections\nEvidence artifacts, code snippets, and concrete examples within each section. This is where the educational value lives.\n\n*Example*: Inside a \"Backend\" section, you might show the actual API response format, not just a box labeled \"API Response\"\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 vs Good\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### Simple vs Comprehensive (Know Which You Need)\n\n| Simple Diagram | Comprehensive Diagram |\n|----------------|----------------------|\n| Generic labels: \"Input\" → \"Process\" → \"Output\" | Specific: shows what the input\u002Foutput actually looks like |\n| Named boxes: \"API\", \"Database\", \"Client\" | Named boxes + examples of actual requests\u002Fresponses |\n| \"Events\" or \"Messages\" label | Timeline with real event\u002Fmessage names from the spec |\n| \"UI\" or \"Dashboard\" rectangle | Mockup showing actual UI elements and content |\n| ~30 seconds to explain | ~2-3 minutes of teaching content |\n| Viewer learns the structure | Viewer learns the structure AND the details |\n\n**Simple diagrams** are fine for abstract concepts, quick overviews, or when the audience already knows the details. **Comprehensive diagrams** are needed for technical architectures, tutorials, educational content, or when you want the diagram itself to teach.\n\n---\n\n## Container vs. Free-Floating Text\n\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\n---\n\n## Design Process (Do This BEFORE Generating JSON)\n\n### Step 0: Assess Depth Required\nBefore anything else, determine if this needs to be:\n- **Simple\u002FConceptual**: Abstract shapes, labels, relationships (mental models, philosophies)\n- **Comprehensive\u002FTechnical**: Concrete examples, code snippets, real data (systems, architectures, tutorials)\n\n**If comprehensive**: Do research first. Look up actual specs, formats, event names, APIs.\n\n### Step 1: Understand Deeply\nRead the content. For each concept, ask:\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?** (not just read about)\n\n### Step 2: Map Concepts to Patterns\nFor each concept, find the visual pattern that mirrors its behavior:\n\n| If the concept... | Use this pattern |\n|-------------------|------------------|\n| Spawns multiple outputs | **Fan-out** (radial arrows from center) |\n| Combines inputs into one | **Convergence** (funnel, arrows merging) |\n| Has hierarchy\u002Fnesting | **Tree** (lines + free-floating text) |\n| Is a sequence of steps | **Timeline** (line + dots + free-floating labels) |\n| Loops or improves continuously | **Spiral\u002FCycle** (arrow returning to start) |\n| Is an abstract state or context | **Cloud** (overlapping ellipses) |\n| Transforms input to output | **Assembly line** (before → process → after) |\n| Compares two things | **Side-by-side** (parallel with contrast) |\n| Separates into phases | **Gap\u002FBreak** (visual separation between sections) |\n\n### Step 3: Ensure Variety\nFor multi-concept diagrams: **each major concept must use a different visual pattern**. No uniform cards or grids.\n\n### Step 4: Sketch the Flow\nBefore JSON, mentally trace how the eye moves through the diagram. There should be a clear visual story.\n\n### Step 5: Generate JSON\nOnly now create the Excalidraw elements. **See below for how to handle large diagrams.**\n\n### Step 6: Render & Validate (MANDATORY)\nAfter generating the JSON, you MUST run the render-view-fix loop until the diagram looks right. This is not optional — see the **Render & Validate** section below for the full process.\n\n---\n\n## Large \u002F Comprehensive Diagram Strategy\n\n**For comprehensive or technical diagrams, you MUST build the JSON one section at a time.** Do NOT attempt to generate the entire file in a single pass. This is a hard constraint — Claude Code has a ~32,000 token output limit per response, and a comprehensive diagram easily exceeds that in one shot. Even if it didn't, generating everything at once leads to worse quality. Section-by-section is better in every way.\n\n### The Section-by-Section Workflow\n\n**Phase 1: Build each section**\n\n1. **Create the base file** with the JSON wrapper (`type`, `version`, `appState`, `files`) and the first section of elements.\n2. **Add one section per edit.** Each section gets its own dedicated pass — take your time with it. Think carefully about the layout, spacing, and how this section connects to what's already there.\n3. **Use descriptive string IDs** (e.g., `\"trigger_rect\"`, `\"arrow_fan_left\"`) so cross-section references are readable.\n4. **Namespace seeds by section** (e.g., section 1 uses 100xxx, section 2 uses 200xxx) to avoid collisions.\n5. **Update cross-section bindings** as you go. When a new section's element needs to bind to an element from a previous section (e.g., an arrow connecting sections), edit the earlier element's `boundElements` array at the same time.\n\n**Phase 2: Review the whole**\n\nAfter all sections are in place, read through the complete JSON and check:\n- Are cross-section arrows bound correctly on both ends?\n- Is the overall spacing balanced, or are some sections cramped while others have too much whitespace?\n- Do IDs and bindings all reference elements that actually exist?\n\nFix any alignment or binding issues before rendering.\n\n**Phase 3: Render & validate**\n\nNow run the render-view-fix loop from the Render & Validate section. This is where you'll catch visual issues that aren't obvious from JSON — overlaps, clipping, imbalanced composition.\n\n### Section Boundaries\n\nPlan your sections around natural visual groupings from the diagram plan. A typical large diagram might split into:\n\n- **Section 1**: Entry point \u002F trigger\n- **Section 2**: First decision or routing\n- **Section 3**: Main content (hero section — may be the largest single section)\n- **Section 4-N**: Remaining phases, outputs, etc.\n\nEach section should be independently understandable: its elements, internal arrows, and any cross-references to adjacent sections.\n\n### What NOT to Do\n\n- **Don't generate the entire diagram in one response.** You will hit the output token limit and produce truncated, broken JSON. Even if the diagram is small enough to fit, splitting into sections produces better results.\n- **Don't use a coding agent** to generate the JSON. The agent won't have sufficient context about the skill's rules, and the coordination overhead negates any benefit.\n- **Don't write a Python generator script.** The templating and coordinate math seem helpful but introduce a layer of indirection that makes debugging harder. Hand-crafted JSON with descriptive IDs is more maintainable.\n\n---\n\n## Visual Pattern Library\n\n### Fan-Out (One-to-Many)\nCentral element with arrows radiating to multiple targets. Use for: sources, PRDs, root causes, central hubs.\n```\n        ○\n       ↗\n  □ → ○\n       ↘\n        ○\n```\n\n### Convergence (Many-to-One)\nMultiple inputs merging through arrows to single output. Use for: aggregation, funnels, synthesis.\n```\n  ○ ↘\n  ○ → □\n  ○ ↗\n```\n\n### Tree (Hierarchy)\nParent-child branching with connecting lines and free-floating text (no boxes needed). Use for: file systems, org charts, taxonomies.\n```\n  label\n  ├── label\n  │   ├── label\n  │   └── label\n  └── label\n```\nUse `line` elements for the trunk and branches, free-floating text for labels.\n\n### Spiral\u002FCycle (Continuous Loop)\nElements in sequence with arrow returning to start. Use for: feedback loops, iterative processes, evolution.\n```\n  □ → □\n  ↑     ↓\n  □ ← □\n```\n\n### Cloud (Abstract State)\nOverlapping ellipses with varied sizes. Use for: context, memory, conversations, mental states.\n\n### Assembly Line (Transformation)\nInput → Process Box → Output with clear before\u002Fafter. Use for: transformations, processing, conversion.\n```\n  ○○○ → [PROCESS] → □□□\n  chaos              order\n```\n\n### Side-by-Side (Comparison)\nTwo parallel structures with visual contrast. Use for: before\u002Fafter, options, trade-offs.\n\n### Gap\u002FBreak (Separation)\nVisual whitespace or barrier between sections. Use for: phase changes, context resets, boundaries.\n\n### Lines as Structure\nUse lines (type: `line`, not arrows) as primary structural elements instead of boxes:\n- **Timelines**: Vertical or horizontal line with small dots (10-20px ellipses) at intervals, free-floating labels beside each dot\n- **Tree structures**: Vertical trunk line + horizontal branch lines, with free-floating text labels (no boxes needed)\n- **Dividers**: Thin dashed lines to separate sections\n- **Flow spines**: A central line that elements relate to, rather than connecting boxes\n\n```\nTimeline:           Tree:\n  ●─── Label 1        │\n  │                   ├── item\n  ●─── Label 2        │   ├── sub\n  │                   │   └── sub\n  ●─── Label 3        └── item\n```\n\nLines + free-floating text often creates a cleaner result than boxes + contained text.\n\n---\n\n## Shape Meaning\n\nChoose shape based on what it represents—or use no shape at all:\n\n| Concept Type | Shape | Why |\n|--------------|-------|-----|\n| Labels, descriptions, details | **none** (free-floating text) | Typography creates hierarchy |\n| Section titles, annotations | **none** (free-floating text) | Font size\u002Fweight is enough |\n| Markers on a timeline | small `ellipse` (10-20px) | Visual anchor, not container |\n| Start, trigger, input | `ellipse` | Soft, origin-like |\n| End, output, result | `ellipse` | Completion, destination |\n| Decision, condition | `diamond` | Classic decision symbol |\n| Process, action, step | `rectangle` | Contained action |\n| Abstract state, context | overlapping `ellipse` | Fuzzy, cloud-like |\n| Hierarchy node | lines + text (no boxes) | Structure through lines |\n\n**Rule**: Default to no container. Add shapes only when they carry meaning. Aim for \u003C30% of text elements to be inside containers.\n\n---\n\n## Color as Meaning\n\nColors encode information, not decoration. Every color choice should come from `references\u002Fcolor-palette.md` — the semantic shape colors, text hierarchy colors, and evidence artifact colors are all defined there.\n\n**Key principles:**\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\n---\n\n## Modern Aesthetics\n\nFor clean, professional diagrams:\n\n### Roughness\n- `roughness: 0` — Clean, crisp edges. Use for modern\u002Ftechnical diagrams.\n- `roughness: 1` — Hand-drawn, organic feel. Use for brainstorming\u002Finformal diagrams.\n\n**Default to 0** for most professional use cases.\n\n### Stroke Width\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 (main flow line, key connections).\n\n### Opacity\n**Always use `opacity: 100` for all elements.** Use color, size, and stroke width to create hierarchy instead of transparency.\n\n### Small Markers Instead of Shapes\nInstead of full shapes, use small dots (10-20px ellipses) as:\n- Timeline markers\n- Bullet points\n- Connection nodes\n- Visual anchors for free-floating text\n\n---\n\n## Layout Principles\n\n### Hierarchy Through Scale\n- **Hero**: 300×150 - visual anchor, most important\n- **Primary**: 180×90\n- **Secondary**: 120×60\n- **Small**: 60×40\n\n### Whitespace = Importance\nThe most important element has the most empty space around it (200px+).\n\n### Flow Direction\nGuide the eye: typically left→right or top→bottom for sequences, radial for hub-and-spoke.\n\n### Connections Required\nPosition alone doesn't show relationships. If A relates to B, there must be an arrow.\n\n---\n\n## Text Rules\n\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\n---\n\n## JSON 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\n## Element Templates\n\nSee `references\u002Felement-templates.md` for copy-paste JSON templates for each element type (text, line, dot, rectangle, arrow). Pull colors from `references\u002Fcolor-palette.md` based on each element's semantic purpose.\n\n---\n\n## Render & Validate (MANDATORY)\n\nYou cannot judge a diagram from JSON alone. After generating or editing the Excalidraw JSON, you MUST render it to PNG, view the image, and fix what you see — in a loop until it's right. This is a core part of the workflow, not a final check.\n\n### How to Render\n\n```bash\ncd .claude\u002Fskills\u002Fexcalidraw-diagram\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 actually view it.\n\n### The Loop\n\nAfter generating the initial JSON, run this cycle:\n\n**1. Render & View** — Run the render script, then Read the PNG.\n\n**2. Audit against your original vision** — Before looking for bugs, compare the rendered result to what you designed in Steps 1-4. Ask:\n- Does the visual structure match the conceptual structure you planned?\n- Does each section use the pattern you intended (fan-out, convergence, timeline, etc.)?\n- Does the eye flow through the diagram in the order you designed?\n- Is the visual hierarchy correct — hero elements dominant, supporting elements smaller?\n- For technical diagrams: are the evidence artifacts (code snippets, data examples) readable and properly placed?\n\n**3. 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 (not clearly anchored to what they describe)\n- Uneven spacing between elements that should be evenly spaced\n- Sections with too much whitespace next to sections that are too cramped\n- Text too small to read at the rendered size\n- Overall composition feels lopsided or unbalanced\n\n**4. Fix** — Edit the JSON to address everything you found. Common fixes:\n- Widen containers when text is clipped\n- Adjust `x`\u002F`y` coordinates to fix spacing and alignment\n- Add intermediate waypoints to arrow `points` arrays to route around elements\n- Reposition labels closer to the element they describe\n- Resize elements to rebalance visual weight across sections\n\n**5. Re-render & re-view** — Run the render script again and Read the new PNG.\n\n**6. Repeat** — Keep cycling until the diagram passes both the vision check (Step 2) and the defect check (Step 3). Typically takes 2-4 iterations. Don't stop after one pass just because there are no critical bugs — if the composition could be better, improve it.\n\n### When to Stop\n\nThe loop is done when:\n- The rendered diagram matches the conceptual design from your planning steps\n- No text is clipped, overlapping, or unreadable\n- Arrows route cleanly and connect to the right elements\n- Spacing is consistent and the composition is balanced\n- You'd be comfortable showing it to someone without caveats\n\n### First-Time Setup\nIf the render script hasn't been set up yet:\n```bash\ncd .claude\u002Fskills\u002Fexcalidraw-diagram\u002Freferences\nuv sync\nuv run playwright install chromium\n```\n\n---\n\n## Quality Checklist\n\n### Depth & Evidence (Check First for Technical Diagrams)\n1. **Research done**: Did you look up actual specs, formats, event names?\n2. **Evidence artifacts**: Are there code snippets, JSON examples, or real data?\n3. **Multi-zoom**: Does it have summary flow + section boundaries + detail?\n4. **Concrete over abstract**: Real content shown, not just labeled boxes?\n5. **Educational value**: Could someone learn something concrete from this?\n\n### Conceptual\n6. **Isomorphism**: Does each visual structure mirror its concept's behavior?\n7. **Argument**: Does the diagram SHOW something text alone couldn't?\n8. **Variety**: Does each major concept use a different visual pattern?\n9. **No uniform containers**: Avoided card grids and equal boxes?\n\n### Container Discipline\n10. **Minimal containers**: Could any boxed element work as free-floating text instead?\n11. **Lines as structure**: Are tree\u002Ftimeline patterns using lines + text rather than boxes?\n12. **Typography hierarchy**: Are font size and color creating visual hierarchy (reducing need for boxes)?\n\n### Structural\n13. **Connections**: Every relationship has an arrow or line\n14. **Flow**: Clear visual path for the eye to follow\n15. **Hierarchy**: Important elements are larger\u002Fmore isolated\n\n### Technical\n16. **Text clean**: `text` contains only readable words\n17. **Font**: `fontFamily: 3`\n18. **Roughness**: `roughness: 0` for clean\u002Fmodern (unless hand-drawn style requested)\n19. **Opacity**: `opacity: 100` for all elements (no transparency)\n20. **Container ratio**: \u003C30% of text elements should be inside containers\n\n### Visual Validation (Render Required)\n21. **Rendered to PNG**: Diagram has been rendered and visually inspected\n22. **No text overflow**: All text fits within its container\n23. **No overlapping elements**: Shapes and text don't overlap unintentionally\n24. **Even spacing**: Similar elements have consistent spacing\n25. **Arrows land correctly**: Arrows connect to intended elements without crossing others\n26. **Readable at export size**: Text is legible in the rendered PNG\n27. **Balanced composition**: No large empty voids or overcrowded regions\n","# Excalidraw Diagram Creator\n\nGenerate `.excalidraw` JSON files that **argue visually**, not just display information.\n\n**Setup:** If the user asks you to set up this skill (renderer, dependencies, etc.), see `README.md` for instructions.\n\n## Customization\n\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\n---\n\n## Core Philosophy\n\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**: If you removed all text, 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\n---\n\n## Depth Assessment (Do This First)\n\nBefore designing, determine what level of detail this diagram needs:\n\n### Simple\u002FConceptual Diagrams\nUse abstract shapes when:\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\nUse concrete examples when:\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- You're showing how multiple technologies integrate\n\n**For technical diagrams, you MUST include evidence artifacts** (see below).\n\n---\n\n## Research Mandate (For Technical Diagrams)\n\n**Before drawing anything technical, research the actual specifications.**\n\nIf you're diagramming a protocol, API, or framework:\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\n---\n\n## Evidence Artifacts\n\nEvidence artifacts are concrete examples that prove your diagram is accurate and help viewers learn. Include them in technical diagrams.\n\n**Types of evidence artifacts** (choose what's relevant to your 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\n**Example**: For a diagram about a streaming protocol, you might show:\n- The actual event names from the spec (not just \"Event 1\", \"Event 2\")\n- A code snippet showing how to connect\n- What the streamed data actually looks like\n\n**Example**: For a diagram about a data transformation pipeline:\n- Show sample input data (actual format, not \"Input\")\n- Show sample output data (actual format, not \"Output\")\n- Show intermediate states if relevant\n\nThe key principle: **show what things actually look like**, not just what they're called.\n\n---\n\n## Multi-Zoom Architecture\n\nComprehensive diagrams operate at multiple zoom levels simultaneously. Think of it like a map that shows both the country borders AND the street names.\n\n### Level 1: Summary Flow\nA simplified overview showing the full pipeline or process at a glance. Often placed at the top or bottom of the diagram.\n\n*Example*: `Input → Processing → Output` or `Client → Server → Database`\n\n### Level 2: Section Boundaries\nLabeled regions that group related components. These create visual \"rooms\" that help viewers understand what belongs together.\n\n*Example*: Grouping by responsibility (Backend \u002F Frontend), by phase (Setup \u002F Execution \u002F Cleanup), or by team (User \u002F System \u002F External)\n\n### Level 3: Detail Inside Sections\nEvidence artifacts, code snippets, and concrete examples within each section. This is where the educational value lives.\n\n*Example*: Inside a \"Backend\" section, you might show the actual API response format, not just a box labeled \"API Response\"\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 vs Good\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### Simple vs Comprehensive (Know Which You Need)\n\n| Simple Diagram | Comprehensive Diagram |\n|----------------|----------------------|\n| Generic labels: \"Input\" → \"Process\" → \"Output\" | Specific: shows what the input\u002Foutput actually looks like |\n| Named boxes: \"API\", \"Database\", \"Client\" | Named boxes + examples of actual requests\u002Fresponses |\n| \"Events\" or \"Messages\" label | Timeline with real event\u002Fmessage names from the spec |\n| \"UI\" or \"Dashboard\" rectangle | Mockup showing actual UI elements and content |\n| ~30 seconds to explain | ~2-3 minutes of teaching content |\n| Viewer learns the structure | Viewer learns the structure AND the details |\n\n**Simple diagrams** are fine for abstract concepts, quick overviews, or when the audience already knows the details. **Comprehensive diagrams** are needed for technical architectures, tutorials, educational content, or when you want the diagram itself to teach.\n\n---\n\n## Container vs. Free-Floating Text\n\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\n---\n\n## Design Process (Do This BEFORE Generating JSON)\n\n### Step 0: Assess Depth Required\nBefore anything else, determine if this needs to be:\n- **Simple\u002FConceptual**: Abstract shapes, labels, relationships (mental models, philosophies)\n- **Comprehensive\u002FTechnical**: Concrete examples, code snippets, real data (systems, architectures, tutorials)\n\n**If comprehensive**: Do research first. Look up actual specs, formats, event names, APIs.\n\n### Step 1: Understand Deeply\nRead the content. For each concept, ask:\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?** (not just read about)\n\n### Step 2: Map Concepts to Patterns\nFor each concept, find the visual pattern that mirrors its behavior:\n\n| If the concept... | Use this pattern |\n|-------------------|------------------|\n| Spawns multiple outputs | **Fan-out** (radial arrows from center) |\n| Combines inputs into one | **Convergence** (funnel, arrows merging) |\n| Has hierarchy\u002Fnesting | **Tree** (lines + free-floating text) |\n| Is a sequence of steps | **Timeline** (line + dots + free-floating labels) |\n| Loops or improves continuously | **Spiral\u002FCycle** (arrow returning to start) |\n| Is an abstract state or context | **Cloud** (overlapping ellipses) |\n| Transforms input to output | **Assembly line** (before → process → after) |\n| Compares two things | **Side-by-side** (parallel with contrast) |\n| Separates into phases | **Gap\u002FBreak** (visual separation between sections) |\n\n### Step 3: Ensure Variety\nFor multi-concept diagrams: **each major concept must use a different visual pattern**. No uniform cards or grids.\n\n### Step 4: Sketch the Flow\nBefore JSON, mentally trace how the eye moves through the diagram. There should be a clear visual story.\n\n### Step 5: Generate JSON\nOnly now create the Excalidraw elements. **See below for how to handle large diagrams.**\n\n### Step 6: Render & Validate (MANDATORY)\nAfter generating the JSON, you MUST run the render-view-fix loop until the diagram looks right. This is not optional — see the **Render & Validate** section below for the full process.\n\n---\n\n## Large \u002F Comprehensive Diagram Strategy\n\n**For comprehensive or technical diagrams, you MUST build the JSON one section at a time.** Do NOT attempt to generate the entire file in a single pass. This is a hard constraint — Claude Code has a ~32,000 token output limit per response, and a comprehensive diagram easily exceeds that in one shot. Even if it didn't, generating everything at once leads to worse quality. Section-by-section is better in every way.\n\n### The Section-by-Section Workflow\n\n**Phase 1: Build each section**\n\n1. **Create the base file** with the JSON wrapper (`type`, `version`, `appState`, `files`) and the first section of elements.\n2. **Add one section per edit.** Each section gets its own dedicated pass — take your time with it. Think carefully about the layout, spacing, and how this section connects to what's already there.\n3. **Use descriptive string IDs** (e.g., `\"trigger_rect\"`, `\"arrow_fan_left\"`) so cross-section references are readable.\n4. **Namespace seeds by section** (e.g., section 1 uses 100xxx, section 2 uses 200xxx) to avoid collisions.\n5. **Update cross-section bindings** as you go. When a new section's element needs to bind to an element from a previous section (e.g., an arrow connecting sections), edit the earlier element's `boundElements` array at the same time.\n\n**Phase 2: Review the whole**\n\nAfter all sections are in place, read through the complete JSON and check:\n- Are cross-section arrows bound correctly on both ends?\n- Is the overall spacing balanced, or are some sections cramped while others have too much whitespace?\n- Do IDs and bindings all reference elements that actually exist?\n\nFix any alignment or binding issues before rendering.\n\n**Phase 3: Render & validate**\n\nNow run the render-view-fix loop from the Render & Validate section. This is where you'll catch visual issues that aren't obvious from JSON — overlaps, clipping, imbalanced composition.\n\n### Section Boundaries\n\nPlan your sections around natural visual groupings from the diagram plan. A typical large diagram might split into:\n\n- **Section 1**: Entry point \u002F trigger\n- **Section 2**: First decision or routing\n- **Section 3**: Main content (hero section — may be the largest single section)\n- **Section 4-N**: Remaining phases, outputs, etc.\n\nEach section should be independently understandable: its elements, internal arrows, and any cross-references to adjacent sections.\n\n### What NOT to Do\n\n- **Don't generate the entire diagram in one response.** You will hit the output token limit and produce truncated, broken JSON. Even if the diagram is small enough to fit, splitting into sections produces better results.\n- **Don't use a coding agent** to generate the JSON. The agent won't have sufficient context about the skill's rules, and the coordination overhead negates any benefit.\n- **Don't write a Python generator script.** The templating and coordinate math seem helpful but introduce a layer of indirection that makes debugging harder. Hand-crafted JSON with descriptive IDs is more maintainable.\n\n---\n\n## Visual Pattern Library\n\n### Fan-Out (One-to-Many)\nCentral element with arrows radiating to multiple targets. Use for: sources, PRDs, root causes, central hubs.\n```\n        ○\n       ↗\n  □ → ○\n       ↘\n        ○\n```\n\n### Convergence (Many-to-One)\nMultiple inputs merging through arrows to single output. Use for: aggregation, funnels, synthesis.\n```\n  ○ ↘\n  ○ → □\n  ○ ↗\n```\n\n### Tree (Hierarchy)\nParent-child branching with connecting lines and free-floating text (no boxes needed). Use for: file systems, org charts, taxonomies.\n```\n  label\n  ├── label\n  │   ├── label\n  │   └── label\n  └── label\n```\nUse `line` elements for the trunk and branches, free-floating text for labels.\n\n### Spiral\u002FCycle (Continuous Loop)\nElements in sequence with arrow returning to start. Use for: feedback loops, iterative processes, evolution.\n```\n  □ → □\n  ↑     ↓\n  □ ← □\n```\n\n### Cloud (Abstract State)\nOverlapping ellipses with varied sizes. Use for: context, memory, conversations, mental states.\n\n### Assembly Line (Transformation)\nInput → Process Box → Output with clear before\u002Fafter. Use for: transformations, processing, conversion.\n```\n  ○○○ → [PROCESS] → □□□\n  chaos              order\n```\n\n### Side-by-Side (Comparison)\nTwo parallel structures with visual contrast. Use for: before\u002Fafter, options, trade-offs.\n\n### Gap\u002FBreak (Separation)\nVisual whitespace or barrier between sections. Use for: phase changes, context resets, boundaries.\n\n### Lines as Structure\nUse lines (type: `line`, not arrows) as primary structural elements instead of boxes:\n- **Timelines**: Vertical or horizontal line with small dots (10-20px ellipses) at intervals, free-floating labels beside each dot\n- **Tree structures**: Vertical trunk line + horizontal branch lines, with free-floating text labels (no boxes needed)\n- **Dividers**: Thin dashed lines to separate sections\n- **Flow spines**: A central line that elements relate to, rather than connecting boxes\n\n```\nTimeline:           Tree:\n  ●─── Label 1        │\n  │                   ├── item\n  ●─── Label 2        │   ├── sub\n  │                   │   └── sub\n  ●─── Label 3        └── item\n```\n\nLines + free-floating text often creates a cleaner result than boxes + contained text.\n\n---\n\n## Shape Meaning\n\nChoose shape based on what it represents—or use no shape at all:\n\n| Concept Type | Shape | Why |\n|--------------|-------|-----|\n| Labels, descriptions, details | **none** (free-floating text) | Typography creates hierarchy |\n| Section titles, annotations | **none** (free-floating text) | Font size\u002Fweight is enough |\n| Markers on a timeline | small `ellipse` (10-20px) | Visual anchor, not container |\n| Start, trigger, input | `ellipse` | Soft, origin-like |\n| End, output, result | `ellipse` | Completion, destination |\n| Decision, condition | `diamond` | Classic decision symbol |\n| Process, action, step | `rectangle` | Contained action |\n| Abstract state, context | overlapping `ellipse` | Fuzzy, cloud-like |\n| Hierarchy node | lines + text (no boxes) | Structure through lines |\n\n**Rule**: Default to no container. Add shapes only when they carry meaning. Aim for \u003C30% of text elements to be inside containers.\n\n---\n\n## Color as Meaning\n\nColors encode information, not decoration. Every color choice should come from `references\u002Fcolor-palette.md` — the semantic shape colors, text hierarchy colors, and evidence artifact colors are all defined there.\n\n**Key principles:**\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\n---\n\n## Modern Aesthetics\n\nFor clean, professional diagrams:\n\n### Roughness\n- `roughness: 0` — Clean, crisp edges. Use for modern\u002Ftechnical diagrams.\n- `roughness: 1` — Hand-drawn, organic feel. Use for brainstorming\u002Finformal diagrams.\n\n**Default to 0** for most professional use cases.\n\n### Stroke Width\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 (main flow line, key connections).\n\n### Opacity\n**Always use `opacity: 100` for all elements.** Use color, size, and stroke width to create hierarchy instead of transparency.\n\n### Small Markers Instead of Shapes\nInstead of full shapes, use small dots (10-20px ellipses) as:\n- Timeline markers\n- Bullet points\n- Connection nodes\n- Visual anchors for free-floating text\n\n---\n\n## Layout Principles\n\n### Hierarchy Through Scale\n- **Hero**: 300×150 - visual anchor, most important\n- **Primary**: 180×90\n- **Secondary**: 120×60\n- **Small**: 60×40\n\n### Whitespace = Importance\nThe most important element has the most empty space around it (200px+).\n\n### Flow Direction\nGuide the eye: typically left→right or top→bottom for sequences, radial for hub-and-spoke.\n\n### Connections Required\nPosition alone doesn't show relationships. If A relates to B, there must be an arrow.\n\n---\n\n## Text Rules\n\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\n---\n\n## JSON 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\n## Element Templates\n\nSee `references\u002Felement-templates.md` for copy-paste JSON templates for each element type (text, line, dot, rectangle, arrow). Pull colors from `references\u002Fcolor-palette.md` based on each element's semantic purpose.\n\n---\n\n## Render & Validate (MANDATORY)\n\nYou cannot judge a diagram from JSON alone. After generating or editing the Excalidraw JSON, you MUST render it to PNG, view the image, and fix what you see — in a loop until it's right. This is a core part of the workflow, not a final check.\n\n### How to Render\n\n```bash\ncd .claude\u002Fskills\u002Fexcalidraw-diagram\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 actually view it.\n\n### The Loop\n\nAfter generating the initial JSON, run this cycle:\n\n**1. Render & View** — Run the render script, then Read the PNG.\n\n**2. Audit against your original vision** — Before looking for bugs, compare the rendered result to what you designed in Steps 1-4. Ask:\n- Does the visual structure match the conceptual structure you planned?\n- Does each section use the pattern you intended (fan-out, convergence, timeline, etc.)?\n- Does the eye flow through the diagram in the order you designed?\n- Is the visual hierarchy correct — hero elements dominant, supporting elements smaller?\n- For technical diagrams: are the evidence artifacts (code snippets, data examples) readable and properly placed?\n\n**3. 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 (not clearly anchored to what they describe)\n- Uneven spacing between elements that should be evenly spaced\n- Sections with too much whitespace next to sections that are too cramped\n- Text too small to read at the rendered size\n- Overall composition feels lopsided or unbalanced\n\n**4. Fix** — Edit the JSON to address everything you found. Common fixes:\n- Widen containers when text is clipped\n- Adjust `x`\u002F`y` coordinates to fix spacing and alignment\n- Add intermediate waypoints to arrow `points` arrays to route around elements\n- Reposition labels closer to the element they describe\n- Resize elements to rebalance visual weight across sections\n\n**5. Re-render & re-view** — Run the render script again and Read the new PNG.\n\n**6. Repeat** — Keep cycling until the diagram passes both the vision check (Step 2) and the defect check (Step 3). Typically takes 2-4 iterations. Don't stop after one pass just because there are no critical bugs — if the composition could be better, improve it.\n\n### When to Stop\n\nThe loop is done when:\n- The rendered diagram matches the conceptual design from your planning steps\n- No text is clipped, overlapping, or unreadable\n- Arrows route cleanly and connect to the right elements\n- Spacing is consistent and the composition is balanced\n- You'd be comfortable showing it to someone without caveats\n\n### First-Time Setup\nIf the render script hasn't been set up yet:\n```bash\ncd .claude\u002Fskills\u002Fexcalidraw-diagram\u002Freferences\nuv sync\nuv run playwright install chromium\n```\n\n---\n\n## Quality Checklist\n\n### Depth & Evidence (Check First for Technical Diagrams)\n1. **Research done**: Did you look up actual specs, formats, event names?\n2. **Evidence artifacts**: Are there code snippets, JSON examples, or real data?\n3. **Multi-zoom**: Does it have summary flow + section boundaries + detail?\n4. **Concrete over abstract**: Real content shown, not just labeled boxes?\n5. **Educational value**: Could someone learn something concrete from this?\n\n### Conceptual\n6. **Isomorphism**: Does each visual structure mirror its concept's behavior?\n7. **Argument**: Does the diagram SHOW something text alone couldn't?\n8. **Variety**: Does each major concept use a different visual pattern?\n9. **No uniform containers**: Avoided card grids and equal boxes?\n\n### Container Discipline\n10. **Minimal containers**: Could any boxed element work as free-floating text instead?\n11. **Lines as structure**: Are tree\u002Ftimeline patterns using lines + text rather than boxes?\n12. **Typography hierarchy**: Are font size and color creating visual hierarchy (reducing need for boxes)?\n\n### Structural\n13. **Connections**: Every relationship has an arrow or line\n14. **Flow**: Clear visual path for the eye to follow\n15. **Hierarchy**: Important elements are larger\u002Fmore isolated\n\n### Technical\n16. **Text clean**: `text` contains only readable words\n17. **Font**: `fontFamily: 3`\n18. **Roughness**: `roughness: 0` for clean\u002Fmodern (unless hand-drawn style requested)\n19. **Opacity**: `opacity: 100` for all elements (no transparency)\n20. **Container ratio**: \u003C30% of text elements should be inside containers\n\n### Visual Validation (Render Required)\n21. **Rendered to PNG**: Diagram has been rendered and visually inspected\n22. **No text overflow**: All text fits within its container\n23. **No overlapping elements**: Shapes and text don't overlap unintentionally\n24. **Even spacing**: Similar elements have consistent spacing\n25. **Arrows land correctly**: Arrows connect to intended elements without crossing others\n26. **Readable at export size**: Text is legible in the rendered PNG\n27. **Balanced composition**: No large empty voids or overcrowded regions\n",{"name":5,"description":7},"main","653b12ebe42d8d4fb0ce41896196cb51189927a9",".agents\u002Fskills\u002Fexcalidraw-diagram",0,"https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Ffrontier-ai-governance-rvas","https:\u002F\u002Fmicrosoft.github.io\u002Ffrontier-ai-governance-rvas","https:\u002F\u002Fgithub.com\u002Fmicrosoft","https:\u002F\u002Fopensource.microsoft.com","Open source projects and samples from Microsoft","2026-10-27 01:11:46",{"source":8,"skillName":5,"commands":39,"prompt":49,"zipAvailable":50},[40,43,46],{"tool":41,"command":42},"npx","npx skills add microsoft\u002Ffrontier-ai-governance-rvas --skill excalidraw-diagram",{"tool":44,"command":45},"bunx","bunx skills add microsoft\u002Ffrontier-ai-governance-rvas --skill excalidraw-diagram",{"tool":47,"command":48},"pnpm","pnpm dlx skills add microsoft\u002Ffrontier-ai-governance-rvas --skill excalidraw-diagram","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Ffrontier-ai-governance-rvas\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Fexcalidraw-diagram\u002FSKILL.md",true,[52,58,64,68,72,76,80,84,90],{"path":53,"resourceType":54,"resourceTypeDesc":55,"sizeBytes":56,"sourceHtmlUrl":57},".gitignore","OTHER","其他",34,"https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Ffrontier-ai-governance-rvas\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Fexcalidraw-diagram\u002F.gitignore",{"path":59,"resourceType":60,"resourceTypeDesc":61,"sizeBytes":62,"sourceHtmlUrl":63},"README.md","REFERENCE","参考文档",2872,"https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Ffrontier-ai-governance-rvas\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Fexcalidraw-diagram\u002FREADME.md",{"path":65,"resourceType":60,"resourceTypeDesc":61,"sizeBytes":66,"sourceHtmlUrl":67},"references\u002Fattribution.md",1921,"https:\u002F\u002Fgithub.com\u002Fgoogle\u002Fskills\u002Fblob\u002Fmain\u002Fskills\u002Fcloud\u002Fgke-storage-troubleshooting\u002Freferences\u002Fattribution.md",{"path":69,"resourceType":60,"resourceTypeDesc":61,"sizeBytes":70,"sourceHtmlUrl":71},"references\u002Fcolor-palette.md",2116,"https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Ffrontier-ai-governance-rvas\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Fexcalidraw-diagram\u002Freferences\u002Fcolor-palette.md",{"path":73,"resourceType":60,"resourceTypeDesc":61,"sizeBytes":74,"sourceHtmlUrl":75},"references\u002Felement-templates.md",4088,"https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Ffrontier-ai-governance-rvas\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Fexcalidraw-diagram\u002Freferences\u002Felement-templates.md",{"path":77,"resourceType":60,"resourceTypeDesc":61,"sizeBytes":78,"sourceHtmlUrl":79},"references\u002Fjson-schema.md",1958,"https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Ffrontier-ai-governance-rvas\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Fexcalidraw-diagram\u002Freferences\u002Fjson-schema.md",{"path":81,"resourceType":60,"resourceTypeDesc":61,"sizeBytes":82,"sourceHtmlUrl":83},"references\u002Fpyproject.toml",127,"https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Ffrontier-ai-governance-rvas\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Fexcalidraw-diagram\u002Freferences\u002Fpyproject.toml",{"path":85,"resourceType":86,"resourceTypeDesc":87,"sizeBytes":88,"sourceHtmlUrl":89},"references\u002Frender_excalidraw.py","SCRIPT","脚本",6630,"https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Ffrontier-ai-governance-rvas\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Fexcalidraw-diagram\u002Freferences\u002Frender_excalidraw.py",{"path":91,"resourceType":60,"resourceTypeDesc":61,"sizeBytes":92,"sourceHtmlUrl":93},"references\u002Frender_template.html",1686,"https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Ffrontier-ai-governance-rvas\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Fexcalidraw-diagram\u002Freferences\u002Frender_template.html",[95,111,126,133,139,151],{"skillNo":96,"name":97,"nameZh":6,"description":98,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":99,"categories":100,"keywords":106,"publishedAt":23},"01M69AEY2SZBH07YRH81HNQQ8Y","skill-creator","Create new skills, modify and improve existing skills, and measure skill performance. Use when users want to create a skill from scratch, edit, or optimize an existing skill, run evals to test a skill, benchmark skill performance with variance analysis, or optimize a skill's description for better triggering accuracy.","https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Ffrontier-ai-governance-rvas\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Fskill-creator\u002FSKILL.md",[101],{"categoryNo":102,"categoryName":103,"taxonomyType":104,"taxonomyTypeDesc":105},"01JBSEEDCAT000000000000023","Skill与智能体开发","SCENARIO","使用场景",[107,108,109,110],"skill creator","performance","run evals","test",{"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":120,"publishedAt":23},"01M69AEHQ7SGDKMGZAJGGPYBXX","preset","Intelligently deploys Azure OpenAI models to optimal regions by analyzing capacity across all available regions. Automatically checks current region first and shows alternatives if needed. USE FOR: quick deployment, optimal region, best region, automatic region selection, fast setup, multi-region capacity check, high availability deployment, deploy to best location. DO NOT USE FOR: custom SKU selection (use customize), specific version selection (use customize), custom capacity configuration (use customize), PTU deployments (use customize).","https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Ffrontier-ai-governance-rvas\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Fmicrosoft-foundry\u002Fmodels\u002Fdeploy-model\u002Fpreset\u002FSKILL.md",[117],{"categoryNo":118,"categoryName":119,"taxonomyType":104,"taxonomyTypeDesc":105},"01JBSEEDCAT000000000000011","运维与部署",[113,9,121,122,123,124,125],"deploy","capacity","customize","setup","capacity check",{"skillNo":127,"name":123,"nameZh":6,"description":128,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":129,"categories":130,"keywords":131,"publishedAt":23},"01M69AEF2CB2J9N0F09H5PKDTP","Interactive guided deployment flow for Azure OpenAI models with full customization control. Step-by-step selection of model version, SKU (GlobalStandard\u002FStandard\u002FProvisionedManaged), capacity, RAI policy (content filter), and advanced options (dynamic quota, priority processing, spillover). USE FOR: custom deployment, customize model deployment, choose version, select SKU, set capacity, configure content filter, RAI policy, deployment options, detailed deployment, advanced deployment, PTU deployment, provisioned throughput. DO NOT USE FOR: quick deployment to optimal region (use preset).","https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Ffrontier-ai-governance-rvas\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Fmicrosoft-foundry\u002Fmodels\u002Fdeploy-model\u002Fcustomize\u002FSKILL.md",[],[123,9,122,113,132],"policy",{"skillNo":134,"name":122,"nameZh":6,"description":135,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":136,"categories":137,"keywords":138,"publishedAt":23},"01M69AECG84DC1D9CW263ZP6JC","Discovers available Azure OpenAI model capacity across regions and projects. Analyzes quota limits, compares availability, and recommends optimal deployment locations based on capacity requirements. USE FOR: find capacity, check quota, where can I deploy, capacity discovery, best region for capacity, multi-project capacity search, quota analysis, model availability, region comparison, check TPM availability. DO NOT USE FOR: actual deployment (hand off to preset or customize after discovery), quota increase requests (direct user to Azure Portal), listing existing deployments.","https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Ffrontier-ai-governance-rvas\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Fmicrosoft-foundry\u002Fmodels\u002Fdeploy-model\u002Fcapacity\u002FSKILL.md",[],[122,123,113,121,9],{"skillNo":140,"name":141,"nameZh":6,"description":142,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":143,"categories":144,"keywords":147,"publishedAt":23},"01M69AE9TETM0YV9PADJTF9YZ6","deploy-model","Unified Azure OpenAI model deployment skill with intelligent intent-based routing. Handles quick preset deployments, fully customized deployments (version\u002FSKU\u002Fcapacity\u002FRAI policy), and capacity discovery across regions and projects. USE FOR: deploy model, deploy gpt, create deployment, model deployment, deploy openai model, set up model, provision model, find capacity, check model availability, where can I deploy, best region for model, capacity analysis. DO NOT USE FOR: listing existing deployments (use foundry_models_deployments_list MCP tool), deleting deployments, agent creation (use agent\u002Fcreate), project creation (use project\u002Fcreate).","https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Ffrontier-ai-governance-rvas\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Fmicrosoft-foundry\u002Fmodels\u002Fdeploy-model\u002FSKILL.md",[145,146],{"categoryNo":118,"categoryName":119,"taxonomyType":104,"taxonomyTypeDesc":105},{"categoryNo":102,"categoryName":103,"taxonomyType":104,"taxonomyTypeDesc":105},[121,148,113,122,149,9,132,150],"deploy model","foundry","MCP",{"skillNo":152,"name":153,"nameZh":6,"description":154,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":155,"categories":156,"keywords":158,"publishedAt":23},"01M69AE4M3X9ZQJ8FT0CD0MCAK","finetuning","Fine-tune models on Microsoft Foundry using SFT (supervised), DPO (preference), or RFT (reinforcement with graders). Covers dataset preparation, training job submission, deployment, and evaluation. USE FOR: fine-tune, SFT, DPO, RFT, training data, grader, distillation, fine-tuned model, training job, large file upload, calibrate grader, deploy fine-tuned model, evaluate fine-tuned model. DO NOT USE FOR: general model deployment without fine-tuning (use deploy-model), agent creation (use agents), prompt optimization without training (use prompt-optimizer).","https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Ffrontier-ai-governance-rvas\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Fmicrosoft-foundry\u002Ffinetuning\u002FSKILL.md",[157],{"categoryNo":102,"categoryName":103,"taxonomyType":104,"taxonomyTypeDesc":105},[153,9,121,159,160,149],"placeholder","microsoft foundry"]