make-html

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Make HTML

制作 HTML

Default Posture

默认立场

Make an HTML artifact for substantial deliverables. When in doubt, use HTML. Markdown and plain chat are fallbacks for brief exchanges, not the default for work a human needs to read, compare, present, share, or manipulate.

Usually produce a single self-contained

.html

file. If the environment cannot create files, output the complete HTML document in one fenced

html

block and name the intended filename.

Do not ask permission to use HTML unless the user requested a conflicting output format.

Use the strongest version of the medium. Do not wrap a Markdown-shaped answer in HTML. If the content is a comparison, make it comparable. If it is a timeline, draw a timeline. If it is a diagram, draw the diagram. If it is an editor, make the export path central.

内容较多的交付物应采用 HTML 形式。存疑时使用 HTML。Markdown 和普通聊天仅作为简短交流的备用形式；对于需要阅读、对比、演示、分享或操作的工作，不应默认采用这些形式。

通常生成一个自包含的

.html

文件。如果环境无法创建文件，则在一个

html

代码块中输出完整的 HTML 文档，并注明目标文件名。

除非用户要求了相冲突的输出格式，否则不要询问是否可以使用 HTML。

充分发挥这一媒介的优势。不要只是把 Markdown 形态的答案包裹进 HTML。如果是对比，就做成可对比的形式；如果是时间线，就绘制时间线；如果是图表，就绘制图表；如果是编辑器，就把导出路径置于核心位置。

Workflow

工作流

Classify the job shape: comparison, plan, review, code map, explainer, report, dashboard, diagram, deck, prototype, or editor.
Read the relevant reference file:
- ```
references/recognition.md
```
  when deciding whether the task deserves HTML.
- ```
references/artifact-patterns.md
```
  for static or mostly static documents.
- ```
references/interaction-patterns.md
```
  for prototypes, explainers, dashboards, and editors.
- ```
references/visual-quality.md
```
  before writing the final artifact structure and styling.
- ```
references/validation.md
```
  before returning any nontrivial artifact, especially artifacts with JavaScript, SVG, tables, diagrams, or dense responsive layouts.
- ```
references/sharing.md
```
  when the user asks for a hosted preview, shareable link, cross-device review, or annotation feedback.
- ```
references/source-style.md
```
  when the artifact is about an existing product, repository, brand, app, docs site, or design system.
- ```
references/custom-themes.md
```
  when the user asks for a saved/custom/personal theme, when a theme name is provided, or when no source style exists and
```
themes/
```
  contains a default or clearly matching theme.
- ```
themes/fallback-theme.md
```
  when no source/project style can be found after a quick style search, or when the artifact has no natural brand.
- ```
references/example-layout-catalog.md
```
  when the task resembles one of the HTML-effectiveness example pages, or when choosing a specific style, layout, or interaction recipe.
- Read multiple references when the artifact spans categories, such as a plan with mockups and a flowchart.
Resolve style provenance before writing CSS: source-backed style with concrete files/tokens, an explicitly selected saved theme, or the built-in fallback theme. Do not invent an unlabeled generic theme between these choices.
Choose a page structure that makes the shape of the information obvious. Prefer side-by-side layouts, timelines, maps, tables, diagrams, controls, and navigation over long linear prose.
Write a complete HTML5 document with inline CSS and, when useful, inline JavaScript.
For editor-style artifacts, include a visible export path such as copy as Markdown, copy as JSON, copy diff, copy prompt, or download file.
Include enough source excerpts, labels, assumptions, and style provenance inside the page for the artifact to stand alone.
Validate the artifact before returning it. At minimum, check self-containment, required HTML tags, dynamic render output when JavaScript is present, and narrow-viewport behavior.
When the user asks for a hosted or shareable link, follow
```
references/sharing.md
```
after local validation. Never upload an artifact automatically.

对任务形态进行分类：对比、计划、评审、代码地图、讲解、报告、仪表盘、图表、演示文稿、原型或编辑器。
阅读相关参考文件：
- ```
references/recognition.md
```
  ：判断任务是否适合采用 HTML 时。
- ```
references/artifact-patterns.md
```
  ：用于静态或基本静态的文档。
- ```
references/interaction-patterns.md
```
  ：用于原型、讲解、仪表盘和编辑器。
- ```
references/visual-quality.md
```
  ：在编写最终交付物的结构和样式之前阅读。
- ```
references/validation.md
```
  ：在返回任何非简单交付物之前阅读，尤其是包含 JavaScript、SVG、表格、图表或密集响应式布局的交付物。
- ```
references/sharing.md
```
  ：当用户要求托管预览、可共享链接、跨设备评审或注释反馈时阅读。
