html-svg-diagrams

これはレビュー時に保存された抜粋です。完全で最新の内容は外部ソースを確認してください。

---
name: html-svg-diagrams
description: 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".
metadata:
  version: "1.2.1"
---

# HTML SVG Diagrams & Flowcharts

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.

## When to use this skill

- "Diagram / illustrate / visualize / draw X"
- "Show me how the [request, data, message] flows"
- "Sketch the [architecture, state machine, sequence]"
- "Map the [dependencies, components, boundaries]"
- Any explanation where the prose would lean heavily on words like "first… then… meanwhile… eventually" — those are sequence diagrams begging to be drawn

## When NOT to use this skill

This is the general fallback. When the prompt names a specific subject, hand off to the specialised skill that knows the conventions:

- **System architecture, microservices, deployment topology** → `html-architecture-diagrams` (service maps, ownership boundaries, on-call use)
- **Database schema, ERD, table relationships** → `html-erd-explorer` (PK/FK/cardinality, migrations)
- **Time axis, roadmap, Gantt, incident timeline** → `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.

## Output requirements

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.

## HTML output foundation

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.

- **Output a real `.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.
- **Mobile-responsive.** Collapse cleanly to a single column under ~700px so the artifact opens on a phone — including during incidents, commutes, and link-shares to non-laptop reviewers.
- **No `localStorage` / `sessionStorage` / `IndexedDB`.** Claude.ai artifacts can't use browser storage. State lives in JS memory; the export / copy button is the persistence layer.
- **Real semantic HTML, not screenshots.** Code goes in `<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 abl