How the system is built, and why its docs stay true
Rift DS ships as the npm package rift-ds: layered CSS tokens, React components, and complete themes, each a generated stylesheet applied by one data-brand attribute. This site installs that package like any other consumer would, and everything documented here is held to the code by the build: generators write the docs from the code's own registries in the repo, and validators fail the build when the two disagree. What these pages say is what the package does. You can install it yourself and re-theme it live.
All of it is open to lift: the specs ( CLAUDE.md, design.md, content-design.md), the skills, and the loops drop into your own codebase or AI tooling. Agents connect to the same docs through the MCP endpoint at /api/mcp: one URL for the component list, exact prop contracts, and the token registry.
Using it in your product
The consumer's view first. Install the package, import one stylesheet, and compose the components; a data-brand attribute on your root element applies a complete theme, light and dark included. Your coding agent joins through this site: one command installs the generated agent skill, and the MCP endpoint serves the exact prop and token contracts while it builds.
smart_toyYour coding agentbuilds with exact prop and token contracts
hubThis site/api/mcp · the agent skill · component .md pages
npm install, then importone stylesheet importone attribute applies a complete looknpx init installs the agent skillreads contracts over MCP
Zoom outZoom inFit the whole mapExpand the map
Your product on the right, the package on the left, and this site serving your agent between them.
The system in one breath
One repo becomes one website, one Storybook, and one npm package, through a single gate: generators derive every surface from one source of truth, validators fail the build when anything drifts, and CI runs the whole chain on every push. The maps below magnify that picture one lane at a time; each pans, zooms, and expands to fill the screen.
Figma
Claude Code
GitHub
Storybook
Vite
Next.js
Vercel
npm
Google
One repocode · registries · specs
fact_checkGenerate · validate · gateone chain, before every build
Vercelwebsite + Storybook
npm registryrift-ds
groupsVisitors + agentspages · chat · MCP
downloadPackage consumersimport the components
push to mainmanual release
Zoom outZoom inFit the whole mapExpand the map
One repo, one gate, two destinations. The other four maps magnify the lanes.
The system as one graph
Start with what the repo holds. Laid out as one graph, the system is five layers deep: primitives feed the semantic tokens, tokens feed the components, and the components compose the site UI and every page. The graph page reads every edge out of the CSS and the import statements at build time. Pick any token or component and it traces both directions: everything it depends on, and everything that would feel a change to it.
The live instrument, mid-trace on Button: 743 nodes and 8862 dependencies, drawn from the same generated data. Open it to trace any node yourself.
The pipeline
A change to any of those layers becomes live the same way, in five stages: author, generate and validate, build, gate, ship. A push to main deploys the site; the package takes its own lane, published to npm with provenance and no stored token. The map carries the detail: the drift guard, the hydration smoke, the axe audit on every story.
1 · Authoreverything hand-written
2 · Generate + validateno build starts before this passes
before every buildbuild time onlypush to main deploysdispatched by handpublish from dist/ · provenance
Zoom outZoom inFit the whole mapExpand the map
Five stages, then the flow snakes down through the gate.
The operator layer
Claude Code drives the pipeline through skills named for their end state. The spine is four states a change can be in; checkpoint, park, land, and ship are the transitions between them, and the audit skills above the spine can read and fix but never deploy. The only two paths to production are ship and super-ship, which runs a full drift audit first.
Claude Code · the operator layerskills named for their end state
Audit skillsdrift · token · content · api · seo · security · a11y · design-qa · …
autorenewRecurring loops2 loops · every run ends in a report for approval
checklistpre-deploythe full verify, run locally · pushes nothing
fixes arrive as branch workseveral read the live siterehearses the gatecheckpoint · save, keep workingpark · save, back to a clean mainland · triage all, merge local, never pushship · push, watch CI, prove it livesuper-ship · drift-audit first, then ship the lot
Zoom outZoom inFit the whole mapExpand the map
States, not steps: the spine has no arrows of its own because the skills are the transitions.
The architecture at runtime
Once the site is live, only the edges matter. Pages come from Vercel with the fonts and the chat corpus already baked in, and a scheduled smoke re-proves production on a cron.
The chat answers through Claude from the published site's corpus, reaching for the generated prop and token contracts when a question needs them; rate limits and a daily budget hold it, and conversations are kept 30 days, tied to no name.
/api/mcp serves agents five tools with no key, no account, and no model behind them: the component list, per-component prop APIs, the token registry, install setup, and site search.
Vercelstatic edge + serverless routes
publicVisitor's browsergtag + the WebGL background run here
monitoringGoogle Analytics 4off until a measurement ID is set
font_downloadGoogle Fontstheme faces, fetched on use
smart_toyAgents + MCP clientsconnect with one URL, no key
GitHub Actions cronthe uptime workflow
Static + ISR pagesfonts, corpus and gtag baked in at build
forum/api/chatfollowups · feedback · guardrails
hub/api/mcpgenerated data from memory · no model, no auth
HTML + assetschatevents go straight to Googlea face downloads when a theme uses itMCP toolssmokes production on a cronmodel callslog + budget + ratepolls
Zoom outZoom inFit the whole mapExpand the map
A space diagram, no time in it: who talks to whom once the site is live.
How the chat answers
The chat's context is deliberate. The site corpus carries everything published as prose, cached for an hour, so most questions are answered from context alone. The generated contracts stay out of it: for a prop's type or default, or a token count, the model calls two lookup tools that read the same in-memory data /api/mcp serves to agents, and the lookup surfaces in the widget as a trace point. The corpus makes the chat fluent; the tools keep it exact.
/api/chat · one exchangestreams the whole way
personVisitorthe chat widget, on any page
verified_userGuardrailsper-visitor rate + daily budget · pick the model tier
menu_bookSystem contextpersona + the whole site corpus · cached 1h
storageGenerated contractsprop API + token registry, read from memory
Anthropic APIClaude answers from the corpus, and asks for a lookup when contracts matter
hub/api/mcpthe same lookups, served to agents
question + the last 10 turnsone streamed model calla prop or token question triggers a lookupin-memory readtool result, then the answerthe answer streams back · lookups show as trace pointsshared implementations
Zoom outZoom inFit the whole mapExpand the map
One exchange, zoomed in. The teal edge is the moment the model stops answering from prose and reads the contract.
Figma
Claude Code
GitHub
Storybook
Vite
Next.js
Vercel
npm
Google