htmldesign

name

htmldesign

description

Create single-file HTML deliverables — editorial diagrams, interactive visualizations, distinctive landing pages, UI prototypes, interactive Plotly charts, single-page reports, and reveal.js slide decks. Dispatch to the best of 7 methods based on user intent. Triggered when the user asks for HTMLでアウトプット / 単一HTML / インタラクティブ / ランディングページ / プロトタイプ / モックアップ / ダッシュボード / レポート / スライドデッキ / reveal.js / Plotly HTML / hover や click できる図 / シェアできる単一ファイル / etc. Operates in two modes — (a) interactive (clarify intent then build), and (b) automatic (when type, content and layout are fully specified). For non-HTML output (SVG/PNG/PDF/MP4) use the visualize2 skill instead. For multi-file React or shadcn projects use frontend-design or web-artifacts-builder.

htmldesign

Author single-file HTML deliverables that the user can drop into a browser, attach to Slack/email, embed in Notion, or commit to a repo. No build step, no install, no React. Operate in interactive mode (1–3 clarifying questions, then build) or automatic mode (when type/content/layout are specified).

1. Workflow

[user request]
  ↓
[Step 1] Classify the intent  →  see references/methods.md
  ↓
[Step 2] Choose a method       →  see Section 3 (decision rules)
  ↓
[Step 3] Confirm or proceed    →  see Section 4 (modes)
  ↓
[Step 4] Generate              →  read the matching references/<method>.md and author the HTML
  ↓
[Step 5] Save under ./outputs/ →  filename per Section 5

2. Supported methods (7) and what each is best at

#	Method	Best for	Style hallmarks
1	Editorial diagram	blog/article explanatory figures (read-to-understand)	inline SVG, 4px grid, hairlines, no shadows, brand palette
2	Interactive visual	"let me touch this" data figures inside an article/Slack	vanilla SVG + <script>, hover/click, no framework
3	Distinctive landing	marketing / hero sections / one-pagers	bold type, asymmetric grid, scroll-triggered motion, layered depth
4	Prototype / UI mockup	dashboards, settings panels, onboarding screens (for screenshots)	design tokens, dark/light, sidebar+main, components-look
5	Plotly HTML	data charts the reader can pan/zoom/hover/legend-toggle	Plotly via CDN, single trace or subplots, light layout
6	Single-page HTML report	stakeholder report — text + charts + tables in one print-ready page	typographic body, embedded SVG/charts, page-break CSS
7	Slide deck (reveal.js)	technical talks, demo decks, web-shareable presentations	reveal.js via CDN, vertical slide structure, speaker notes

Detailed per-method patterns: load the matching references/<method>.md file lazily.

3. Method selection — decision rules

Apply rules top-to-bottom; pick the first that matches.

1. User explicitly named a method ("editorialで", "Plotlyで(HTML)", "reveal.jsで", "ランディングページ", "プロトタイプで", "レポートで") → use it.
2. User said "プレゼン / スライド / slides / deck" → slides (reveal.js).
3. User said "レポート / report / 単一ページにまとめて" with multiple sections → single-page report.
4. User said "ランディング / landing / LP / ヒーロー / マーケ" → distinctive landing.
5. User said "ダッシュボード / 管理画面 / 設定画面 / モックアップ / プロトタイプ" → prototype.
6. User wants data charts the reader can interact with (hover/zoom/legend) AND has numeric data → Plotly HTML. (For brand-styled handcrafted interactivity prefer rule 7.)
7. User wants a custom small-dataset interactive figure (e.g. 4-bar dashboard with click-to-highlight) → interactive visual (vanilla).
8. User wants an explanatory figure for an article (no interactivity required) → editorial diagram.
9. Tie-breaker — prefer in this order: editorial > interactive > prototype > Plotly HTML > landing > report > slides. (Most-canonical match wins.)

Full intent → method mapping: see references/methods.md (read on demand).

4. Two operating modes

4a. Interactive (default when intent is ambiguous)

Ask at most 1–3 short questions before building:

1. What is being shown? (data? concept? product UI? sales pitch? talk?)
2. Where will it live? (blog / Notion / Slack / printout / web URL / talk on stage)
3. Brand or style? (brand colors? dark/light? "minimal" / "playful" / "editorial"?)

Then state the chosen method + style in one line, build, save, report path.

4b. Automatic (no clarification)

When the request fully specifies type, content, and style (or these can be inferred), proceed without questions. Examples:

• "売上推移を hover できる Plotly HTML で" → Plotly HTML + line + hover
• "CTOへの提案レポートを単一HTMLで" → single-page report
• "新製品のランディングページ、ダーク基調" → distinctive landing + dark
• "通知設定画面のプロトタイプ、モバイル版" → prototype + mobile

State the choice in one line ("editorial diagram + brand palette で生成します") then produce.

5. Output

• Always single HTML file (<!DOCTYPE html> + inline <style> + inline <script>).
• External assets are allowed only as CDN script tags (Plotly, reveal.js). Avoid external CSS unless unavoidable.
• Save to ./outputs/ (project CWD) unless user specifies. Filename is lowercase snake_case derived from intent (e.g. revenue_dashboard.html, q4_landing.html, aurora_pitch.html).
• Do not overwrite an existing file silently — confirm first.

6. Quality bar

• Single file: no separate .css/.js files unless explicitly requested.
• Renders offline (CDN-only is acceptable; otherwise inline everything).
• Mobile-aware: responsive viewport meta tag + a layout that doesn't break under 480px.
• Accessibility: semantic HTML, alt on images, labels on form controls, color contrast ≥ 4.5:1.
• No emojis in copy unless the user asks for them.
• No tracking scripts, no autoplay audio/video.
• Print-friendly if the deliverable is a report (use @media print to hide chrome).
• Brand restraint: max 2 typefaces, max 5 colors, consistent border-radius and spacing scale.

7. Method-specific authoring pointers

Read only the relevant reference file (progressive disclosure):

• references/methods.md — intent → method lookup table
• references/editorial.md — editorial diagram patterns (4px grid, hairlines, palettes)
• references/interactive.md — vanilla SVG+JS patterns (hover, click-lock, metric switcher)
• references/landing.md — landing-page archetypes (hero, marquee, feature grid, CTA)
• references/prototype.md — UI tokens, common components (toggle, slider, pill, button)
• references/plotly_html.md — Plotly via CDN, layout polish, frame-based animation
• references/report.md — single-page report skeleton (cover, body, charts, tables, footer)
• references/slides.md — reveal.js skeleton, slide grammar, speaker notes

8. Tools

This skill is mostly direct HTML authoring — Claude writes the file. Two helper scripts assist data-driven cases:

Helper	Purpose
scripts/plotly_html.py	Convert a numeric dataset (CSV/JSON) into a self-contained Plotly HTML chart
scripts/preview.py	Start a local HTTP server on port 8765 to preview the generated HTML in a browser

9. Failure handling

• If a referenced CDN URL is wrong/changed → use the latest pinned version from the relevant references/<method>.md.
• If the file exceeds ~2 MB → suggest splitting (e.g. moving Plotly to a CDN-loaded version, or compressing inline images).
• If interactivity tests reveal a layout bug under 480px → fix and report.

10. End-of-task report

After building, report in 1–2 lines:

✅ <method> で <filename> を作成しました（<size> KB）。ブラウザで開いて確認してください。

If multiple files: list paths in a code block. In interactive mode you may append: "色味/レイアウト/コピーを調整しますか？"

11. When NOT to use this skill

Redirect to a more appropriate skill in these cases:

User wants…	Use instead
SVG / PNG / PDF / MP4 / GIF (non-HTML)	visualize2
Production multi-file React / Tailwind / shadcn	frontend-design (Anthropic plugin)
Multi-component HTML artifacts with React/Tailwind/shadcn	web-artifacts-builder
.docx / .pptx / .xlsx files	docx / pptx / xlsx
Something to deploy (multi-file site)	webgen (or your project's deployment skill)