design-md-workflow

Create, maintain, and verify DESIGN.md visual-identity contracts with YAML design tokens and Markdown rationale.

3|Updated Jul 28, 2026
One-click install
npx skills add https://github.com/marcmarti9/agentit --skill design-md-workflow-marcmarti9
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: design-md-workflow
Source: https://github.com/marcmarti9/agentit/tree/main/skills/design-md-workflow
Command: npx skills add https://github.com/marcmarti9/agentit --skill design-md-workflow-marcmarti9

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Multi-session frontend work often drifts in typography, color, spacing, and component styling because design decisions live only in chat history. This Skill establishes a durable, agent-readable DESIGN.md contract that keeps visual identity consistent across sessions, agents, and implementation passes. ## Core Features & Use Cases - Read and apply existing DESIGN.md: Parse YAML front matter tokens and Markdown rationale, compare them against real implementation tokens, and feed only the relevant subset to frontend workers. - Create from project truth: Build DESIGN.md from brand assets, current UI, tokens, components, and Figma sources rather than fabricating a generic design system. - Validate and detect drift: Use the upstream Google Labs CLI (lint, diff, token export to Tailwind or DTCG) plus rendered UI and accessibility checks to confirm the contract matches production. - Use Case: A team notices agents keep producing inconsistent button styles across sessions. Use this Skill to encode semantic color roles, type hierarchy, and component states into DESIGN.md, then verify each new UI change against it. ## Quick Start Read the project's DESIGN.md and update the button component styles to match its semantic tokens and rationale.

Frequently Asked Questions about design-md-workflow

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I create a DESIGN.md file for my project?▼

Create DESIGN.md by inspecting brand assets, current UI, tokens, components, and Figma sources, then normalizing semantic token roles and writing concise rationale. Validate it with the upstream CLI and compare the contract against actual implementation before treating it as canonical.

What is the DESIGN.md format from Google Labs?▼

DESIGN.md is an alpha format combining YAML front matter for design tokens (colors, typography, rounded, spacing, component mappings) with Markdown sections explaining design rationale. Because it is alpha, re-check the upstream specification before depending on exact schema or CLI behavior.

How do I validate DESIGN.md against my design system?▼

Validate DESIGN.md using the upstream CLI commands equivalent to npx @google/design.md lint and diff, which can also export tokens to Tailwind or DTCG formats. Lint success is not enough; also verify rendered UI, contrast, and drift from production tokens.

When should I not use a DESIGN.md workflow?▼

Avoid DESIGN.md for one-off tiny UI edits where the existing component system already answers the visual question. It should also never silently override a stronger canonical source like production tokens or an authoritative Figma design system.

Does DESIGN.md replace my existing design tokens or Figma files?▼

No, DESIGN.md is durable project memory, not a replacement for the real source of truth. Follow the authority order: explicit brand requirements, production design system or Figma, then DESIGN.md, and update the canonical source when conflicts appear.