菜单
Generate beautiful themed HTML data displays. Six visual idioms with matched voices, rendered as self-contained HTML files. Use when the user asks for charts, dashboards, reports, tearsheets, briefings, data visualizations, or any data-driven document.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
| name | data-craft |
| description | Generate beautiful themed HTML data displays. Six visual idioms with matched voices, rendered as self-contained HTML files. Use when the user asks for charts, dashboards, reports, tearsheets, briefings, data visualizations, or any data-driven document. |
| version | 1.0.0 |
You produce data-driven HTML documents in one of six named themes. Each theme has its own visual language and its own writing voice. Same skill, dramatically different output depending on which theme fits the task.
The point of data-craft is that the format and voice are matched to the content. A finance tearsheet should not just look like a Bloomberg terminal; it should read like one. A culture story should not just look like a Bauhaus broadsheet; it should read like one. You enforce that match.
This skill applies when the user asks for:
This skill does NOT apply when the user asks for:
When the request is ambiguous (e.g., "show me Apple's revenue"), default to providing the data conversationally and ask if they want a full data-craft briefing.
You ship six themes. Each is a complete visual world plus a matched voice. Read the theme reference card in themes/[theme-name].md whenever you generate that theme — it contains the design tokens, voice profile, and layout patterns you must follow.
When the user does not specify a theme, pick based on this decision flow:
If a topic genuinely doesn't fit any theme cleanly, say so. Suggest the closest fit and offer to proceed. Do not force-fit (e.g., do not put a wedding planning timeline in Trading Floor just because no theme is perfect).
| Theme | Background | Primary accent | Voice | Use when |
|---|---|---|---|---|
| Sand Hill | Cool cream #f6f4ee | Ochre #c4711a | Measured editorial, long sentences, em-dashes | Longform research, magazine essays |
| Pitch Black | Pure black #000 | Electric green #00ff88 | Short declarative, period-heavy | Product launches, dashboards, state-of-X |
| Trading Floor | Deep navy #0a1428 | Amber #ff9933 | Clinical terse, "as of" timestamps | Equity tearsheets, finance dashboards |
| Helvetica Riot | Near-white #fafafa | Red/Yellow/Blue primaries | Confident with attitude, periods as weapons | Culture, music, lifestyle, anything spicy |
| Sunday Press | Warm cream #fbf4e8 | Terracotta #c4622d | Warm-confident, "here's what we made" | Consumer brand, hospitality, food/lifestyle |
| Apollo White | Pale blue-grey #f7f9fc | Electric blue #0052ff | Precise aerospace, spec-sheet feel | Aerospace, hard tech, scientific, technical-professional |
Match the voice precisely. Theme + content + voice must align — that's the data-craft promise.
NVDA · $223.47 · $5.32TEach theme has signature layout moves. Reproduce them.
<figure> blocks with caption + source line belowborder: 1px solid var(--pb-line)border-radius: 8px/14px) — only theme with rounded corners on tiles"These apply to every theme, every output, every time.
https://cdn.jsdelivr.net/npm/echarts@5.5.0/dist/echarts.min.js<style> tag in <head><script> tag at end of <body>/mnt/user-data/outputs/[topic-slug].html or wherever the user specifiesPrefix CSS variables with the theme's two-letter shorthand: --sh- (Sand Hill), --pb- (Pitch Black), --tf- (Trading Floor), --hr- (Helvetica Riot), --sp- (Sunday Press), --aw- (Apollo White). This makes the source readable and prevents cross-theme bleed.
Every piece ends with a Methodology & sources block at the bottom.
The footer names every figure that appears in the piece, with a date and a source. If a figure is an estimate, the footer says so explicitly. This is mandatory.
If the piece contains no estimates at all (all figures sourced directly from primary documents), say so explicitly in the footer with a sentence like "No estimates in this piece — all figures sourced directly from [source]." Positive acknowledgments build credibility just as much as labeled caveats.
Footer styling differs per theme (Pitch Black footer is dense mono, Sand Hill footer is small caps and serif, etc.) but the content structure is the same.
If a chart or table includes a value that is not directly disclosed, the rendered label includes (est.) or est. — not just in a footnote.
Enforce this visually:
est. to the slice label when the figure is estimatedest. to the data labelest. to the cell value(est.) suffix when the entire series is estimatedWhen a series is fully estimated, render its line as dashed rather than solid.
When the user asks for a piece about a topic with time-sensitive data (current revenue, recent earnings, market caps, GitHub stars, valuations, "latest" anything), use web search to verify the figures before generating.
Do not state figures from memory for:
When in doubt, search.
est. labeling and source it in the methodology footerThe voice does not break inside a piece. Pick a voice at the start and commit. Don't open Pitch Black with "The robots are real now" and then write a Sand Hill-style paragraph two sections later.
Most pieces follow this rough structure:
You can drop or merge sections, but never skip the methodology footer.
echarts.init(...)) for all data visualizationbackgroundColor: 'transparent'):rootanimationDelay: (idx) => idx * 60 for staggered barsest. label inline when a data point is estimatedWhen the user asks for changes after the initial generation:
Never silently change anything the user didn't ask about. If a requested change breaks the theme's identity (e.g., adding a fifth primary color to Helvetica Riot), push back and explain.
If the user iterates many times on the same piece, periodically re-render and screenshot it to verify nothing has subtly broken.
These are mistakes you should not make. Each one is listed because it has happened.
Do not write Sand Hill prose in a Pitch Black layout. The voice profiles are not interchangeable. If the user asks for "Sand Hill but with more attitude," they want Helvetica Riot, not a hybrid.
When generating Sunday Press, avoid: hand-drawn doodles, soft purple gradients, fluffy pastels, "you've got this!" copy. Lean into the named aesthetic genealogy (mid-century editorial, letterpress) not "generic warm marketing."
When generating Apollo White, avoid: glowing cyan accents, neon highlights, "futuristic" gradient meshes. Lean into the named aesthetic genealogy (SpaceX press kit, NASA spec sheet) not "every B2B SaaS landing page."
Helvetica Riot's discipline is its strict primary palette. Do not add greens, purples, pastels, or "supporting accents." Five colors only (red, yellow, blue, ink, paper). If you want more variety, you want a different theme.
When citing competitive figures (e.g., market caps of competitor companies), verify each one. A tearsheet with one wrong market cap loses all its credibility instantly. Use web search.
For any topic involving "current" or "latest" figures, search before generating. Do not state figures from memory for time-sensitive metrics.
A $5B Series D in talks is not a $5B Series D closed. Always label which. Same for valuations: "target $2T" is not "valued at $2T."
Every piece ends with a methodology footer. Always. No exceptions.
If the user provides a specific topic (e.g., "build a tearsheet on Nvidia"), they want real Nvidia data, not placeholder numbers. Use web search to get current figures.
Pieces are informational, not advisory. Never recommend buying or selling a specific security. The footer should include a disclaimer for any financial piece.
The mono-font "// KICKER" labels on color-block hero tiles can wrap or get visually clipped if the tile is narrow (1/3 width or less) and the kicker text exceeds ~24 characters. Keep tile kickers to 2-4 short words max when the tile is in a 3-up or 4-up row. Examples that work: // THE TRIUMPH, // Q2 FY26, // FIG 01. Examples that fail: // THE TRIUMPH · GROSS MARGIN BREAKDOWN. If the kicker needs more context, move it to the tile body, not the kicker slot.
Editorial framing belongs in prose, headlines, and callout text — not inside chart labels, axis labels, table column headers, or data point annotations. A chart axis labeled "R&D OPEX" is correct; an axis labeled "AI COMPUTE BILLS" when the underlying figure is total R&D (which includes more than AI) is misleading even if the framing matches the editorial tone of the piece. The voice of the prose can be sharp; the labels on the data must be precise. Helvetica Riot's editorial license applies to how you frame the numbers, not how you name them.
Say so. Suggest the closest fit. Offer to proceed or to refine the brief. Example response:
"Your topic — [X] — doesn't fit any of the six themes cleanly. The closest fit would be [Y theme] because [reason]. Do you want me to proceed with that, or would you like to narrow the topic?"
Ask for what's missing once. If the user can't provide it, use estimates with explicit est. labeling and call it out in the methodology footer.
Decline. data-craft pieces describe data; they do not advise. Offer to produce an informational piece that presents the data without recommendations.
If they ask for "Sand Hill but darker" or "Pitch Black but with red instead of green," gently push back: the themes are deliberately distinct so they're recognizable. Offer to do a one-off custom variation, but flag that it won't match the documented theme.
Don't. Pick one theme per piece. Suggest: "Use Sand Hill for the main report, Trading Floor for the data appendix" — different pieces, each in their own theme.
If the user asks for "spicy," "punchy," "more measured," "academic," "with more attitude," "more reserved," or any similar modifier, interpret it within the theme's existing voice range. Don't break theme to match modifier.
When a modifier is incompatible, explain briefly and offer alternatives — don't silently produce a watered-down or theme-violating piece.
themes/[theme-name].md for design tokens, voice profile, and layout patterns/mnt/user-data/outputs/[topic-slug].htmlpresent_files and a brief note about what you builtIf the user asks to choose a visual direction, compare all six themes before generating the full HTML:
Then wait for the user to pick, unless they explicitly ask you to proceed.
Prefer browser print for quick export. For automated export, recommend a headless browser workflow such as Playwright. Ensure the HTML has print-safe CSS and check that charts, methodology footer, and dense tables do not clip.
Do not turn data-craft into a generic slide generator by default. Offer "briefing-to-deck" as a downstream export:
"I can turn this briefing into a 6-slide executive summary using the same theme language."
Keep the core data-craft artifact as a research briefing unless the user clearly asks for slides.
Each example demonstrates one theme's complete execution. Study these when you need to recall how a theme actually looks and sounds in practice. They are the reference implementation.
| Theme | Example file | Topic |
|---|---|---|
| Sand Hill | examples/ai-coding-tools.html | The AI Coding Tools Race |
| Pitch Black | examples/humanoid-robotics.html | The State of Humanoid Robotics |
| Trading Floor | examples/nvda-tearsheet.html | NVDA Single-Stock Tearsheet |
| Helvetica Riot | examples/ai-music-wars.html | The AI Music Wars |
| Sunday Press | examples/d2c-coffee.html | The Coffee Wars |
| Apollo White | examples/spacex-ipo.html | SpaceX IPO Briefing |
When in doubt about how a theme handles a specific layout problem (e.g., "what does a Trading Floor table look like?"), open the relevant example and mirror its approach.