Design system — the system follows solutions

Any project that ships a repeatable form accumulates a design system: tokens/ variables (color, type, spacing, motion — or a channel's palette and cover grid), components/templates (UI parts, thumbnail layouts, packaging, letter formats) and a catalog (Storybook for digital — see STACKS; a template library or brand book elsewhere). Home: _ops/design-system/ in the repo — tokens as files are the source of truth. Curator = the Design squad lead (or the sole designer).

• Reuse-first gate at spec time. Discussing any solution, the conductor/designer answers explicitly: covered by the existing system, or does it need an extension? Default is reuse; an extension is a deliberate, argued decision recorded in the spec (what's added and why the existing pieces don't fit). The system grows by argument, never as a side effect.
• A system has three origins — build · adopt · inherit. Building your own is the default flow here. Adopting a ready-made host system (Material, Apple HIG, Fluent — or non-digital: a franchise brand book, a publisher style guide, a platform's content format): the host's guidelines become law; CONVENTIONS.md records *host + version
  • our delta layer*. Extensions then live in a separate, documented "our extensions" layer that follows the host's own philosophy and naming — never restyle or reinterpret host semantics, that is exactly how teams drift away from the host. Host ships a new version → treat it like /multica-ops:upgrade: preview the diff and its impact on the delta layer before applying. Inheriting an existing own system (typical at /multica-ops:join): audit-and-prepare exactly like the join delta — inventory tokens/components/templates, verdict per piece (complete / needs additions / needs rework), wire the conventions, only then extend.
• Systematize in the same feature. A shipped solution that introduced new patterns gets a systematization sub-task in that feature: new tokens documented, one-offs promoted to components (or marked exceptions), stale pieces pruned.
• Systematization is conveyor work, with a review. It's built by whichever craft owns the medium — code tokens/Storybook components → an engineer, cover templates → a designer, voice guide → a copywriter — and then passes a systematization review by the curator before merging into the system. Same pattern in every domain: whoever systematizes, the curator reviews.
• One component standard, fixed at enablement. Turning the module on, the curator seeds _ops/design-system/CONVENTIONS.md: naming, one props convention (borrowed from the chosen stack's idioms — e.g. shadcn/Radix patterns for web), state names, and a single documentation shape per component (templates/COMPONENT-template.md: anatomy · props table · variants · states · tokens used · do/don't). Every component — agent- or human-made — is documented to that shape; mixed conventions (one component hook-style, another ad-hoc) are exactly what this kills. Useful skills (find via multica skill search): Storybook, Storybook Component Doc (doc standard), Component Library Audit (catches prop/convention drift), Design System Patterns (token hierarchies). Naming/API reference: component.gallery — real-world design systems and component patterns; consult before inventing component names or APIs. Tokens format: default W3C DTCG JSON under _ops/design-system/tokens/, transformed per platform via Style Dictionary; Figma sync via Tokens Studio; Pen.dev or any other tool → study its token workflow first (see _ops/TOOLING.md).
• Design QA checks against the system: implementations use tokens/components, not hardcoded values; a deviation is either fixed or argued into the system. The owner can add a human checkpoint on system extensions via /multica-ops:mops reviews.
• Assets obey the same conformance: stay within one chosen icon set / illustration style / photo look (mixing reads amateur, exactly as hardcoded values do), widening only on a real gap — and record every shipped asset with its licence in _ops/assets.md (sources and the licence-first rule live in STACKS → Free assets).