create-design-md

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Create DESIGN.md

创建DESIGN.md

Create a

DESIGN.md

for one product or coherent website. Record the design language that governs it, not every value that happens to exist.

为单个产品或连贯的网站创建

DESIGN.md

文档。记录主导产品的设计语言，而非所有实际存在的细节值。

Boundaries

边界规则

Modify only
```
DESIGN.md
```
. Do not change product source, dependencies, configuration, or generated files.
Use the DESIGN.md format contract below. Do not invent a competing schema.
Do not copy every discovered token or component into the document.
Do not convert repetition, local styling, or visual preference into product intent.

仅修改
```
DESIGN.md
```
。请勿更改产品源代码、依赖项、配置文件或生成文件。
使用下方的DESIGN.md格式约定。请勿自创冲突性的架构。
请勿将所有发现的令牌或组件复制到文档中。
请勿将重复出现的内容、局部样式或视觉偏好转化为产品设计意图。

1. Choose the mode

1. 选择工作模式

Repository mode

仓库模式

Use when a local product repository is available. Create or update

DESIGN.md

at the root of the selected product.

If the repository contains multiple deployable products, select the one named by the user. If the request does not identify one and ownership is ambiguous, ask before writing.

Repository evidence may establish normative values, token names, component ownership, and documented rationale.

当本地产品仓库可用时使用此模式。在所选产品的根目录创建或更新

DESIGN.md

。

如果仓库包含多个可部署产品，请选择用户指定的产品。若请求未明确指定且归属模糊，请先询问再进行编写。

仓库中的素材可确立标准值、令牌名称、组件归属及已记录的设计依据。

URL mode

URL模式

Use when the user provides a public URL without its source repository. Create a reconstructed

DESIGN.md

draft in the current workspace.

URL mode requires rendered browser access. Inspect the DOM, computed styles, and publicly loaded stylesheets at desktop and mobile widths. Screenshots may support interpretation but cannot establish exact values by themselves.

Inspect the supplied page and shared chrome. For a site-wide request, sample up to three same-origin pages that represent distinct templates.

URL evidence may establish only observable visual patterns and computed values. It cannot establish internal token names, component ownership, undocumented rationale, or whether a pattern is intentionally canonical.

If rendered inspection is unavailable, ask for screenshots or source files. Do not create a DESIGN.md from copy, metadata, or HTML structure alone.

Choose repository mode whenever source is available. A supplied URL may verify rendered presentation but does not replace repository evidence.

当用户提供无源代码仓库的公共URL时使用此模式。在当前工作区创建一份重构后的

DESIGN.md

草稿。

URL模式需要浏览器渲染访问。在桌面和移动端宽度下检查DOM、计算样式及公开加载的样式表。截图可辅助解读，但无法单独确定精确值。

检查提供的页面及共享的浏览器界面元素。若为全站请求，最多采样三个代表不同模板的同源页面。

URL素材仅能确立可观察的视觉模式和计算值，无法确定内部令牌名称、组件归属、未记录的设计依据，或某一模式是否为有意设定的规范。

若无法进行渲染检查，请请求提供截图或源文件。请勿仅通过文本内容、元数据或HTML结构创建DESIGN.md。

只要源代码可用，优先选择仓库模式。提供的URL可用于验证渲染效果，但无法替代仓库中的素材。

Shared evidence pipeline

共享素材处理流程

The modes differ only in how they collect evidence. They must use the same record and output pipeline:

text

role → value → source → scope → recurrence → confidence

Collect evidence using the selected mode.
Record the source, scope, and recurrence for each candidate.
Normalize candidates into the DESIGN.md schema.
Omit candidates that are uncertain, local without a contract, or not implementation-relevant.
Validate frontmatter shape and export compatibility.
Write Markdown only after the normalized frontmatter passes.

Never let repository or URL evidence introduce a second token schema. The same flat token names, mapping-shaped typography, omission rules, and export gates apply to both modes.

The generated document is private until validation passes. Never return, display, or summarize a DESIGN.md draft before lint and export succeed. If validation reports an invalid shape or missing export category, rewrite the frontmatter and rerun; if the category cannot be repaired, remove it and report it as omitted.

两种模式仅在素材收集方式上有所不同，必须使用相同的记录和输出流程：

text

role → value → source → scope → recurrence → confidence

