Help us improve
Share bugs, ideas, or general feedback.
From html-skills
Create SVG-based technical diagrams inside HTML — flowcharts, sequence diagrams, state machines, data-flow diagrams, dependency graphs, request/response timelines. Use whenever the user wants to visualize, illustrate, diagram, or sketch a technical concept, system, or process. Strongly prefer SVG over ASCII art, mermaid blocks, or markdown text for anything spatial or relational. Reach for this whenever an explanation involves arrows, boxes, layers, or sequencing — even when the user doesn't say "diagram".
npx claudepluginhub f-labs-io/agent-html-skills --plugin html-skillsHow this skill is triggered — by the user, by Claude, or both
Slash command
/html-skills:html-svg-diagramsThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
ASCII diagrams in markdown are a workaround for not having SVG. With SVG inside HTML, you get real shapes, real arrows, real typography, and real positioning — for the same conceptual cost.
Create HTML system architecture diagrams — microservice maps, dependency graphs, deployment topologies, data ownership maps, integration diagrams. Useful during incidents, design reviews, onboarding, and capacity planning. Use whenever the user wants to visualize, document, or explain how a system fits together — across services, regions, queues, caches, databases, or organizational boundaries. Reach for this whenever the explanation would otherwise involve sentences like "service A talks to service B which writes to queue C".
Generates standalone HTML diagrams in flat engineering blueprint style using Tailwind v4 and D3 v7. For architecture diagrams, system flows, technical spec sheets, and component maps.
Generates dark-themed standalone SVG diagrams for architecture, flowcharts, sequence diagrams, mind maps, timelines, state machines, data flows, and more.
Share bugs, ideas, or general feedback.
ASCII diagrams in markdown are a workaround for not having SVG. With SVG inside HTML, you get real shapes, real arrows, real typography, and real positioning — for the same conceptual cost.
Use this skill any time the explanation has arrows, boxes, layers, time, or position. Most technical concepts do.
This is the general fallback. When the prompt names a specific subject, hand off to the specialised skill that knows the conventions:
html-architecture-diagrams (service maps, ownership boundaries, on-call use)html-erd-explorer (PK/FK/cardinality, migrations)html-timeline-roadmap (lanes, dependencies, "today" marker)Use this skill when the diagram is conceptual or general-purpose (flowchart, state machine, sequence, dependency graph between abstract things). The specialised skills win when the subject is a real system, schema, or schedule.
SVG inline using real <svg> and <g> elements. Use viewBox so the diagram scales without re-layout. Pair every diagram with a short prose explanation underneath — the diagram alone is rarely enough.
For multi-diagram pages, use one SVG per concept with its own caption rather than one giant SVG with everything.
These defaults apply to every artifact this skill produces, on top of the requirements above. If a rule above conflicts with this list, the rule above wins; otherwise these are non-negotiable.
.html file the user opens in a browser — never inline-render in chat. Every artifact this skill produces is a file on disk (<topic>-<kind>.html), not an HTML block embedded in the agent's chat surface (claude.ai artifact/canvas widgets, fenced html blocks, custom rendered iframes, etc.). Inline rendering strips features, themes unpredictably against the surrounding chat (often unreadable in dark mode), and lacks the stable origin and clipboard/network access the submit handler needs. Always write the file. The file itself must be self-contained: no build step, no external runtime, inline CSS and JS. Google Fonts via <link> is fine; otherwise nothing loaded from npm or a CDN unless this skill explicitly calls for it.localStorage / sessionStorage / IndexedDB. Claude.ai artifacts can't use browser storage. State lives in JS memory; the export / copy button is the persistence layer.<pre><code> (selectable, copyable). Tabular data goes in <table>. Diagrams are inline <svg> with real <g> and <path> elements, not embedded PNGs. The reader should be able to copy any value, line, or label out of the artifact.textContent for text and document.createElement + appendChild for structure. Never set innerHTML from a string that includes a variable, user input, computed value, or imported data — it's an XSS vector and many agent harnesses (including Claude Code) block it via security hooks. Static literal markup inline in your script is fine.:root so the whole artifact can be re-skinned in one place — and so design decisions are visible, not buried in 40 inline declarations.Cmd/Ctrl+P should produce something usable: backgrounds that carry meaning print, content doesn't get clipped, dark themes have a sane print fallback.<topic>-<kind>.html) so multiple artifacts on one project compose into a readable folder, not a pile of output.html collisions.For request/response paths, ETL pipelines, decision branches. Boxes for stages, arrows for direction of data, conditional diamonds for branches. Annotate edges with the data shape passing through.
For interactions over time across multiple actors (services, components, processes). Vertical lifelines per actor, horizontal arrows for messages, time flowing downward. Number the steps.
For things with discrete states and transitions (order status, connection status, UI mode). Circles for states, arrows for transitions, transitions labeled with the event that triggers them and the side effect.
For "how the system fits together". Layers or zones, components inside, edges showing communication. Distinguish sync (solid) from async (dashed) edges. Show data ownership boundaries clearly.
For "what depends on what" — modules, packages, services. Nodes for things, directed edges for dependencies. Layer by depth or by group. Highlight cycles in red.
For sequences with duration. Horizontal time axis, bars for activities, dependency arrows between bars. Mark milestones with vertical lines.
For stack-like concepts (network layers, abstraction layers, request lifecycle). Horizontal bands, each labeled, with concrete details inside.
Avoid generic "boxes and arrows" defaults. Pick a deliberate style:
The style should match the document the diagram lives in.
Read our rate-limiter code and produce a single HTML page with three diagrams: (1) the token-bucket data flow, (2) the request lifecycle as a sequence diagram, (3) the state machine for the bucket itself. Caption each. End with a "gotchas" section.
Output: HTML file with three labeled SVG diagrams in sequence (data flow → sequence → state machine), each captioned, followed by a gotchas section listing 3–5 non-obvious behaviors.