html-design-tokens

这段内容是审核时保存的快照。外部来源才是完整且最新的版本。

---
name: html-design-tokens
description: Showcase design tokens — color palettes, type scales, spacing systems, radius scales, shadow systems, motion tokens — as HTML pages with copy-paste CSS variable exports, contrast ratio checks, and live sample type. Use whenever the user shows or asks about a palette, theme, design system, branding colors, design tokens, or wants to document any system of values that drives visual design. Markdown literally cannot display colors; reach for this skill any time color or spatial values are involved.
metadata:
  version: "1.2.1"
---

# HTML Design Token Showcases

Markdown can't show colors. Unicode block characters are a hack and a tell that the writer wished they had a different format. For palettes, type scales, spacing systems, and any other design tokens, use HTML — the values can be displayed for what they actually are.

## When to use this skill

- "Show me / document our [palette, colors, theme, tokens, design system]"
- "Build a token reference for X"
- "Document the spacing / type / color scale"
- Whenever a markdown file would have to fake a color with `█████` blocks
- Whenever a developer needs to copy CSS variables out of a doc

## Output requirements

Each token is shown:
1. Visually rendered (the actual color, the actual spacing, the actual shadow)
2. With its identifier (`--color-accent-500`, `space-md`)
3. With its value (`#B8602A`, `12px`)
4. With a copy button that puts the value or the CSS variable on the clipboard

Token grids reflow at narrow widths so the doc stays readable on a phone — designers and developers actually read these on the move.

## 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>` ins