使用所选模式收集素材。
为每个候选项记录来源、范围和重复出现情况。
将候选项标准化为DESIGN.md架构格式。
剔除不确定、无约定的局部内容或与实现无关的候选项。
验证frontmatter的格式及导出兼容性。
仅在标准化后的frontmatter通过验证后，再编写Markdown内容。

绝不能让仓库或URL素材引入第二种令牌架构。两种模式均需使用相同的扁平化令牌名称、映射型排版规则、剔除规则及导出限制。

生成的文档在验证通过前为私有状态。在lint检查和导出成功前，绝不要返回、展示或总结DESIGN.md草稿。若验证报告格式无效或缺少导出分类，请重写frontmatter并重新运行验证；若分类无法修复，则移除该分类并报告已省略。

2. Trace the evidence

2. 追踪素材

In repository mode, inspect in this order:

Existing
```
DESIGN.md
```
and explicit repository guidance
Tokens, themes, variables, and global styles
Shared primitives and their variants
Representative routes and rendered consumers
Surface-local implementations

A source participates only when the selected product imports, references, inherits, or renders it. Exclude proposals, migrations, examples, generated outputs, legacy implementations, and similarly named packages unless the selected product uses them.

In URL mode, sample representative elements for:

colors and surface roles
typography roles
spacing and layout
borders, radii, and elevation
navigation, buttons, inputs, cards, and repeated content structures
desktop and mobile presentation

Prefer computed values and loaded CSS declarations over visual estimation.

Before drafting URL-mode prose or YAML, build a private evidence ledger for each sampled page and viewport. For each candidate, record: page, viewport, element role, computed property/value, and the matching loaded-CSS declaration or custom property when available. Inspect the public stylesheets loaded by the page, including custom properties and media-query rules; a stylesheet value is usable only when it is connected to a rendered element or recurs across the sampled pages.

Promote a URL value into DESIGN.md when either (a) the rendered computed value and a loaded declaration/custom property agree, or (b) the same computed value recurs for the same role across the required samples. If neither condition holds, omit the value. You may preserve an exposed custom-property name only when its declaration and rendered use are directly observable; do not invent semantic aliases from a raw value.

For every URL-mode claim, require all three proofs before writing it:

Observation: the pattern or value is visible or computed on the rendered page.
Basis: it is measured, or recurs across the required sampled pages/viewports.
Consequence: it changes a concrete implementation choice in DESIGN.md.

If any proof is missing, omit the claim. Do not turn a visual impression into a token, a single occurrence into a site-wide rule, or a guessed value into YAML. Exact values require computed styles or loaded CSS; otherwise describe the role without a value or omit it.

在仓库模式下，按以下顺序检查：

现有
```
DESIGN.md
```
及明确的仓库指导规范
设计令牌、主题、变量及全局样式
共享基础组件及其变体
具有代表性的路由及渲染后的消费组件
局部界面的实现

只有当所选产品导入、引用、继承或渲染某一资源时，该资源才纳入考虑范围。排除提案、迁移文件、示例、生成输出、遗留实现及同名但未被所选产品使用的包。

在URL模式下，针对以下元素采样代表性示例：

颜色及界面角色
排版角色
间距与布局
边框、圆角及层级
导航、按钮、输入框、卡片及重复出现的内容结构
桌面端与移动端展示效果

优先使用计算值和加载的CSS声明，而非视觉估算。

在编写URL模式的 prose 内容或YAML前，为每个采样页面和视口建立私有素材台账。针对每个候选项，记录：页面、视口、元素角色、计算属性/值，以及可用时匹配的已加载CSS声明或自定义属性。检查页面加载的公开样式表，包括自定义属性和媒体查询规则；只有当样式表中的值与渲染元素关联，或在采样页面中重复出现时，该值才可使用。

当满足以下任一条件时，可将URL中的值纳入DESIGN.md：(a) 渲染后的计算值与已加载的声明/自定义属性一致；(b) 同一角色的相同计算值在所需采样中重复出现。若两个条件均不满足，则剔除该值。仅当自定义属性的声明和渲染使用可直接观察时，才可保留其名称；请勿从原始值中自创语义别名。

对于URL模式下的每一项内容，必须满足以下三个证明条件才可写入：

可观察性：该模式或值在渲染页面上可见或可通过计算得到。
依据性：可被测量，或在所需采样页面/视口中重复出现。
影响性：会改变DESIGN.md中的具体实现选择。

若任一证明条件缺失，则剔除该项内容。请勿将视觉印象转化为令牌，将单次出现的内容转化为全站规则，或将猜测值写入YAML。精确值需要计算样式或已加载的CSS；否则仅描述角色而不指定值，或直接剔除。

