Knowledge base on design systems methodology and practice — Brad Frost's Atomic Design (atoms/molecules/organisms/templates/pages, pattern libraries, workflow, maintenance) plus practical patterns for design tokens, component API conventions, documentation/governance, accessibility, and adoption/migration. Use when designing a new component library or design system from scratch, deciding how to structure/name/compose components, setting up design tokens, planning documentation or governance, or auditing an existing system for consistency and maintainability.
Sources: Brad Frost's Atomic Design (atomicdesign.bradfrost.com, free online book) + synthesized industry practice | Chapters: 17 | Generated: 2026-08-25
design tokens, atomic design, component API, accessibility, governance, or similar; I find and read the matching chapterch011; I load that specific chapterWhen you ask about a topic not covered in Core Patterns below, I will read the relevant chapter file before answering.
Atomic Design is a vocabulary, not a rulebook. Atoms → molecules → organisms → templates → pages describes increasing levels of composition. Its value is a shared team language for talking about structure, not a strict classification every component must fit perfectly.
Design in components and systems, never in one-off pages. A page is one rendering of the system's patterns with real content — the reusable pattern behind it, not the page itself, is the actual design asset.
Content-agnostic structure is what makes a component reusable. Name and build patterns by their function ("labeled input"), not by their first use case ("SignupEmailField") — context-specific naming quietly locks a reusable pattern to one place.
Design tokens are the machine-readable atoms. Structure them in two layers: primitive (raw values) and semantic (meaningful aliases, e.g. color.action.primary). Components should only ever reference the semantic layer — that's what makes theming and rebrands a one-place change.
A shared component API vocabulary (variant/size/tone) matters more than any single component's cleverness. Prefer compound components and slots over prop-list explosion once a component's responsibilities multiply.
Documentation must be wired to real code, not hand-maintained separately. A living story explorer (Storybook or similar) rendering the actual production component is the only documentation that can't silently drift from what ships.
Accessibility fixed once in a shared component is fixed everywhere that component is used. This is the single strongest argument for building on accessible-by-default primitives (see radix-primitives-docs, base-ui-docs) instead of ad hoc markup per feature.
A design system is a product, not a deliverable. It needs ongoing governance (a lightweight process for proposing/reviewing/retiring patterns), real versioning discipline (semver + changelog + deprecation windows), and active promotion — launch is the start, not the finish line.
| # | Title | Key Concepts |
|---|---|---|
| ch001 | Designing Systems | pages vs. systems, modularity, style guide benefits/challenges |
| ch002 | Atomic Design Methodology | the chemistry analogy, five stages overview |
| ch003 | Atoms | base HTML elements, invisible atoms (color/type/spacing) |
| ch004 | Molecules | single responsibility, first reusable unit |
| ch005 | Organisms | distinct interface sections, repeatable molecules |
| ch006 | Templates & Pages | structure vs. real content, edge-case testing |
| ch007 | Why Atomic Design Works | part-and-whole thinking, structure/content separation, naming, beyond the web |
| ch008 | Tools of the Trade | Pattern Lab, nesting, pseudo-patterns, lineage, code view |
| ch009 | The Atomic Workflow | interface inventories, buy-in, in-browser iteration |
| ch010 | Maintaining Design Systems | the ten "make it..." maintenance principles |
| # | Title | Key Concepts |
|---|---|---|
| ch011 | Design Tokens | primitive vs. semantic tokens, DTCG format, Style Dictionary |
| ch012 | Component API Conventions | variant/size/tone, compound components, asChild, slots |
| ch013 | Documentation & Pattern Labs in Practice | Storybook, Ladle, generated docs, visual regression |
| ch014 | Versioning & Governance | semver, changelog, deprecation windows, ownership models |
| ch015 | Accessibility as a System Requirement | WCAG baseline, automated vs. manual testing, accessible-by-default primitives |
| ch016 | Adoption & Migration | gradual rollout, codemods, measuring adoption |
| ch017 | Real-World Design Systems Survey | Material 3, Atlassian, Polaris, Carbon |
This skill has two distinct source layers, and they carry different confidence levels:
This is a methodology/practice skill, not an implementation skill. For the concrete API of specific component libraries this project already covers, use those skills directly: radix-primitives-docs and base-ui-docs for unstyled primitives, shadcn-ui-docs for the styled layer built on them, tailwind-docs for the styling system most of these examples assume, and aceternity-ui-docs for a copy-paste animated component catalog. This skill is about how to structure, govern, and scale a system built from tools like those — not a replacement for their docs.