authoring-design-system — SKILL.md

Variant: standard · When to use: producing (or amending) a design-system document from a product's direction, to a quality bar a designer/engineer can build a consistent, accessible UI from.

Overview

This skill is the how-to of writing a usable, consistent, accessible design-system document — the reusable visual + interaction language a product's UI draws on (principles, design tokens, a component catalog, patterns, layout + internationalization conventions, accessibility standards, voice, and lifecycle/governance). It supplies the producer's judgment, not the section list. It assumes two collaborators: a design-system template tool that supplies the section structure, and a deep-research capability to ground tokens and components in established practice. The producer is handed the product direction (and any user-flows) and must elaborate it — never emit generic boilerplate. The bar to clear: a designer can build a consistent UI and an engineer can implement it from the document, the catalog covers every component the product's screens need, and the system is accessible. The document is the vocabulary later wireframes and hi-fi draw on — it precedes them.

The artifact is textual markdown — tokens as values + DTCG-shaped tables (hex/HSL/Oklch), type-scale + component spec tables. Not a rendered Figma file, not a compiled token package. The method is medium-independent; the artifact today is text.

When to activate

• Authoring a new design-system document from a product's direction / PRD.
• Expanding a thin token set or component list into a full design system (foundations + catalog + patterns + accessibility + voice + governance).
• Amending an existing design system for a change (a new/changed token or component) — as a scoped, versioned delta (see Step 7).
• Filling a design-system template with researched, decision-complete content.

Do NOT activate when: