Skill metadata
Reference: full SKILL.md
The following is the complete skill definition that Mibyan loads when this skill is triggered. This is what the agent sees as instructions when the skill is active.
DESIGN.md Skill
DESIGN.md is Google’s open spec (Apache-2.0,google-labs-code/design.md) for
describing a visual identity to coding agents. One file combines:
- YAML front matter — machine-readable design tokens (normative values)
- Markdown body — human-readable rationale, organized into canonical sections
npx @google/design.md) lints structure + WCAG contrast,
diffs versions for regressions, and exports to Tailwind or W3C DTCG JSON.
When to use this skill
- User asks for a DESIGN.md file, design tokens, or a design system spec
- User wants consistent UI/brand across multiple projects or tools
- User pastes an existing DESIGN.md and asks to lint, diff, export, or extend it
- User asks to port a style guide into a format agents can consume
- User wants contrast / WCAG accessibility validation on their color palette
popular-web-designs
instead. For process and taste when designing a one-off HTML artifact
from scratch (prototype, deck, landing page, component lab), use
claude-design. This skill is for the formal spec file itself.
File anatomy
Token types
Component property whitelist:
backgroundColor, textColor, typography,
rounded, padding, size, height, width. Variants (hover, active,
pressed) are separate component entries with related key names
(button-primary-hover), not nested.
Canonical section order
Sections are optional, but present ones should appear in this order. The linter flags out-of-order sections (section-order, warning) and duplicate
headings — consumers per the spec reject duplicates, so fix both before
returning the file.
- Overview (alias: Brand & Style)
- Colors
- Typography
- Layout (alias: Layout & Spacing)
- Elevation & Depth (alias: Elevation)
- Shapes
- Components
- Do’s and Don’ts
Workflow: authoring a new DESIGN.md
- Ask the user (or infer) the brand tone, accent color, and typography direction. If they provided a site, image, or vibe, translate it to the token shape above.
- Write
DESIGN.mdin their project root usingwrite_file. Always includename:andcolors:; other sections optional but encouraged. - Use token references (
{colors.primary}) in thecomponents:section instead of re-typing hex values. Keeps the palette single-source. - Lint it (see below). Fix any broken references or WCAG failures before returning.
- If the user has an existing project, also write Tailwind or DTCG
exports next to the file (
tailwind.theme.json,tokens.json).
Workflow: lint / diff / export
The CLI is@google/design.md (Node). Use npx — no global install needed.
- for stdin. lint returns exit 1 on errors (warnings
alone exit 0). export exits 0 on a successful export regardless of lint
findings in the source — run lint separately to gate on those. Output is
JSON by default; parse it if you need to report findings structurally.
On Windows, the design.md bin name can collide with the .md file
association (silent no-op or the file opens in an editor). Use the dot-free
alias: npx -y -p @google/design.md designmd lint DESIGN.md.
Lint rule reference (the 9 rules, as of CLI 0.3.0)
broken-ref(error) —{colors.missing}points at a non-existent tokencontrast-ratio(warning) — componenttextColorvsbackgroundColorbelow WCAG AA (4.5:1)missing-primary(warning) — colors defined but noprimarytokenmissing-typography(warning) — colors defined but no typography tokensorphaned-tokens(warning) — color tokens never referenced by a componentsection-order(warning) — sections out of the canonical orderunknown-key(warning) — top-level YAML key that looks like a typo of a schema key (colours:→colors:); custom extension keys stay silenttoken-summary,missing-sections(info) — counts and absent optional sections
Pitfalls
- Don’t nest component variants.
button-primary.hoveris wrong;button-primary-hoveras a sibling key is right. - Hex colors must be quoted strings. YAML will otherwise choke on
#or truncate values like#1A1C1Eoddly. - Negative dimensions need quotes too.
letterSpacing: -0.02emparses as a YAML flow — writeletterSpacing: "-0.02em". - Section order matters even though the linter only warns. If the user gives you prose in a random order, reorder it to match the canonical list before saving — spec-compliant consumers expect it.
- Typography sub-property typos are silently dropped. As of CLI 0.3.0 a
typo like
fontwight:produces no finding and the value vanishes from exports — double-check sub-property names against the schema (fontFamily,fontSize,fontWeight,lineHeight,letterSpacing,fontFeature,fontVariation). version: alphais the current spec version (as of Jul 2026, CLI 0.3.0). The spec is marked alpha — watch for breaking changes.- Token references resolve by dotted path.
{colors.primary}works;{primary}does not.
Spec source of truth
- Repo: https://github.com/google-labs-code/design.md (Apache-2.0)
- CLI:
@google/design.mdon npm - License of generated DESIGN.md files: whatever the user’s project uses; the spec itself is Apache-2.0.