3. Decide what belongs

3. 确定内容范围

In repository mode, find explicit product intent or a design reference before describing product character. In URL mode, do not invent product character; the Overview may state only the site's observable purpose and presentation, and must identify the document as reconstructed.

Write YAML only from named shared tokens and roles in governing sources. Do not turn utility classes, repeated literals, or component values into token scales.

Treat frontmatter shape as a hard gate, not a stylistic choice: a value that is a token group must be a mapping whose children are the schema's fields. Never emit scalar typography entries (

sans: Geist

), arbitrary nested source objects (

font-family: { mono: ... }

), or rounded keys copied from CSS variable names (

radius-sm

radius-md

, etc.).

Use mappings, never sequences, for token groups. When a governing source defines one group-level token such as

--radius

, normalize it to

base

; otherwise preserve the source token names.

Map source values into DESIGN.md schema fields. Preserve semantic token names, not source object nesting. For example, write

typography.mono.fontFamily: Geist Mono

, never

typography.mono: Geist Mono

; write

rounded.base: 0.625rem

when the source has only

--radius

, never

rounded.radius

or derived radius steps.

Resolve framework utilities through the active theme or configuration before writing exact values.

Identify the repository's export target before writing frontmatter:

css-tailwind

for Tailwind v4,

json-tailwind

for Tailwind v3, and

dtcg

otherwise. Token names must be valid for that target.

Check the installed DESIGN.md specification before encoding theme modes:

bash

npx @google/design.md spec

If the specification supports

themes

and

default-theme

, use its theme-aware token syntax. Otherwise, put the default-theme value under each canonical semantic token and preserve exact alternate-theme values in a

## Themes

table. Do not create parallel

-light

and

-dark

token names, discard alternate-theme values, or use unreleased syntax. A fallback Themes table is documentation only; do not pretend it makes the frontmatter theme-aware.

In repository mode, every prose rule must be supported by explicit guidance, a named shared token or variant, or a shared owner used by at least two audited surfaces. Otherwise omit it.

In URL mode, every prose rule must be directly observable. A site-wide rule must recur across at least two sampled templates; otherwise scope it to the inspected page. Use reconstructed role-based names and label the document as a draft.

URL-mode YAML is intentionally sparse, but not empty when measured evidence exists. Add a category when at least one supported value or role survives the three-proof gate. Colors may use computed values or verified public custom properties, but must remain flat and export-safe; typography must use canonical fields such as

fontFamily

fontSize

lineHeight

, and

fontWeight

; rounded and spacing values must come from computed styles or loaded declarations. Do not create aliases such as

primary

elevated

, or

display

merely to organize observations. A component section requires the same interaction or surface treatment to recur across at least two sampled pages and to change a concrete implementation choice.

URL reconstruction does not change the frontmatter schema. Use only these typography property names:

fontFamily

fontSize

lineHeight

fontWeight

, and

letterSpacing

. For example:

yaml

typography:
  sans:
    fontFamily: Inter Variable
  display:
    fontFamily: Inter Variable
    fontSize: 64px
    lineHeight: 64px
    fontWeight: 510

Never emit URL-specific aliases such as

family

size

weight

mobile-display

, or nested

sans

mono

values inside a typography scale. Reconstructed role names may vary; schema field names may not.

For URL output, use

css-tailwind

as the compatibility export target unless the user specifies another target. Flatten reconstructed color roles into valid token names. Use

background-primary

foreground-secondary

, or

border-muted

, not nested keys such as

background.primary

foreground.secondary

. Every emitted token name must match

^[a-zA-Z0-9][a-zA-Z0-9-]*$

; reject and rewrite any key that would fail this test.

Normalize URL frontmatter before writing any Markdown. The order is: collect evidence, choose the export target, map evidence into the canonical schema, reject invalid shapes, then write the document. Never draft prose first and retrofit the YAML afterward.

URL frontmatter must satisfy these shape rules:

```
colors
```
is a flat mapping of valid token names to values.
```
typography
```
is a mapping of named scales; each scale is a mapping using only canonical fields.
```
rounded
```
and
```
spacing
```
are flat mappings of valid token names to values.
```
components
```
may reference canonical token paths but may not introduce a second token schema.

If normalization would require inventing a token name, field, scale, or semantic relationship, omit the candidate.

Outside the Overview, every Markdown sentence must change an implementation choice. Delete component inventories, generic design advice, and prose that only restates YAML.

