Docs

Building Blocks + Skeleton

Use Skeleton as a benchmark for visible breadth, live themes, and documentation depth—not as a visual template or source-contract replacement.

What’s included

Skeleton remains a useful benchmark for visible inventory breadth, component-detail information architecture, live theme exploration, and showing a complete system publicly. It is not Building Blocks’ visual template, and this page claims no Skeleton dependency or package relationship.

Why Skeleton is a useful benchmark

Skeleton makes a design system feel complete because its documentation exposes the inventory directly rather than hiding most components behind search. It also treats themes as a first-class, live experience. Those two qualities directly address the shallowness problem identified in Building Blocks v0.1.

Borrow inventory visibility.

Skeleton separates design-system/foundation material, Tailwind-oriented visual components, and framework-specific behavioral components in its docs architecture. Building Blocks should use its own categories—Foundation, Components, Patterns, Themes, Catalog, Guides—but make the breadth equally obvious.

Do not copy Skeleton’s taxonomy literally.

The B&Co checklist contains product-decision and governance rows that do not map cleanly to a conventional component library.

Borrow live theme exploration.

Skeleton’s current theme documentation demonstrates multiple preset themes and CSS-variable-driven customization. That supports a Building Blocks workbench where one stable system can be exercised against different product expressions.

Open the Building Blocks Themes workbench →

Borrow deeper component-page expectations.

Skeleton’s stronger component pages combine a clear purpose, live examples, variants/states, and copyable implementation examples. Building Blocks should match that depth when real code exists, while also adding the B&Co-specific job, when-not, source contract, responsive meaning, accessibility, token lineage, related patterns, and Catalog connection.

Do not copy its product model.

  • Do not copy Skeleton’s brand or visual styling.
  • Do not imply Building Blocks is Tailwind-, Svelte-, or React-specific before implementation decisions are real.
  • Do not reduce Foundation to visual tokens alone.
  • Do not replace the product-local Catalog with a central component gallery.

Official research sources

Skeleton · Themes · Buttons · Dialog