Publish DESIGN.md生成器 skill to marketplace
Constraint: Public skills are published only by explicit administrator action unless they are tracked third-party market sources. Confidence: high Scope-risk: narrow Directive: Keep private/internal skills out of the public marketplace and preserve normal incremental market Git history. Tested: Marketplace validation passed.
This commit is contained in:
KeyInfo Bot
@@ -315,6 +315,18 @@
|
||||
"authentication": "ON_INSTALL"
|
||||
},
|
||||
"category": "MCP"
|
||||
},
|
||||
{
|
||||
"name": "design-md",
|
||||
"source": {
|
||||
"source": "local",
|
||||
"path": "./plugins/design-md"
|
||||
},
|
||||
"policy": {
|
||||
"installation": "AVAILABLE",
|
||||
"authentication": "ON_INSTALL"
|
||||
},
|
||||
"category": "知识库与检索"
|
||||
}
|
||||
]
|
||||
}
|
||||
|
||||
@@ -0,0 +1,39 @@
|
||||
{
|
||||
"name": "design-md",
|
||||
"version": "0.1.0",
|
||||
"description": "创建、编辑、验证、比较、导出及应用 Google Labs DESIGN.md 文件，从而构建可供人工智能读取的规范化设计系统。",
|
||||
"author": {
|
||||
"name": "EAPIL",
|
||||
"url": "https://git.playones.com/arechen/EapilSkillMarket"
|
||||
},
|
||||
"homepage": "https://git.playones.com/arechen/EapilSkillMarket",
|
||||
"repository": "https://git.playones.com/arechen/EapilSkillMarket",
|
||||
"license": "Proprietary",
|
||||
"keywords": [
|
||||
"eapil",
|
||||
"codex-skill",
|
||||
"design-md"
|
||||
],
|
||||
"skills": "./skills/",
|
||||
"interface": {
|
||||
"displayName": "DESIGN.md生成器",
|
||||
"shortDescription": "创建、编辑、验证、比较、导出及应用 Google Labs DESIGN.md 文件，从而构建可供人工智能读取的规范化设计系统。",
|
||||
"longDescription": "创建、编辑、验证、比较、导出及应用 Google Labs DESIGN.md 文件，从而构建可供人工智能读取的规范化设计系统。",
|
||||
"developerName": "EAPIL",
|
||||
"category": "知识库与检索",
|
||||
"capabilities": [
|
||||
"Read",
|
||||
"Write"
|
||||
],
|
||||
"defaultPrompt": [
|
||||
"使用 DESIGN.md生成器 帮我完成这个任务。"
|
||||
],
|
||||
"websiteURL": "https://git.playones.com/arechen/EapilSkillMarket",
|
||||
"privacyPolicyURL": "https://git.playones.com/arechen/EapilSkillMarket",
|
||||
"termsOfServiceURL": "https://git.playones.com/arechen/EapilSkillMarket",
|
||||
"brandColor": "#2563EB",
|
||||
"screenshots": [],
|
||||
"composerIcon": "./assets/market-icon.svg",
|
||||
"logo": "./assets/market-icon.svg"
|
||||
}
|
||||
}
|
||||
@@ -0,0 +1 @@
|
||||
<svg xmlns="http://www.w3.org/2000/svg" width="360" height="360" viewBox="0 0 32 32"><title>DESIGN.md生成器</title><g fill="none"><path fill="url(#SVGklx3zJXo)" d="M7.5 3A4.5 4.5 0 0 0 3 7.5v17A4.5 4.5 0 0 0 7.5 29h17a4.5 4.5 0 0 0 4.5-4.5v-17A4.5 4.5 0 0 0 24.5 3z"/><path fill="url(#SVGxO13MgXq)" d="M7.5 3A4.5 4.5 0 0 0 3 7.5v17A4.5 4.5 0 0 0 7.5 29h17a4.5 4.5 0 0 0 4.5-4.5v-17A4.5 4.5 0 0 0 24.5 3z"/><path fill="url(#SVGxluVFb5q)" d="M7.5 3A4.5 4.5 0 0 0 3 7.5v17A4.5 4.5 0 0 0 7.5 29h17a4.5 4.5 0 0 0 4.5-4.5v-17A4.5 4.5 0 0 0 24.5 3z"/><path fill="url(#SVGPD31pBoO)" d="M7.5 3A4.5 4.5 0 0 0 3 7.5v17A4.5 4.5 0 0 0 7.5 29h17a4.5 4.5 0 0 0 4.5-4.5v-17A4.5 4.5 0 0 0 24.5 3z"/><path fill="url(#SVGOvZEKcyA)" d="M7.5 3A4.5 4.5 0 0 0 3 7.5v17A4.5 4.5 0 0 0 7.5 29h17a4.5 4.5 0 0 0 4.5-4.5v-17A4.5 4.5 0 0 0 24.5 3z"/><path fill="url(#SVGdi1M5dPd)" d="M12 10.5a1.5 1.5 0 1 0-3 0a1.5 1.5 0 0 0 3 0m0 5.5a1.5 1.5 0 1 0-3 0a1.5 1.5 0 0 0 3 0m-1.5 7a1.5 1.5 0 1 0 0-3a1.5 1.5 0 0 0 0 3M14 10.5a1 1 0 0 0 1 1h7a1 1 0 1 0 0-2h-7a1 1 0 0 0-1 1m1 4.5a1 1 0 1 0 0 2h7a1 1 0 1 0 0-2zm-1 6.5a1 1 0 0 0 1 1h7a1 1 0 1 0 0-2h-7a1 1 0 0 0-1 1"/><path fill="url(#SVG2J5EFbQO)" d="m31.74 13.656l-.919-.299a1.9 1.9 0 0 1-1.199-1.197l-.298-.918a.363.363 0 0 0-.684 0l-.299.918a1.89 1.89 0 0 1-1.18 1.197l-.919.299a.363.363 0 0 0 0 .684l.919.298a1.9 1.9 0 0 1 1.198 1.202l.299.918a.363.363 0 0 0 .684 0l.299-.918a1.89 1.89 0 0 1 1.198-1.197l.919-.299a.363.363 0 0 0 0-.684z"/><path fill="url(#SVGNaWMwbPh)" d="M21.775 8.837a3.5 3.5 0 0 0-1.647-1.168l-1.684-.546a.665.665 0 0 1 0-1.254l1.684-.547a3.47 3.47 0 0 0 2.15-2.154l.014-.042l.547-1.682a.665.665 0 0 1 1.255 0l.547 1.682a3.47 3.47 0 0 0 2.198 2.196l1.683.547l.034.008a.665.665 0 0 1 0 1.254l-1.684.547a3.47 3.47 0 0 0-2.197 2.196l-.548 1.682l-.016.042a.664.664 0 0 1-1.238-.042l-.548-1.682a3.5 3.5 0 0 0-.55-1.037"/><defs><radialGradient id="SVGxO13MgXq" cx="0" cy="0" r="1" gradientTransform="matrix(-3.5 0 0 -1.74793 29 14.5)" gradientUnits="userSpaceOnUse"><stop stop-color="#4a43cb"/><stop offset="1" stop-color="#4a43cb" stop-opacity="0"/></radialGradient><radialGradient id="SVGxluVFb5q" cx="0" cy="0" r="1" gradientTransform="matrix(-7 0 0 -3.49587 23.5 7.5)" gradientUnits="userSpaceOnUse"><stop stop-color="#4a43cb"/><stop offset="1" stop-color="#4a43cb" stop-opacity="0"/></radialGradient><radialGradient id="SVGPD31pBoO" cx="0" cy="0" r="1" gradientTransform="matrix(0 6 -2.99646 0 23.5 7.5)" gradientUnits="userSpaceOnUse"><stop stop-color="#4a43cb"/><stop offset="1" stop-color="#4a43cb" stop-opacity="0"/></radialGradient><radialGradient id="SVGOvZEKcyA" cx="0" cy="0" r="1" gradientTransform="matrix(0 4 -1.99764 0 29 14.5)" gradientUnits="userSpaceOnUse"><stop stop-color="#4a43cb"/><stop offset="1" stop-color="#4a43cb" stop-opacity="0"/></radialGradient><radialGradient id="SVG2J5EFbQO" cx="0" cy="0" r="1" gradientTransform="rotate(63.379 17.2 6.887)scale(34.3364 26.737)" gradientUnits="userSpaceOnUse"><stop offset=".718" stop-color="#ffcd0f"/><stop offset=".991" stop-color="#e67505"/></radialGradient><radialGradient id="SVGNaWMwbPh" cx="0" cy="0" r="1" gradientTransform="rotate(61.2 24.745 -9.672)scale(47.2968 36.829)" gradientUnits="userSpaceOnUse"><stop offset=".698" stop-color="#ffcd0f"/><stop offset=".991" stop-color="#e67505"/></radialGradient><linearGradient id="SVGklx3zJXo" x1="3.929" x2="21.872" y1="7.875" y2="26.517" gradientUnits="userSpaceOnUse"><stop stop-color="#0fafff"/><stop offset="1" stop-color="#2764e7"/></linearGradient><linearGradient id="SVGdi1M5dPd" x1="11.692" x2="21.978" y1="10.077" y2="34.999" gradientUnits="userSpaceOnUse"><stop stop-color="#fff"/><stop offset="1" stop-color="#b3e0ff"/></linearGradient></defs></g></svg>
|
||||
|
After Width: | Height: | Size: 3.6 KiB |
@@ -0,0 +1,100 @@
|
||||
---
|
||||
name: design-md
|
||||
description: Create, edit, validate, compare, export, and apply Google Labs DESIGN.md files for AI-readable design systems. Use when the user asks to create or use DESIGN.md, convert brand/UI guidance into DESIGN.md, derive design rules from an existing app or screenshots, keep frontend implementation aligned with design tokens and prose, validate DESIGN.md with the @google/design.md CLI, or export DESIGN.md tokens to Tailwind, CSS, JSON, or DTCG formats.
|
||||
---
|
||||
|
||||
# DESIGN.md
|
||||
|
||||
Use this skill to make `DESIGN.md` a durable source of truth for a product's visual identity. A `DESIGN.md` combines exact machine-readable tokens in YAML front matter with human-readable design rationale in Markdown.
|
||||
|
||||
## Core Workflow
|
||||
|
||||
1. Locate and read any existing `DESIGN.md` before UI work. Treat it as design context for implementation, review, and refactoring.
|
||||
2. If creating one, gather concrete inputs first: existing CSS/Tailwind/theme files, component styles, screenshots, brand notes, typography choices, accessibility constraints, and target audience.
|
||||
3. Write exact tokens in YAML front matter and explain intent in prose. Tokens provide values; prose explains how to apply them.
|
||||
4. Validate with the official CLI whenever Node/npm is available. Fix errors before considering the file ready.
|
||||
5. Apply tokens and prose to implementation, then update `DESIGN.md` if the code intentionally changes the design system.
|
||||
|
||||
Read `references/design-md-reference.md` when creating, editing, validating, exporting, or applying a `DESIGN.md`.
|
||||
|
||||
Use `assets/DESIGN.md.template` as a starting point for new files when the repo has no existing `DESIGN.md`.
|
||||
|
||||
## Creating DESIGN.md
|
||||
|
||||
Prefer a specific design reference over vague adjectives. For example, "enterprise observability console with dense tables and quiet operational controls" is more useful than "modern, clean, premium." Include intentional negative constraints only when they prevent likely drift.
|
||||
|
||||
Structure the file as:
|
||||
|
||||
```markdown
|
||||
---
|
||||
version: alpha
|
||||
name: Product Design System
|
||||
colors:
|
||||
primary: "#1A1C1E"
|
||||
typography:
|
||||
body-md:
|
||||
fontFamily: Inter
|
||||
fontSize: 16px
|
||||
fontWeight: 400
|
||||
lineHeight: 1.5
|
||||
---
|
||||
|
||||
## Overview
|
||||
...
|
||||
```
|
||||
|
||||
Use canonical `##` sections in this order when relevant: `Overview`, `Colors`, `Typography`, `Layout`, `Elevation & Depth`, `Shapes`, `Components`, `Do's and Don'ts`. Preserve custom sections when editing existing files.
|
||||
|
||||
Include token groups that the implementation can actually use:
|
||||
|
||||
- `colors`: CSS color strings such as hex, rgb(), hsl(), oklch(), named colors, or transparent.
|
||||
- `typography`: objects with font family, size, weight, line height, letter spacing, and optional feature/variation settings.
|
||||
- `rounded`: radius scale values such as `4px`, `8px`, or `9999px`.
|
||||
- `spacing`: spacing scale values such as `4px`, `8px`, `1rem`, or domain-specific numeric values.
|
||||
- `components`: common component style tokens and state variants using literal values or references like `{colors.primary}`.
|
||||
|
||||
## Applying DESIGN.md
|
||||
|
||||
When building UI from an existing `DESIGN.md`:
|
||||
|
||||
1. Parse the YAML tokens first for exact values.
|
||||
2. Read the prose for personality, density, hierarchy, interaction emphasis, and constraints.
|
||||
3. Map tokens into the local styling system: CSS variables, Tailwind theme, component props, design-token JSON, or framework-specific theme configuration.
|
||||
4. Use the design's named roles, not arbitrary nearby values. Do not invent new colors, radii, shadows, or type styles unless the task requires extending the system.
|
||||
5. Keep visual decisions consistent across new screens and components. When a required pattern is absent, extend the `DESIGN.md` deliberately and validate it.
|
||||
|
||||
## CLI
|
||||
|
||||
Use the official package for checks and conversion:
|
||||
|
||||
```powershell
|
||||
npx -p @google/design.md designmd lint DESIGN.md
|
||||
npx -p @google/design.md designmd diff DESIGN.md DESIGN-v2.md
|
||||
npx -p @google/design.md designmd export --format css-tailwind DESIGN.md > theme.css
|
||||
npx -p @google/design.md designmd export --format json-tailwind DESIGN.md > tailwind.theme.json
|
||||
npx -p @google/design.md designmd export --format dtcg DESIGN.md > tokens.json
|
||||
```
|
||||
|
||||
On macOS/Linux, `npx @google/design.md ...` is also acceptable. On Windows/PowerShell, prefer the `designmd` alias via `npx -p @google/design.md designmd ...` because the `.md` executable name can collide with Markdown file associations.
|
||||
|
||||
If CLI access is unavailable, manually check:
|
||||
|
||||
- Front matter starts and ends with exact `---` fences.
|
||||
- Token references resolve to existing YAML paths.
|
||||
- Component text/background color pairs meet WCAG AA contrast for normal text when possible.
|
||||
- Present sections follow canonical order.
|
||||
- No duplicate section headings exist.
|
||||
|
||||
## Editing Rules
|
||||
|
||||
Preserve unknown sections and custom token keys unless the user asks to remove them. Unknown content is allowed by the format and often contains project-specific design context.
|
||||
|
||||
Reject or repair duplicate canonical sections, broken token references, obvious misspelled top-level keys, and invalid YAML.
|
||||
|
||||
Use `diff` when comparing versions. Treat added errors or warnings as a regression unless the user explicitly accepts the change.
|
||||
|
||||
## Sources
|
||||
|
||||
Primary reference: https://github.com/google-labs-code/design.md
|
||||
|
||||
Official spec: https://github.com/google-labs-code/design.md/blob/main/docs/spec.md
|
||||
@@ -0,0 +1,4 @@
|
||||
interface:
|
||||
display_name: "DESIGN.md"
|
||||
short_description: "Create and apply AI-readable design systems"
|
||||
default_prompt: "Use $design-md to create or apply a DESIGN.md for this UI project."
|
||||
@@ -0,0 +1,103 @@
|
||||
---
|
||||
version: alpha
|
||||
name: Product Design System
|
||||
description: Replace with a short description of the product or brand identity.
|
||||
colors:
|
||||
primary: "#111827"
|
||||
on-primary: "#FFFFFF"
|
||||
secondary: "#4B5563"
|
||||
tertiary: "#2563EB"
|
||||
neutral: "#F9FAFB"
|
||||
surface: "#FFFFFF"
|
||||
on-surface: "#111827"
|
||||
border: "#E5E7EB"
|
||||
typography:
|
||||
headline-lg:
|
||||
fontFamily: Inter
|
||||
fontSize: 32px
|
||||
fontWeight: 700
|
||||
lineHeight: 1.15
|
||||
headline-md:
|
||||
fontFamily: Inter
|
||||
fontSize: 24px
|
||||
fontWeight: 650
|
||||
lineHeight: 1.2
|
||||
body-md:
|
||||
fontFamily: Inter
|
||||
fontSize: 16px
|
||||
fontWeight: 400
|
||||
lineHeight: 1.5
|
||||
label-md:
|
||||
fontFamily: Inter
|
||||
fontSize: 14px
|
||||
fontWeight: 600
|
||||
lineHeight: 1.2
|
||||
rounded:
|
||||
sm: 4px
|
||||
md: 8px
|
||||
lg: 12px
|
||||
full: 9999px
|
||||
spacing:
|
||||
xs: 4px
|
||||
sm: 8px
|
||||
md: 16px
|
||||
lg: 24px
|
||||
xl: 32px
|
||||
components:
|
||||
page:
|
||||
backgroundColor: "{colors.neutral}"
|
||||
textColor: "{colors.on-surface}"
|
||||
button-primary:
|
||||
backgroundColor: "{colors.tertiary}"
|
||||
textColor: "{colors.on-primary}"
|
||||
typography: "{typography.label-md}"
|
||||
rounded: "{rounded.md}"
|
||||
padding: 12px
|
||||
card:
|
||||
backgroundColor: "{colors.surface}"
|
||||
textColor: "{colors.on-surface}"
|
||||
rounded: "{rounded.lg}"
|
||||
padding: 24px
|
||||
divider:
|
||||
backgroundColor: "{colors.border}"
|
||||
height: 1px
|
||||
---
|
||||
|
||||
## Overview
|
||||
|
||||
Describe the specific product, audience, visual reference, interaction density, and emotional target. Prefer concrete references over generic terms.
|
||||
|
||||
## Colors
|
||||
|
||||
- **Primary** is used for core text and the strongest structural elements.
|
||||
- **Secondary** is used for captions, metadata, borders, and low-emphasis controls.
|
||||
- **Tertiary** is used for the primary action and focused interactive emphasis.
|
||||
- **Neutral** is the page foundation.
|
||||
- **Surface** is used for panels, inputs, cards, and modal content.
|
||||
|
||||
## Typography
|
||||
|
||||
Describe the type hierarchy, role of each family, weight strategy, line-height rhythm, casing, and how dense or relaxed text should feel.
|
||||
|
||||
## Layout
|
||||
|
||||
Describe grid behavior, max content width, gutters, spacing rhythm, responsive behavior, and whether the UI should feel dense, spacious, editorial, operational, playful, or utilitarian.
|
||||
|
||||
## Elevation & Depth
|
||||
|
||||
Describe how hierarchy is created: shadows, borders, tonal layers, color contrast, flat surfaces, or another strategy.
|
||||
|
||||
## Shapes
|
||||
|
||||
Describe radius usage and exceptions. State whether the system is sharp, soft, geometric, organic, or mixed.
|
||||
|
||||
## Components
|
||||
|
||||
Describe primary buttons, secondary buttons, inputs, cards, lists, tables, navigation, dialogs, tabs, chips, tooltips, and state variants that matter to the product.
|
||||
|
||||
## Do's and Don'ts
|
||||
|
||||
- Do keep token usage consistent across screens.
|
||||
- Do preserve the intended hierarchy and interaction emphasis.
|
||||
- Don't introduce new colors, radii, shadows, or type styles without updating this file.
|
||||
- Don't use generic decorative effects that conflict with the overview.
|
||||
@@ -0,0 +1,198 @@
|
||||
# DESIGN.md Reference
|
||||
|
||||
Use this reference after the `design-md` skill triggers. It is a compact working guide based on the Google Labs DESIGN.md alpha specification.
|
||||
|
||||
## Purpose
|
||||
|
||||
`DESIGN.md` is a plain-text design-system file for coding agents. It has two layers:
|
||||
|
||||
- YAML front matter for machine-readable design tokens.
|
||||
- Markdown prose for design rationale, usage guidance, and constraints.
|
||||
|
||||
Tokens are the exact values. Prose explains the design intent and tells the agent how to apply the values.
|
||||
|
||||
## File Shape
|
||||
|
||||
```markdown
|
||||
---
|
||||
version: alpha
|
||||
name: Product Name
|
||||
description: Optional one-line summary
|
||||
colors:
|
||||
primary: "#1A1C1E"
|
||||
typography:
|
||||
body-md:
|
||||
fontFamily: Inter
|
||||
fontSize: 16px
|
||||
fontWeight: 400
|
||||
lineHeight: 1.5
|
||||
rounded:
|
||||
sm: 4px
|
||||
spacing:
|
||||
md: 16px
|
||||
components:
|
||||
button-primary:
|
||||
backgroundColor: "{colors.primary}"
|
||||
textColor: "{colors.on-primary}"
|
||||
rounded: "{rounded.sm}"
|
||||
padding: 12px
|
||||
---
|
||||
|
||||
## Overview
|
||||
...
|
||||
```
|
||||
|
||||
The front matter block must be at the top of the file and delimited by lines containing exactly `---`.
|
||||
|
||||
## Token Schema
|
||||
|
||||
Top-level token groups:
|
||||
|
||||
- `version`: optional, current alpha value is `alpha`.
|
||||
- `name`: design-system name.
|
||||
- `description`: optional short summary.
|
||||
- `colors`: map of color token names to CSS color strings.
|
||||
- `typography`: map of type role names to typography objects.
|
||||
- `rounded`: map of radius scale names to dimensions.
|
||||
- `spacing`: map of spacing names to dimensions or numbers.
|
||||
- `components`: map of component/state names to component property tokens.
|
||||
|
||||
Common color token names: `primary`, `secondary`, `tertiary`, `neutral`, `surface`, `on-surface`, `error`, `on-primary`.
|
||||
|
||||
Common typography token names: `headline-display`, `headline-lg`, `headline-md`, `body-lg`, `body-md`, `body-sm`, `label-lg`, `label-md`, `label-sm`.
|
||||
|
||||
Common rounded token names: `none`, `sm`, `md`, `lg`, `xl`, `full`.
|
||||
|
||||
## Token Types
|
||||
|
||||
Color values may be any valid CSS color string. Hex `#RRGGBB` is the safest default for broad tooling support.
|
||||
|
||||
Dimensions are numbers with `px`, `em`, or `rem` units. Use unitless `lineHeight` only when intended as a multiplier.
|
||||
|
||||
Typography objects may contain:
|
||||
|
||||
- `fontFamily`
|
||||
- `fontSize`
|
||||
- `fontWeight`
|
||||
- `lineHeight`
|
||||
- `letterSpacing`
|
||||
- `fontFeature`
|
||||
- `fontVariation`
|
||||
|
||||
Token references use `{path.to.token}`. Most references should point to primitive values, such as `{colors.primary}`. Component tokens may reference composite typography objects, such as `{typography.label-md}`.
|
||||
|
||||
## Section Order
|
||||
|
||||
Use `##` headings. Sections are optional, but present canonical sections should appear in this order:
|
||||
|
||||
1. `Overview` or `Brand & Style`
|
||||
2. `Colors`
|
||||
3. `Typography`
|
||||
4. `Layout` or `Layout & Spacing`
|
||||
5. `Elevation & Depth` or `Elevation`
|
||||
6. `Shapes`
|
||||
7. `Components`
|
||||
8. `Do's and Don'ts`
|
||||
|
||||
An optional `#` title may appear before the sections. It is not parsed as a design section.
|
||||
|
||||
## Section Guidance
|
||||
|
||||
`Overview`: describe the product, audience, density, personality, and emotional target. Use specific visual references. Avoid generic adjective lists.
|
||||
|
||||
`Colors`: define roles, not just hex values. Explain where each color appears and where it must not appear.
|
||||
|
||||
`Typography`: define hierarchy, font families, weights, scale, line heights, casing, data/label treatments, and reading-density decisions.
|
||||
|
||||
`Layout`: define grid, max widths, spacing rhythm, density, page gutters, container behavior, and responsive expectations.
|
||||
|
||||
`Elevation & Depth`: define whether hierarchy comes from shadows, borders, tonal layers, contrast, surface color, or no elevation.
|
||||
|
||||
`Shapes`: define radius, border geometry, sharp/soft language, and where exceptions are allowed.
|
||||
|
||||
`Components`: define buttons, inputs, cards, tables, lists, chips, tabs, dialogs, tooltips, and state variants that matter to the product.
|
||||
|
||||
`Do's and Don'ts`: include practical guardrails. Keep them intentional; if the list gets long, strengthen the overview and component guidance.
|
||||
|
||||
## Components
|
||||
|
||||
Known component property tokens:
|
||||
|
||||
- `backgroundColor`
|
||||
- `textColor`
|
||||
- `typography`
|
||||
- `rounded`
|
||||
- `padding`
|
||||
- `size`
|
||||
- `height`
|
||||
- `width`
|
||||
|
||||
Represent states and variants as related component keys:
|
||||
|
||||
```yaml
|
||||
components:
|
||||
button-primary:
|
||||
backgroundColor: "{colors.primary}"
|
||||
textColor: "{colors.on-primary}"
|
||||
rounded: "{rounded.md}"
|
||||
padding: 12px
|
||||
button-primary-hover:
|
||||
backgroundColor: "{colors.primary-hover}"
|
||||
```
|
||||
|
||||
Unknown component properties are allowed but should produce a warning during review.
|
||||
|
||||
## Consumer Behavior
|
||||
|
||||
Preserve unknown section headings. Preserve unknown valid token names. Accept unknown component properties with review warnings. Reject duplicate section headings. Fix broken references.
|
||||
|
||||
## Official CLI
|
||||
|
||||
Install or run directly:
|
||||
|
||||
```bash
|
||||
npm install @google/design.md
|
||||
npx @google/design.md lint DESIGN.md
|
||||
```
|
||||
|
||||
Windows/PowerShell reliable form:
|
||||
|
||||
```powershell
|
||||
npx -p @google/design.md designmd lint DESIGN.md
|
||||
```
|
||||
|
||||
Useful commands:
|
||||
|
||||
```powershell
|
||||
npx -p @google/design.md designmd lint DESIGN.md
|
||||
npx -p @google/design.md designmd diff DESIGN.md DESIGN-v2.md
|
||||
npx -p @google/design.md designmd export --format json-tailwind DESIGN.md > tailwind.theme.json
|
||||
npx -p @google/design.md designmd export --format css-tailwind DESIGN.md > theme.css
|
||||
npx -p @google/design.md designmd export --format dtcg DESIGN.md > tokens.json
|
||||
npx -p @google/design.md designmd spec --rules
|
||||
```
|
||||
|
||||
`lint` exits nonzero when errors are present. `diff` exits nonzero when the later file has regressions, such as more errors or warnings.
|
||||
|
||||
## Authoring Checklist
|
||||
|
||||
- Use a concrete visual reference in `Overview`.
|
||||
- Include exact values for reusable colors, typography, spacing, radii, and core components.
|
||||
- Explain scarcity rules for accents, shadows, display type, decorative elements, and motion.
|
||||
- Use token references for component values instead of duplicating literals.
|
||||
- Keep prose actionable for future UI generation.
|
||||
- Validate with the CLI and fix structural errors.
|
||||
|
||||
## Applying Checklist
|
||||
|
||||
- Read `DESIGN.md` before editing UI.
|
||||
- Bind exact tokens to CSS variables, Tailwind theme entries, framework theme objects, or component constants.
|
||||
- Use prose for unstated choices such as density, hierarchy, affordance strength, and restraint.
|
||||
- Avoid introducing style drift. Add new tokens only when the task expands the design system.
|
||||
- Re-run lint after editing `DESIGN.md`.
|
||||
|
||||
## Source Links
|
||||
|
||||
- Repository: https://github.com/google-labs-code/design.md
|
||||
- Specification: https://github.com/google-labs-code/design.md/blob/main/docs/spec.md
|
||||
- Philosophy: https://github.com/google-labs-code/design.md/blob/main/PHILOSOPHY.md
|
||||
Reference in New Issue
Block a user