- ```
references/source-style.md
```
  ：当交付物涉及现有产品、代码仓库、品牌、应用、文档站点或设计系统时阅读。
- ```
references/custom-themes.md
```
  ：当用户要求使用已保存、自定义或个人主题，提供了主题名称，或找不到源样式但
```
themes/
```
  中存在默认主题或明显匹配的主题时阅读。
- ```
themes/fallback-theme.md
```
  ：在快速搜索后仍找不到源样式或项目样式，或交付物没有自然品牌时阅读。
- ```
references/example-layout-catalog.md
```
  ：当任务与某个 HTML 效果示例页面相似，或需要选择特定样式、布局或交互方案时阅读。
- 当交付物跨越多个类别时阅读多个参考文件，例如同时包含 mockup 和流程图的计划。
在编写 CSS 前确定样式来源：采用有具体文件或 token 支撑的源样式、明确选定的已保存主题，或内置回退主题。不要在这些选项之外自行创造一种未标注的通用主题。
选择能让信息形态一目了然的页面结构。优先使用并排布局、时间线、映射图、表格、图表、控件和导航，而不是冗长的线性文字。
编写完整的 HTML5 文档，CSS 内联，并在有用时内联 JavaScript。
对于编辑器类交付物，提供清晰的导出路径，例如复制为 Markdown、复制为 JSON、复制 diff、复制 prompt 或下载文件。
在页面中加入足够的源内容摘录、标签、假设和样式来源，使交付物能够独立成立。
返回前验证交付物。至少检查自包含性、必需的 HTML 标签、存在 JavaScript 时的动态渲染输出，以及窄视口下的行为。
当用户要求托管或可共享链接时，在本地验证后遵循
```
references/sharing.md
```
。绝不自动上传交付物。

Universal Requirements

通用要求

Use one self-contained
```
.html
```
file by default.

Include

<!doctype html>

<html lang="en">

<meta charset="utf-8">

, a viewport meta tag, and a meaningful

<title>

Put CSS in a
```
<style>
```
block and JavaScript in a
```
<script>
```
block. Do not require a bundler, package install, or build step.
Work offline by default. Do not require network calls, remote fonts, CDN scripts, or external stylesheets for the artifact to render. Use inline SVG, inline data, and data URIs when assets are necessary.
Prefer semantic HTML:
```
header
```
,
```
main
```
,
```
section
```
,
```
article
```
,
```
nav
```
,
```
aside
```
,
```
table
```
,
```
details
```
,
```
button
```
,
```
label
```
, and form controls where they fit.
Use inline SVG, canvas, CSS, and native controls freely when they make the artifact clearer.
Make the page responsive. It should remain readable on narrow screens without page-level horizontal scrolling. Intentional horizontal scrolling is acceptable only inside bounded regions such as code blocks, dense tables, and large diagrams.
Chip-like UI must wrap instead of scrolling horizontally. This includes jump links, filter chips, segmented controls, badges, button groups, tag rows, and legends. Never hide these controls in a horizontal scroll strip.
Force long tokens to wrap where they appear in prose, callouts, badges, cells, and inline code. Local paths, URLs, branch names, hashes, commands, and long identifiers must not widen the whole page.
Do not size text with viewport units. Use explicit sizes plus media-query breakpoints so headings and labels fit predictably.
Use clear hierarchy and dense, scannable layout. Avoid filling the page with decorative shells that do not add meaning.
Styling precedence is: source/project style, explicitly requested saved theme, saved default or clearly matching theme, then fallback theme.
When claiming source/project style, the artifact must be backed by concrete style evidence such as CSS variables, theme config, UI component source, local screenshots, or product pages. Source content alone is not source style.
When no source style evidence is found, use
```
themes/fallback-theme.md
```
directly. Do not create a neutral light dashboard, generic docs UI, or model-invented palette as a substitute fallback.
Add a compact style provenance note in the artifact, usually in the footer or a source/evidence section: name the source files/tokens, saved theme, or fallback theme used.
Make state visible. Selected tabs, active filters, changed values, warnings, and recommendations should be obvious at a glance.
Selection state must be real. Tabs, chips, filters, segmented controls, nav pills, selected cards, and toggles must update their visual state and
```
aria-selected
```
,
```
aria-pressed
```
, or
```
aria-current
```
value when the user changes selection. Do not hard-code the first item as active unless it is the only possible state.
Make interactive controls discoverable and reversible. Sliders, toggles, filters, and editors should have labels and reset behavior when helpful.
For comparisons, keep options aligned so the reader can compare the same dimension across choices.
For reports and reviews, put the conclusion, recommendation, or highest-priority findings near the top.
For diagrams, add labels, legends, and short explanations near the visual rather than burying them below.
For diagrams, prefer lane-based or layered layouts with orthogonal or clearly routed arrows. Avoid crossing arrows; if crossings appear in a screenshot, redesign the layout rather than accepting it.
For decks, use one
```
<section>
```
per slide and keyboard navigation.
For design references and figure sheets, include copy controls for tokens, SVG, code, or parameters.
For code examples, prefer tabbed examples, collapsible detail, annotated snippets, or diff blocks over plain fenced-code styling. Code samples should feel like first-class artifacts.
Code blocks must remain readable: style inline code with
```
:not(pre) > code
```
, never a bare
```
code
```
selector, and reset
```
pre code
```
to transparent background, no border, inherited block color, inherited monospace font, and preserved whitespace.
Code blocks should include offline syntax highlighting by default. Use semantic token spans or a small inline highlighter for common languages such as JSON, shell, HTML, CSS, JavaScript, TypeScript, and diffs. Do not depend on CDN highlighters or leave substantial code blocks monochrome.
For long artifacts, add jump links, tabs, filters, or collapsible sections instead of making the user scroll through a wall.

