Proactively create a visual HTML page when plain text cannot effectively convey the information. Use this skill when: the content involves diagrams (flowcharts, architecture, sequence diagrams), data comparisons (tables, charts), timelines, interactive demos, visual layouts, or any scenario where a simple webpage would communicate more clearly than markdown text. Also use when the user explicitly asks for a visual page, a webpage, or says "show me" / "画个图" / "做个页面" / "可视化". This skill should be used proactively by the model — do not wait for the user to ask.
Proactively create a visual HTML page when plain text cannot effectively convey the information. Use this skill when: the content involves diagrams (flowcharts, architecture, sequence diagrams), data comparisons (tables, charts), timelines, interactive demos, visual layouts, or any scenario where a simple webpage would communicate more clearly than markdown text. Also use when the user explicitly asks for a visual page, a webpage, or says "show me" / "画个图" / "做个页面" / "可视化". This skill should be used proactively by the model — do not wait for the user to ask.
descriptions
{"zh-Hans":"在纯文本难以表达时主动创建可视化 HTML 页面，适用于图表、流程、时间线、交互演示和布局说明。"}
displayNames
{"zh-Hans":"可视化页面"}
Visual Page Skill
Workflow
Create a self-contained local HTML page and deliver it to the user.
Choose an output path:
If the user specified an output path, use it.
If the user provided an input file or directory and no output path, save the HTML next to the input when appropriate.
Otherwise, create a descriptive .html file in the current workspace or a temp directory.
Write one complete index.html-style document with all CSS and JavaScript inlined unless an external CDN library is genuinely useful (Tailwind, Chart.js, Mermaid, D3).
Verify the page is valid enough to open directly in a browser: no missing local assets, no broken relative references, responsive layout.
Send the file to the user: <media type="file" src="/absolute/path/to/page.html" caption="Visual page" />
When the user asks to revise or update a page, edit the existing HTML file directly so any previous references stay valid. If the previous file is unavailable, create a new one and mention it.
Design Philosophy
Aesthetics is the goal, not decoration. A page that "works" but looks cheap is a failure. The reader's eyes judge in 2 seconds before reading a single word. Treat beauty as a non-negotiable requirement equal to data correctness.
图表先行，文字辅助。 Charts, diagrams, and illustrations are the PRIMARY communication tool — they let readers grasp the point in seconds. Text exists to annotate details that visuals can't convey alone. When building a page, start from "what chart/diagram tells this story?" not "what paragraphs explain this?" If a section has 3+ paragraphs without a visual, you're doing it wrong — find the chart, flow, or illustration that replaces most of that text.
Design for the reader. You are guiding a human eye, not displaying your work. One H1, one core conclusion, F-pattern scanning. Empty space is a feature. Charts and inline SVG beat dense paragraphs for any structured comparison or hierarchy.
Less is more. Every element earns its place. No filler sections, no data slop (pointless stats/badges). When unsure between "add another card" or "let it breathe" — let it breathe.
Rules
1. Pick the page mode FIRST
Mode
When
Background
Font
Data UI
Dashboards, charts, tables
#fafafa / white
Sans (Outfit)
Long-read / Report
Research, design docs, architecture pages
Warm cream #f7f5f0
Sans body + serif headlines (DM Serif Display)
Terminal
Code demos, log viewers
#1a1a2e (NEVER #000)
Mono-prominent
Wrong-mode = ugly page. Research report on dark slate → dashboard look. Dashboard with serif → poster look.
2. Color
BANNED: pure #000, purple/blue AI gradients, neon glows, oversaturated accents.
Most CSS frameworks assume Latin typography. CJK characters are square blocks with built-in
visual mass — copying Latin defaults (line-height: 1.7+, body 16-17px, section gap 80px+,
card padding 28-32px) makes Chinese pages feel sparse, with the first screen showing only
a hero and one card.
Calibrate: does the first screen communicate the core idea, or is it just hero + breathing room?
Working ranges for CJK-heavy text (adjust by content, not hard rules):
Body: 14–15px, line-height 1.5–1.65
Headlines: H1 28–34px, H2 22–26px
Section gaps: 40–56px
Paragraph margin-bottom: 8–12px
Card padding: 16–22px
Latin-only pages can be more generous. Mixed CJK + Latin follows the CJK side.
No emoji as icons, no ASCII art (┌─┐ │ ├─) for diagrams. Use inline SVG from lucide.dev with currentColor, stroke-width="2", viewBox="0 0 24 24". One icon per section header max.
For diagrams: use the minimal patterns in §8, or Mermaid for 4+ nodes. Never box-drawing characters.
7. Visualization — chart-first, pick the right renderer
Default mindset: every key point deserves a visual. Ask "what chart explains this?" before writing paragraphs. Text annotates what the visual can't show alone.
Visual need
Renderer
Architecture / module layers
Inline SVG or CSS grid
Flowchart, process flow (≥4 nodes)
Mermaid
Flowchart, process flow (2-3 nodes)
Inline SVG or CSS cards + arrows
Pie / bar / line chart, time-series >8 points
Chart.js
Data comparison (2-8 rows)
CSS bench bars or <table>
Timeline / roadmap
CSS list with vertical rail
Key-value pairs ≤6 rows
CSS two-column grid
Rule: don't import Chart.js / Mermaid for <5 data points or <4 nodes — hand-roll with CSS / inline SVG.
When using Chart.js, match the page typography: font.family = "'Outfit'", muted gridlines (borderColor = 'rgba(0,0,0,0.04)'), borderRadius: 6.
8. Minimal patterns
Three starting points for the most common shapes. Treat them as scaffolds, not constraints — adjust spacing, colors, structure to fit the page. CSS vars assume the Report palette (see §2).
