One stylesheet, many sites. Reusable design kits — each a family of switchable themes — that dress any site in the network in seconds, keep a live theme picker, and survive bulk content updates. The cure for the generic-AI look, applied at network scale.
A kit is a coordinated design language (typography + structural styling) with five themes (color worlds) inside it. A site picks one kit and a default theme; visitors can switch themes live with the on-page picker, and the choice is remembered. Everything is driven by CSS custom properties, so a kit is mostly data — not bespoke code per site.
The whole system lives in one file: https://www.wholetech.com/wt-skins.css. A page opts in with two classes on its <html> tag:
<html class="wtk-rugged wtt-2"> ← kit = rugged, theme = 2 (Solar)
Live example of the rugged kit, all five themes (use its bottom-right picker): offgridder.com.
Each theme is just a block of CSS variables on the kit+theme selector. The kit's component rules (cards, hero, buttons, nav) read those variables, so the same markup re-skins instantly:
html.wtk-rugged.wtt-2{ /* Solar */
--bg:#0b0c0e; --surface:#15171a; --s2:#1d2024;
--border:#34373d; --text:#f3efe6; --dim:#b9b3a4;
--accent:#ffb400; ... }
html.wtk-rugged .card{background:var(--surface);border:1px solid var(--border)}
html.wtk-rugged .btn{background:var(--accent);color:var(--bg)}
The standard variable names — --bg, --surface, --s2, --border, --text, --dim, --muted, --accent (plus --h/--b for heading/body fonts) — are shared by every kit. That's what makes the next two pieces possible.
Many older pages ship their own inline CSS that can fight the kit. The enforcer (bottom of wt-skins.css) re-asserts the kit's variables on body, headings, cards, sections and buttons with !important, scoped to html[class*="wtk-"]. Result: the kit always wins the cascade, network bars (promo bar, ticker) are deliberately left alone.
Every skinned page gets a small fixed picker (#wt-skinbar) listing the kit's five theme names. It swaps the wtt-N class on <html> and saves the choice to localStorage per hostname, so a returning visitor sees their pick. No build step, no reload.
The rollout tool is /root/wt-skin-rollout.py on the droplet. It injects the fonts, the stylesheet link, the pre-paint script and the picker into every page of a site, sets the <html> classes, and is idempotent with per-file backups.
# dry-run every mapped site python3 wt-skin-rollout.py # apply to a specific cluster python3 wt-skin-rollout.py --apply offgridder.com earthscrapers.com stonedom.com # undo a site python3 wt-skin-rollout.py --rollback offgridder.com
Which kit/theme each site gets is the MAP dict at the top of that script ("site.com":("rugged",1)). Theme names per kit live in NAMES; font links in FONT. Add a site to MAP, run with --apply, done.
| System | How kits stay compatible |
|---|---|
| WT-Blocks (bulk content) | Kits only style; they never touch the <!-- wt:sources --> markers on subpages. You can restyle 80 sites and bulk-edit their sources/videos/FAQ independently. See /design/. |
| Agents First | The rollout never removes the AGENTS bar, AGENTS.md, llms.txt, robots policy, or schema. Design is cosmetic; discoverability is untouched. |
| Network bars | The promo bar, news nav and live pill are excluded from enforcer overrides so cross-site navigation always renders. |
There is a memory rule (what Paul calls a "directive") that loads into every Claude session on this project:
Where it lives: the memory file feedback_redesign_use_kit.md in Claude's memory folder, synced to every machine via claude-env.
~\claude-env\memory\feedback_redesign_use_kit.md, then run sync.ps1.MEMORY.md) and sync.The same pattern governs every standing rule — design bar, content discipline, push semantics. They're plain Markdown files; editing them changes how every machine behaves next session.