Preserve the scope and direction of every rule. When implementation conflicts with explicit guidance, document the guidance and report the conflict outside

DESIGN.md

在仓库模式下，在描述产品特性前，需先找到明确的产品意图或设计参考。在URL模式下，请勿自创产品特性；概述部分仅可说明网站的可观察用途及展示效果，且必须注明文档为重构版本。

仅根据主导资源中的命名共享令牌和角色编写YAML。请勿将工具类、重复字面量或组件值转化为令牌刻度。

将frontmatter格式视为硬性要求，而非风格选择：属于令牌组的值必须是包含架构字段的映射。绝不要输出标量排版条目（

sans: Geist

）、任意嵌套的源对象（

font-family: { mono: ... }

）或从CSS变量名复制的圆角键（

radius-sm

radius-md

等）。

对令牌组使用映射，而非序列。若主导资源定义了一个组级令牌（如

--radius

），则将其标准化为

base

；否则保留源令牌名称。

将源值映射到DESIGN.md架构字段。保留语义令牌名称，而非源对象的嵌套结构。例如，应编写

typography.mono.fontFamily: Geist Mono

，而非

typography.mono: Geist Mono

；当源中仅有

--radius

时，应编写

rounded.base: 0.625rem

，而非

rounded.radius

或派生的圆角步骤。

在写入精确值前，需通过活动主题或配置解析框架工具类。

在编写frontmatter前，确定仓库的导出目标：Tailwind v4使用

css-tailwind

，Tailwind v3使用

json-tailwind

，其他情况使用

dtcg

。令牌名称必须符合目标的要求。

在编码主题模式前，检查已安装的DESIGN.md规范：

bash

npx @google/design.md spec

若规范支持

themes

和

default-theme

，则使用其支持主题的令牌语法。否则，将默认主题的值放在每个标准语义令牌下，并将精确的备用主题值保留在

## Themes

表格中。请勿创建并行的

-light

和

-dark

令牌名称，不要丢弃备用主题值，也不要使用未发布的语法。备用的Themes表格仅用于文档记录；请勿假装它使frontmatter支持主题。

在仓库模式下，每一条 prose 规则必须有明确的指导规范、命名共享令牌或变体，或至少两个被审计界面使用的共享所有者作为支撑。否则剔除该规则。

在URL模式下，每一条 prose 规则必须可直接观察。全站规则必须在至少两个采样模板中重复出现；否则将其范围限定在已检查的页面。使用重构的基于角色的名称，并将文档标记为草稿。

URL模式下的YAML应刻意精简，但当存在可测量素材时不可为空。当至少一个支持的值或角色通过三证明条件时，添加对应的分类。颜色可使用计算值或已验证的公开自定义属性，但必须保持扁平化且可安全导出；排版必须使用标准字段，如

fontFamily

、

fontSize

、

lineHeight

和

fontWeight

；圆角和间距值必须来自计算样式或已加载的声明。请勿仅为组织观察结果而创建

primary

、

elevated

或

display

等别名。组件部分要求相同的交互或界面处理在至少两个采样页面中重复出现，且会改变具体的实现选择。

URL重构不会改变frontmatter架构。仅使用以下排版属性名称：

fontFamily

、

fontSize

、

lineHeight

、

fontWeight

和

letterSpacing

。例如：

yaml

typography:
  sans:
    fontFamily: Inter Variable
  display:
    fontFamily: Inter Variable
    fontSize: 64px
    lineHeight: 64px
    fontWeight: 510

绝不要输出URL特有的别名，如

family

、

size

、

weight

、

mobile-display

，或排版刻度内嵌套的

sans

mono

值。重构的角色名称可有所不同；但架构字段名称不可更改。

对于URL输出，除非用户指定其他目标，否则使用

css-tailwind

作为兼容性导出目标。将重构的颜色角色扁平化为有效的令牌名称。使用

background-primary

、

foreground-secondary

或

border-muted

，而非

background.primary

或

foreground.secondary

等嵌套键。每个输出的令牌名称必须匹配

^[a-zA-Z0-9][a-zA-Z0-9-]*$

；拒绝并重写任何不符合该规则的键。

在编写任何Markdown内容前，先标准化URL的frontmatter。顺序为：收集素材、选择导出目标、将素材映射到标准架构、剔除无效格式，然后编写文档。绝不要先编写prose内容再事后调整YAML。

URL的frontmatter必须满足以下格式规则：