默认使用一个自包含的
```
.html
```
文件。

包含

<!doctype html>

、

<html lang="en">

、

<meta charset="utf-8">

、viewport meta 标签和有意义的

<title>

。

将 CSS 放在
```
<style>
```
块中，将 JavaScript 放在
```
<script>
```
块中。交付物不应依赖 bundler、软件包安装或构建步骤。
默认支持离线运行。交付物的渲染不应依赖网络请求、远程字体、CDN 脚本或外部样式表。必要时使用内联 SVG、内嵌数据和 data URI。
优先采用语义化 HTML：在适用处使用
```
header
```
、
```
main
```
、
```
section
```
、
```
article
```
、
```
nav
```
、
```
aside
```
、
```
table
```
、
```
details
```
、
```
button
```
、
```
label
```
和表单控件。
可以自由使用内联 SVG、canvas、CSS 和原生控件，以提升交付物的清晰度。
页面应具备响应式能力。在窄屏上保持可读，且不得产生页面级横向滚动。只有代码块、密集表格和大型图表等受限区域可以有意进行横向滚动。
Chip 风格的 UI 必须换行，而不是横向滚动。这包括跳转链接、筛选 chip、分段控件、徽章、按钮组、标签行和图例。绝不能将这些控件隐藏在横向滚动区域中。
无论长 token 出现在正文、提示框、徽章、单元格还是行内代码中，都要强制其换行。本地路径、URL、分支名、hash、命令和长标识符不得撑宽整个页面。
不要使用视口单位设置文字大小。使用明确的尺寸配合 media query 断点，确保标题和标签能够稳定适配。
使用清晰的层级和紧凑、便于扫读的布局。不要用没有实际意义的装饰性外壳填满页面。
样式优先级依次为：源样式或项目样式、明确要求使用的已保存主题、已保存的默认主题或明显匹配的主题，最后是回退主题。
声称使用了源样式或项目样式时，交付物必须有具体样式证据作为支撑，例如 CSS 变量、theme config、UI 组件源文件、本地截图或产品页面。源内容本身不能作为源样式的依据。
找不到源样式证据时，直接使用
```
themes/fallback-theme.md
```
。不要创建中性浅色仪表盘、通用文档 UI 或模型自行臆造的配色来代替回退主题。
在交付物中加入简洁的样式来源说明，通常放在页脚或来源/证据区块中：注明所使用的源文件或 token、已保存主题或回退主题。
让状态清晰可见。选中的标签页、启用的筛选器、已更改的值、警告和建议应一目了然。
选择状态必须真实有效。标签页、chip、筛选器、分段控件、导航 pill、选中的卡片和开关，都必须在用户更改选择时更新视觉状态，以及
```
aria-selected
```
、
```
aria-pressed
```
或
```
aria-current
```
值。除非第一项是唯一可能的状态，否则不要将其硬编码为选中状态。
交互控件应易于发现且操作可逆。滑块、开关、筛选器和编辑器应带有标签，并在有帮助时提供重置功能。
对于对比内容，保持各选项对齐，以便读者对相同维度进行比较。
对于报告和评审，将结论、建议或优先级最高的问题放在顶部附近。
对于图表，在视觉元素附近添加标签、图例和简短解释，不要将其埋在下方。
对于图表，优先采用泳道式或分层布局，并使用正交箭头或路径清晰的箭头。避免箭头交叉；如果截图中出现交叉，应重新设计布局，而不是接受这种效果。
对于演示文稿，每张幻灯片使用一个
```
<section>
```
，并提供键盘导航。
对于设计参考和图形规格表，提供复制 token、SVG、代码或参数的功能。
对于代码示例，优先使用标签页示例、可折叠详情、带注释的代码片段或 diff 块，而不是普通围栏代码样式。代码示例应像其他一等交付物一样受到重视。
代码块必须保持可读：使用
```
:not(pre) > code
```
设置行内代码样式，不要使用裸
```
code
```
选择器；将
```
pre code
```
重置为透明背景、无边框、继承代码块文字颜色、继承等宽字体并保留空白字符。
代码块默认应包含离线语法高亮。对于 JSON、shell、HTML、CSS、JavaScript、TypeScript 和 diff 等常见语言，使用语义化 token span 或小型内联高亮器。不要依赖 CDN 高亮器，也不要让大段代码块保持单色。
对于长交付物，添加跳转链接、标签页、筛选器或可折叠区块，避免让用户滚动浏览大段连续内容。

