frontend-design: consider consuming/producing DESIGN.md per Google Labs open spec

## Summary Suggestion: extend the `frontend-design` skill to optionally **consume** or **produce** a `DESIGN.md` file following the format Google Labs [just shipped as an open spec](https://github.com/google-labs-code/design.md) on 2026-04-22. It's a single-markdown design-system contract with YAML frontmatter (tokens for colours, typography, spacing) plus prose explaining the *why*. ## Why this might fit The skill currently works from freeform user requirements and produces implementation directly. That's great for one-shot outputs but leaves a gap for multi-agent / multi-pass workflows where consistency across pages or across sessions matters. A DESIGN.md contract would let `frontend-design` act at two points: 1. **Phase 1 — Design**: if no DESIGN.md exists, distil the user's brief into one. Tokens named by role ("primary" = "main ink for body text"), prose explaining aesthetic direction and differentiator. Future passes read the same file. 2. **Phase 2 — Implementation**: if a DESIGN.md exists (either produced in phase 1 or authored by the user), every downstream generation reads it and stays consistent. Agents verify output against WCAG contrast checks via the `npx @google/design.md lint` CLI before writing code. The "BOLD aesthetic direction" and "one memorable differentiator" principles the skill already articulates land really well in the *prose* section of a DESIGN.md. The distinctive typography + colour + motion choices fit the *tokens* section. ## What this would look like - Skill checks for existing `DESIGN.md` in the project root. If present, reads it before generating. - If no DESIGN.md and the user's brief suggests a multi-page or multi-component output, skill offers to generate one first and then implement against it. - Export paths: the Google Labs spec ships `export --format tailwind` which drops into Tailwind theme configs directly, and W3C DTCG tokens for other toolchains. Relevant for teams with existing design systems. - `lint` CLI catches accessibility regressions (WCAG contrast ratios on component colour pairs) before code gets written. ## Why now The spec shipped two days ago (1.6k stars, Apache 2.0, alpha). It's emerging as a shared contract for agent-driven UI — same shape as CLAUDE.md/AGENTS.md but for visual decisions. Getting in early means the skill participates in the convention rather than diverging from it. ## Not prescriptive Happy for this to be "we evaluated it and decided not to adopt" — the suggestion is to make the consideration deliberate rather than miss it. The skill's current "avoid AI slop, distinctive aesthetic" ethos might be better served by loose creativity than by a structured contract, and that's a valid design choice. ## Context Surfaced in our team's Claude Code Chat space 2026-04-22 as a relevant standard for agent-driven frontend work. Filing the suggestion here because the skill's ethos and Google Labs' spec overlap substantively on the "consistent, intentional, auditable" axis. Google Labs spec: https://github.com/google-labs-code/design.md 10-min video walkthrough: https://youtu.be/W1gWIQp9k1Y