Create DESIGN.md

Produce a DESIGN.md in the @google/design.md format: YAML frontmatter holding the machine-readable token system (colors, typography, rounded, spacing, components) plus a human-readable body explaining how the system behaves. The file becomes the single source of truth that humans and agents consult before touching UI — so every value in it must be defensible, and vague filler is worse than an honest gap.

Read references/format.md before writing the file. It contains the exact frontmatter schema, the token-reference syntax, and the required body sections.

Workflow

1. Inventory the inputs

Establish what evidence exists before extracting anything:

• Screenshots / images — the user attached them or gave paths. Read each one.
• Live URL(s) — the user gave one or more web addresses. The rendered site is ground truth for its own design; mine its CSS and screenshot it (playbook below).
• Code or codebase — the user pointed at files, or the working directory is a project with UI code. Detect UI code with a quick scan (package.json deps, *.css, tailwind.config.*, theme files).
• Written description — the user described the look they want ("dark, dense, terminal-inspired…").
• Brand reference — the user named a brand. Check resources/design-md/ in this skill's directory for a ready-made analysis (stripe, linear.app, vercel, notion). If present, use it as the base and adapt it to the project rather than re-deriving from scratch. For other brands, derive the system from screenshots or the brand's live site; getdesign.md hosts downloadable analyses of many more brands the user can supply.

Sources combine. When they conflict, trust in this order: actual code values (project source, or CSS / computed styles fetched from a live URL) > screenshot measurements > description inferences > brand-reference defaults. Code is ground truth for what actually ships; everything else is interpretation.