When Plain Chat Is Enough

何时普通聊天已经足够

Stay out of HTML only when the response is genuinely small or the user asked for a different format:

A short conversational answer.
A command or terminal-style response.
A single code snippet or config block.
A quick list that the reader will scan once.
An explicit request for Markdown, JSON, plain text, or another format.

If the output starts becoming a document, switch to HTML.

仅在回复确实很短，或用户要求其他格式时，才使用普通聊天而非 HTML：

简短对话式回答。
命令或终端风格回复。
单段代码片段或配置块。
读者只需浏览一遍的简短列表。
明确要求使用 Markdown、JSON、纯文本或其他格式。

如果输出开始演变成文档，就切换到 HTML。

Artifact Families

交付物类型

Common outputs this skill should create:

Option comparison pages with aligned tradeoffs and a recommendation.
Implementation plans with milestones, data flow, key code, risks, and open questions.
PR or code review pages with annotated diffs, severity labels, and reviewer focus areas.
Module maps and architecture explainers with boxes, arrows, call paths, and entry points.
Design system references with colors, type, spacing, components, states, and copyable tokens.
Component variant sheets showing every state, size, intent, and edge case.
Animation or interaction prototypes with live controls and exported parameters.
Flowcharts, timelines, process maps, and SVG figure sheets.
Research or learning explainers with tabs, collapsible sections, glossary, diagrams, and live demos.
Status reports and incident reports with metric cards, timelines, impact, root cause, and action items.
Slide decks implemented as HTML sections with keyboard navigation.
Custom editors for triage, prioritization, config, prompts, datasets, annotations, copy, and structured content.

此 skill 应创建的常见输出：

带有对齐的利弊分析和推荐结论的选项对比页面。
包含里程碑、数据流、关键代码、风险和开放问题的实施计划。
带有注释 diff、严重程度标签和评审关注点的 PR 或代码评审页面。
包含方框、箭头、调用路径和入口点的模块地图与架构讲解。
包含颜色、字体、间距、组件、状态和可复制 token 的设计系统参考。
展示所有状态、尺寸、意图和边界情况的组件变体表。
带实时控件和可导出参数的动画或交互原型。
流程图、时间线、流程映射图和 SVG 图形规格表。
包含标签页、可折叠区块、术语表、图表和实时演示的研究或学习讲解。
包含指标卡、时间线、影响、根因和行动项的状态报告与事故报告。
以 HTML section 实现并带键盘导航的幻灯片演示文稿。
用于分诊、优先级排序、配置、提示词、数据集、注释、复制和结构化内容的自定义编辑器。

Output Conventions

输出约定

When creating a file, use a short descriptive filename such as:

```
implementation-plan.html
```
```
pr-review.html
```
```
module-map.html
```
```
concept-explainer.html
```
```
incident-report.html
```
```
triage-editor.html
```
```
prompt-tuner.html
```

When returning the artifact, mention what was created and where it is. Keep the chat response brief; the HTML page is the deliverable.

When returning a hosted preview, also state the Pagedrop route, whether the URL is revision-pinned, and that it persists until the backing Gist is deleted. Keep the local

.html

file as the canonical artifact.

创建文件时，使用简短且具有描述性的文件名，例如：

```
implementation-plan.html
```
```
pr-review.html
```
```
module-map.html
```
```
concept-explainer.html
```
```
incident-report.html
```
```
triage-editor.html
```
```
prompt-tuner.html
```

返回交付物时，说明创建了什么以及文件位置。聊天回复应保持简短；HTML 页面才是交付物。

返回托管预览时，还要说明 Pagedrop 路由、URL 是否固定到修订版本，以及它会持续存在直到底层 Gist 被删除。将本地

.html

文件保留为规范版本。