```
colors
```
是有效令牌名称到值的扁平映射。
```
typography
```
是命名刻度的映射；每个刻度是仅使用标准字段的映射。
```
rounded
```
和
```
spacing
```
是有效令牌名称到值的扁平映射。
```
components
```
可引用标准令牌路径，但不可引入第二种令牌架构。

若标准化需要自创令牌名称、字段、刻度或语义关系，则剔除该候选项。

除概述外，每一句Markdown内容必须改变实现选择。删除组件清单、通用设计建议及仅重述YAML内容的prose。

保留每条规则的范围和方向。当实现与明确的指导规范冲突时，记录指导规范并在

DESIGN.md

外报告冲突。

4. Write the document

4. 编写文档

Start with the smallest valid frontmatter:

yaml

---
version: alpha
name: <string>
description: <string>
---

Only

name

is required. Add

colors

typography

rounded

spacing

, or

components

only when a governing source already defines that named system or contract. Do not create token names to organize implementation values. Token references use

{path.to.token}

Use schema-shaped mappings, not copied source nesting. A typography scale is always named and maps its properties beneath it:

yaml

typography:
  sans:
    fontFamily: Geist
  mono:
    fontFamily: Geist Mono

If the source defines only

--radius

, write

rounded.base

, not

rounded.radius

; do not derive

sm

md

lg

, or

xl

from utility classes or repeated values. Before saving, inspect the parsed frontmatter and reject it yourself if any

typography

child is scalar or if

rounded

contains keys not present in the governing source.

Start with

## Overview

. State only the product's purpose and evidenced design direction. Do not summarize pages, components, tokens, or implementation. Add only supported sections from this order:

Colors
Themes
Typography
Layout
Elevation & Depth
Shapes
Components
Do's and Don'ts

Do not create a section merely because it exists in the format. Do not reorder or duplicate included sections. Add an unknown section only when supported guidance cannot fit a standard section.

Markdown records design intent and application guidance. Except for the fallback

## Themes

table, do not put token inventories, component configuration, source syntax, or documentation methodology in Markdown.

Include a Don't only when a governing source states an explicit prohibition.

Put exact normative values in YAML frontmatter, except alternate-theme values when the installed specification cannot represent modes.
Put supported rationale and application guidance in Markdown.
Preserve accepted decisions from an existing
```
DESIGN.md
```
unless the user or current governing evidence replaces them.
Do not invent brand personality, audience, or emotional rationale.
Do not include citations, audit notes, rejected candidates, conflicts, or unresolved questions inside
```
DESIGN.md
```
.

Before saving, delete:

any YAML token not already named by a governing source
any page-local behavior presented as a product-wide rule
any implementation pattern that conflicts with explicit guidance
any prohibition not explicitly stated
any exact implementation value outside YAML frontmatter or the fallback
```
## Themes
```
table
any component configuration or documentation methodology in Markdown
any sentence that does not change the resulting DESIGN.md

Run one final no-op pass: remove vague advice such as “be thorough,” “keep it polished,” or “use good judgment.” Keep only evidence gates, schema constraints, or application rules that change the document.

从最小的有效frontmatter开始：

yaml

---
version: alpha
name: <string>
description: <string>
---

仅

name

为必填项。仅当主导资源已定义对应的命名系统或约定时，才添加

colors

、

typography

、

rounded

、

spacing

或

components

。请勿为组织实现值而创建令牌名称。令牌引用使用

{path.to.token}

。

使用架构形状的映射，而非复制源的嵌套结构。排版刻度始终有名称，并将其属性映射在下方：

yaml

typography:
  sans:
    fontFamily: Geist
  mono:
    fontFamily: Geist Mono

若源仅定义了

--radius

，则编写

rounded.base

，而非

rounded.radius

；请勿从工具类或重复值中派生

sm

、

md

、

lg

或

xl

。保存前，检查解析后的frontmatter，若

typography

的子项为标量，或

rounded

包含主导资源中不存在的键，则自行拒绝该内容。

从

## Overview

开始。仅说明产品的用途及已证实的设计方向。请勿总结页面、组件、令牌或实现。仅按以下顺序添加受支持的章节：

Colors
Themes
Typography
Layout
Elevation & Depth
Shapes
Components
Do's and Don'ts

请勿仅因格式中存在某章节就创建该章节。请勿重新排序或重复已包含的章节。仅当受支持的指导规范无法适配标准章节时，才添加未知章节。

Markdown记录设计意图和应用指导规范。除备用的

