Documentation is split by authority.
System meaning
Source contracts, jobs, usage, when-not, responsive meaning, accessibility expectations, themes, patterns, completeness, product decisions, and Catalog lineage.
Product truth
What this product specifies, designs, implements, has not implemented yet, and where the real code lives.
Executable component states
Stories, args/Controls, responsive preview, source/API docs, automated accessibility, interaction tests, and visual-test integrations.
Do not invent an install surface before one exists.
This site defines the system model and documentation architecture. It does not claim a final package name, CLI, token file schema, component API, Storybook connection, or centralized governance service. Implementation docs become code-level docs only when those artifacts are real.
Use the docs by job.
Storybook: exercise the implementation.
Storybook already models component states as stories, makes args live-editable through Controls, can generate Autodocs and MDX documentation, provides viewport tooling, and supports accessibility and interaction testing. Building Blocks should specify the required state/behavior matrix and link or embed those executable surfaces when the implementation exists.
Storybook relationship →Skeleton: benchmark breadth and theme exploration.
Skeleton is useful because its documentation makes the inventory visible and its theme experience makes system-wide variation tangible. Building Blocks should borrow the visibility and workbench ideas—not Skeleton’s visual style, Tailwind/Svelte/React APIs, or package model.
Skeleton relationship →Source contracts remain above benchmarks.
External systems can reveal missing baseline candidates or better documentation patterns. They do not silently rewrite the B&Co Standard or Completeness Checklist. Any proposed source change is a proposal until explicitly adopted.
See what’s included →