Stats
Actions
Tags
Help us improve
Share bugs, ideas, or general feedback.
From html-skills
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".
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-architecture-diagramsThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
Architecture diagrams answer the questions that come up most often during incidents and design reviews: what talks to what, who owns what, where does the data live, what fails when X goes down. A good HTML system diagram is the document you open during the incident, not the one you write after.
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".
Generates layered architecture diagrams as self-contained HTML files with inline SVG icons, CSS Grid zones, and JS-driven color-coded connection overlays for systems, infra, and deployments.
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.
Share bugs, ideas, or general feedback.
Architecture diagrams answer the questions that come up most often during incidents and design reviews: what talks to what, who owns what, where does the data live, what fails when X goes down. A good HTML system diagram is the document you open during the incident, not the one you write after.
This skill is more focused than general SVG diagrams — specifically for system-level architecture.
Diagram as inline SVG. Include a legend if shapes/colors carry meaning. Save with a name like <system>-architecture.html and treat it as a versioned doc — these get opened during incidents, so the date in the footer matters.
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.Boxes for services. Edges for calls between them. Distinguish:
For larger maps (~10+ services), group by domain into bounded zones.
Regions, VPCs, availability zones, k8s clusters, queues, caches, databases. Show physical/logical placement, not just service names. Include load balancers and ingress points. Mark single-region from multi-region resources.
Directed graph of "what depends on what". For monorepos: package-level. For services: service-level. Layer by depth. Highlight cycles in red — they're usually problems.
The path data takes through the system from ingress to storage. Each transformation/enrichment is a stage. Show queue boundaries clearly — they're often where incidents hide.
For systems that connect to many external services (CRM, payment, analytics, webhooks). The system in the middle, externals around it, edges labeled with what flows.
For showing abstraction layers (presentation / application / domain / infrastructure). Horizontal bands. Components inside. Cross-layer calls drawn explicitly.
Pick a meaning and stick to it across the diagram:
Don't color for decoration. If color isn't conveying info, use neutral fills.
Big systems benefit from multi-zoom diagrams in one HTML file:
Link from the zone in the top map down to its detail section. The reader scrolls to the level they need.
System diagrams benefit from inline notes near specific elements:
Use small margin notes connected by thin lines. Don't crowd the diagram itself.
Diagram our payments architecture as an HTML page. Three regions, payment service in each, a global ledger DB in us-east, async events to a fraud service, sync calls to two third-party processors. Show data ownership and mark the single point of failure.
Output: HTML file with an SVG topology showing three regional zones, services per region, the global ledger with explicit single-region marking, dashed lines to fraud service, solid lines to processors, color-coded by criticality, with a legend, last-updated timestamp, and a margin note flagging the global ledger as the SPOF.