Skill detail

html-erd-explorer

Creates interactive HTML ERDs, a focused visualization use case.

MatchPossibleReviewed for html
Sourcef-labs-io/agent-html-skillsExternal source
Reported installs147Popularity signal only

Inspect before use

Automated review checks relevance, not safety or endorsement. Read the source instructions before using this skill.

Saved source preview

SKILL.md

The saved excerpt is a snapshot from review. The external source remains the complete and most current version.

---
name: html-erd-explorer
description: Generate HTML entity-relationship diagrams (ERDs) and database schema visualizations with clickable tables, relationship paths, and migration before/after views. Use whenever the user has a database schema, data model, or table structure to document, explain, migrate, or explore — even when they call it a "data model", "schema diagram", or just "the tables". Reach for this any time the conversation touches database structure with more than ~3 tables.
metadata:
  version: "1.2.1"
---

# HTML ERD & Schema Explorer

Database schemas are inherently visual — tables connected by foreign keys, with cardinality and direction. ERDs in markdown are awkward; in dedicated tools they're heavy. An HTML ERD is portable, embeddable in a doc, and click-to-explore.

## When to use this skill

- "Diagram our [schema, data model, database, tables]"
- "Show me how [table X] relates to [table Y]"
- "Document the schema for [feature/service]"
- "Plan the migration from this schema to that one"
- "Explain how a query touches the schema"
- Any time a database structure with ≥3 tables enters the conversation

## Output requirements

Tables rendered as cards/boxes with their columns listed. Foreign key relationships drawn as connecting lines with cardinality markers (1, *, etc.). Click a table to expand or focus.

Include a legend explaining symbols (PK, FK, indices, nullable).

## 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 able to copy any value, line, or label out of the artifact.
- **Build DOM safely; don't sling strings.** Use `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.
- **SVG text doesn't wrap — size the shape to the label, or use `<foreignObject>`.** Plain SVG `<text>` overflows silently when the label is longer than the box was sized for, crashing into adjacent shapes. For variable-length or potentially-long labels, wrap with `<foreignObject width="W" height="H">` plus an HTML `<div>` inside — real wrapping, real padding, real `text-overflow:ellipsis`. Plain `<text>` is fine only for short, fixed-length labels — and even then, size the surrounding shape from the label length (≥ 8px per char + 16px p
Read the full source on GitHub (opens external page)
Context

Related work