Design

The kit ships no CSS. Its markup carries styling hooks, and each site's look is its own theme, taken from its example and owned by the site from the first commit. A kit update never changes how a site looks.

The theme

The theme is one folder, src/styles/theme/:

Path	What it holds
`tokens/colors.css`	the color scheme in use: one `@import` of a preset
`tokens/type.css`	fonts and the text scale
`tokens/shape.css`	radii and shadows
`tokens/space.css`	the content width, section spacing, side gutter and breakpoint
`presets/colors/`	the color schemes, such as `basics`' `navy` and `pine`
`fonts.css`	the fonts, from `public/assets/fonts/`
`base.css`, `layout.css`, `sections.css`, `prose.css`	the styles of the page, the header and footer, every section type, and rendered Markdown
`README.md`	the design's roles, color schemes and the text and background pairs whose contrast is checked

The site's own CSS goes in src/styles/site.css, outside the theme, and wins over it.

Make it the client's

Colors. Add a preset for the client's palette in presets/colors/, with the same color names as the others, and import it in tokens/colors.css. Don't edit a shipped preset: a new one keeps them to compare against.
Fonts. Put the font files in public/assets/fonts/, with their license text beside them, and name them in fonts.css and tokens/type.css.
Shape and space. Change the radii, shadows and spacing in tokens/shape.css and tokens/space.css.

Check the theme, then the built pages:

npm run check:styles
npm run build
npm run check:styles -- --built

Every color is a role, such as --color-surface or --color-accent, so a change to a token changes it everywhere. Colors are written only in the color presets, and font names only in tokens/type.css and fonts.css.

Styling hooks

Every part of the kit's markup has an sk- class, such as sk-hero and sk-hero__title. Variants and tones add modifier classes, such as sk-hero--page, and states show as attributes, such as data-open on the menu. The theme styles these hooks, so a theme styles every section type, variant and tone, including the ones the site doesn't use yet. HOOKS.md lists them all.

The site's own markup, such as a custom page or a site section, uses Tailwind utilities built from the theme's tokens, such as bg-surface or text-h2. The theme resets Tailwind's default colors, fonts, sizes, radii and shadows, so a class like bg-red-500 or text-4xl renders nothing.

What the style checks report

npm run check:styles, before the build, fails on:

a color outside the color presets, or a font name outside tokens/type.css and fonts.css;
an arbitrary Tailwind value, such as p-[13px];
an sk- class the installed kit doesn't have;
a color preset whose color names differ from the others', or that fails one of the contrast pairs in the theme's README.md.

It warns about a hook that the kit deprecates, naming its replacement.

npm run check:styles -- --built, after the build, warns about hooks the built pages carry that the theme doesn't style, such as a new variant after a kit update, and about classes that no rule matches. The deploy workflow runs both checks on every push.

Accessibility

The kit's markup has the landmarks, one h1 per page, alternative text, keyboard use of the menu and the FAQ, and names for icon-only buttons. What only CSS can do is the theme's job: text contrast of at least 4.5:1, or 3:1 for large text, in every color scheme, a visible focus style, a skip link that shows on focus, buttons and header controls of at least 44 by 44 pixels, and no motion when a visitor asks for reduced motion.

Another example's look

To give a site another example's look, copy that example's src/styles/theme/ and public/assets/fonts/ at the release the site uses, then run the style checks. The README has the steps, and everything about themes.