How this was made

The exact workflow, so you can run it yourself. One orchestrator model doing the taste work, cheaper models doing the volume work, one static deploy.

STEP 01Briefs before builds

The single highest-leverage artifact in this project is not code — it's a briefs file. Before anything was built, the strongest model in the stack (Claude Fable 5) wrote an art-direction brief for all 25 sites in one sitting: concept, exact palette (hex values), a typography pairing, the one signature technique the site exists to showcase, a layout spec, and a motion spec. For the hardest techniques, the brief includes the core code itself — a GLSL noise shader, a flow-field integrator, a variable-font proximity loop — so the builder never has to invent the hard part.

Why this matters: design quality lives in the decisions, not the typing. Concentrating every decision into one authored document means the expensive model's taste is captured once and reused 25 times, and every downstream build becomes a bounded, verifiable task.

STEP 02Fundamentally different, on purpose

"Make 25 different websites" degenerates into 25 hero-sections with different colors unless difference is structural. So each brief is anchored to a different technique, and the techniques were chosen first, like a syllabus:

• Raw WebGL2 fragment shaders (fbm nebulae) — no three.js, no libraries
• Scroll-driven narrative — the page state is the story position
• Seeded generative art — the algorithm is the product, regenerate is the CTA
• Variable-font axes as an interface — cursor proximity drives font-variation-settings
• 3D CSS product staging — perspective tilt + a conic-gradient specular that follows the pointer
• …and twenty more: SVG goo filters, Web Audio synthesis, verlet jellyfish, glitch editorial, isometric self-assembly, a playable lander.

Everything is vanilla HTML/CSS/JS in a single file per site. No build step, no framework. That constraint is doing real work: it keeps every site auditable, portable, and honest — the design skill can't hide behind a component library.

STEP 03Parallel builds, one integrator

Each site was built by an independent agent (Claude Opus) given exactly one brief plus the shared conventions, with a hard scope boundary: write one file, touch nothing else. Five builders ran concurrently. The orchestrator never wrote volume code — it wrote the briefs, built the hub and this guide, and did final review.

fable-25/
├── BRIEFS.md            ← the taste layer (all 25 briefs)
└── site/                ← the deploy root
    ├── index.html       ← hub gallery
    ├── guide/index.html ← this page
    ├── 01-meridian/index.html
    ├── 02-umbra/index.html
    └── …one folder per site

STEP 04Iteration passes

Every site gets reviewed with a fine-toothed comb before it's accepted: does the signature moment actually fire, does the palette match the brief's hexes, does it hold at 375px and 1440px, does prefers-reduced-motion genuinely stop the motion, is the copy believable. Builders self-review once; the orchestrator reviews again with fresh eyes and fixes or rejects. The review criteria are written down in the brief, so "done" is checkable rather than vibes.

STEP 05Deploy

The whole collection is static files, so hosting is one command against the site/ directory:

wrangler pages project create fable-25
wrangler pages deploy site/ --project-name=fable-25

Cloudflare Pages serves each folder at its own route (/01-meridian/, /guide/…), free, on a global CDN. Adding sites 6–25 is: build from the brief, drop the folder in, redeploy.

REPLICATE ITThe whole recipe in five lines

• Have your best model write all the briefs first — palette hexes, type pairing, one signature technique, motion spec, and the hardest 20 lines of code.
• Write shared conventions once, including named anti-slop rules and a footer/navigation contract.
• Fan out builds to cheaper parallel agents, one brief + one file each, hard scope walls.
• Review against the brief's own checklist; iterate before accepting.
• Keep everything static; deploy is one command.