## Themes

表格外，请勿在Markdown中放入令牌清单、组件配置、源语法或文档方法论。

仅当主导资源明确禁止时，才添加“Don't”项。

将精确的标准值放入YAML frontmatter，除非已安装的规范无法表示模式时的备用主题值。
将受支持的设计依据和应用指导规范放入Markdown。
保留现有
```
DESIGN.md
```
中已被接受的决策，除非用户或当前主导素材替换它们。
请勿自创品牌个性、受众或情感设计依据。
请勿在
```
DESIGN.md
```
中放入引用、审计笔记、被拒绝的候选项、冲突或未解决的问题。

保存前，删除以下内容：

任何主导资源未命名的YAML令牌
任何被表述为产品全站规则的页面局部行为
任何与明确指导规范冲突的实现模式
任何未明确说明的禁止项
任何YAML frontmatter或备用
```
## Themes
```
表格外的精确实现值
Markdown中的任何组件配置或文档方法论
任何不会改变最终DESIGN.md的语句

运行最后一次无操作检查：删除模糊建议，如“务必全面”、“保持简洁”或“合理判断”。仅保留会改变文档的素材规则、架构约束或应用规则。

5. Validate

5. 验证

Run structural linting:

bash

npx @google/design.md lint DESIGN.md

Then run one compatibility export using the target selected above:

bash

npx @google/design.md export --format <format> DESIGN.md

Inspect the output. Every populated frontmatter category supported by the target must emit its corresponding token category; an empty or missing category is a schema failure even when the command exits successfully. Rewrite the frontmatter and rerun validation until the category is emitted, unless the target genuinely cannot represent it. Do not report success while any populated category is missing from the export. Do not return the document while lint or export fails. Do not remove supported design information solely to satisfy an exporter limitation; report that limitation instead. Do not create or retain exported files.

For

css-tailwind

, verify these output families:

colors

→

--color-*

typography.<name>.fontFamily

→

--font-*

typography.<name>.fontSize

→

--text-*

rounded

→

--radius-*

, and

spacing

→

--spacing-*

. Typography entries are named scales; put

fontFamily

fontSize

, and

lineHeight

inside each scale, never under arbitrary source nesting such as

font-family

. If

typography

is populated but the export contains neither

--font-*

nor

--text-*

, the document is invalid and must be rewritten before reporting.

When updating an existing document, preserve its original contents temporarily and run:

bash

npx @google/design.md diff <previous-file> DESIGN.md

Restore any removed accepted decision unless current governing evidence or the user explicitly replaces it.

运行结构lint检查：

bash

npx @google/design.md lint DESIGN.md

然后使用上述选择的目标运行一次兼容性导出：

bash

npx @google/design.md export --format <format> DESIGN.md

检查输出结果。目标支持的每个已填充frontmatter分类必须输出对应的令牌分类；即使命令成功退出，空分类或缺失分类也属于架构失败。重写frontmatter并重新运行验证，直到分类被输出，除非目标确实无法表示该分类。当任何已填充分类未出现在导出结果中时，请勿报告成功。当lint或导出失败时，请勿返回文档。请勿仅为满足导出器限制而删除受支持的设计信息；相反，应报告该限制。请勿创建或保留导出文件。

对于

css-tailwind

，验证以下输出族：

colors

→

--color-*

，

typography.<name>.fontFamily

→

--font-*

，

typography.<name>.fontSize

→

--text-*

，

rounded

→

--radius-*

，

spacing

→

--spacing-*

。排版条目为命名刻度；将

fontFamily

、

fontSize

和

lineHeight

放入每个刻度内，而非

font-family

等任意源嵌套结构。若

typography

已填充，但导出结果中既无

--font-*

也无

--text-*

，则文档无效，必须重写后再报告。

当更新现有文档时，临时保留其原始内容并运行：

bash

npx @google/design.md diff <previous-file> DESIGN.md

恢复任何被移除的已接受决策，除非当前主导素材或用户明确替换它们。

6. Report

6. 报告

Return:

mode and audited product or URL
created or updated
```
DESIGN.md
```
governing sources used
conflicts or unsupported areas omitted from the document
final lint and export results

In URL mode, label the output as a reconstructed draft.

返回以下内容：

工作模式及审计的产品或URL
创建或更新后的
```
DESIGN.md
```
使用的主导资源
文档中省略的冲突或不受支持的区域
最终的lint和导出结果

在URL模式下，将输出标记为重构草稿。