Design System Map
The design map turns visual work into an ordered operating stack: intent, system, components, motion, sources, and proof.
Use this page before creating, merging, or splitting a design article. Use Design System when the task is "what UI system should this product obey?" Use this page when the task is "where does this design knowledge belong, and what should it work with?"
Operating Order
Design work in this wiki should move through this sequence:
- Surface type - operational app, agent console, marketing page, docs, portfolio, visual essay, dashboard, or reference page.
- Intent and methodology - what decision the interface helps a user make and which discovery/system/evaluation lens applies.
- Art direction - style vocabulary, visual thesis, material thesis, type voice, density, and motion appetite.
- System contract -
DESIGN.md, tokens, components, states, accessibility, and enforcement. - Source shelf - component libraries, design references, motion/effect sources, font/type sources, and asset provenance.
- Rendered proof - browser screenshots, viewport checks, interaction states, reduced-motion behavior, and visual-doctor review when stakes are high.
The wiki should encode design as constraints and examples, not as vibes. References only become durable when they change future decisions.
Design Families
Create Or Fold
Create a new design page when the subject is a durable design decision, visual system, implementation source, browser primitive, reference ledger, or repeatable proof workflow. Fold it into an existing page when it is only a one-off example, a single screenshot with no reusable rule, a variant of an already-covered CSS primitive, or a tool that belongs in Component Library Sources.
If a source is primarily a tool, file its factual/tool page in wiki/tools/ and link it from the relevant design shelf. If it primarily changes visual-system decisions, keep the synthesis here.
No-Merge Ledger
| Pages | Keep separate because |
|---|---|
| Design System, Design Tokens, Sigil Token Architecture, Reticle Design System, and DESIGN.md | They sit at different layers: house UI contract, token theory, Sigil implementation, Reticle visual grammar, and persistent agent-readable identity spec. |
| Website Design Styles, Aesthetic Systems, Design Methodology Atlas, Frontend Tactics Atlas, and Prompt Recipes | They answer different stages: style vocabulary, art direction, thinking model, tactic selection, and agent prompt shape. |
| Component Library Sources and individual source pages such as Astryx Design System, Cloudflare Kumo, Motion Primitives, and Shadcn Registry Directory (Top Blocks) | The shelf owns selection; individual pages own source-specific evidence and adoption rules. |
| CSS primitive pages such as CSS Container Queries, CSS Anchor Positioning, CSS text-box-trim, CSS View Transitions API, and Scroll-Driven Animations (CSS) | Each primitive changes a different implementation decision and should remain searchable by exact browser feature. |
| Dashboard Design System, Technical Illustration System, Frontend and Design Skills, and Landing Page Variants & Reticle Expansion | These are reusable pattern systems, not generic inspiration snippets. |
| Design Inspiration Galleries, Niche UI Inspiration Galleries, Product Site Reference Gallery, Personal Website References, Design Agencies Reference, and X Bookmarks: Design & UI (Feb–Jun 2026) | Each is a different evidence shelf: whole-site galleries, component galleries, product sites, personal sites, agency benchmarks, and source-critical bookmark ledger. |
Frontend and Design Skills in wiki/design/ and executable frontend skills |
The design page preserves the readable design philosophy and signals; executable skills own run procedure. |
Page Contract
Every durable design article should make these visible:
| Field | Standard |
|---|---|
| Design family | Which family in this map owns the page. |
| Use when | The decision or task that should open the page. |
| System relationship | How it relates to Design System, Design Tokens, Component Library Sources, or proof workflows. |
| Constraints | What should be enforced in tokens, components, CSS, skills, or project rules. |
| Proof | How rendered output should be checked: screenshot, browser state, accessibility, performance, or visual doctor. |
| Evidence | Timeline entries, source links, artifacts, or longform ledgers when the source trail matters. |
Short source pages can satisfy this with a compact Design Position section. Long reference ledgers can keep the evidence body intact and add a short orientation section near the top.
Update Rule
When a design article changes:
- Update the article and its
Design Position. - Update Design Pack when the route or canonical page map changes.
- Update this map when a family, merge decision, or page contract changes.
- Update Filing Decision Tree and Design Filing if directory placement rules changed.
- Run
npm run build-index,qmd update,qmd embed, and routing/quality checks when generated surfaces or routing changed.
Timeline
- 2026-07-03 | Routed Website Design Styles into the Method, tactics, and prompting family so style names become constraints before tokens/components/proof. Source: User request, 2026-07-03
- 2026-07-01 | Added the design category map during the full design refresh so design articles share explicit families, merge boundaries, and a page contract. Source: User request, 2026-07-01