--- prompt-id: "07" name: Domain components — product-specific components under archetype rules status: live mcp: none model: Sonnet 4.6 environment: Claude.ai or Claude Code inputs: - output/tokens.css - output/components/foundation.css - output/components/composite.css - specs/.spec.md - user-provided: 2-sentence description of each domain component outputs: - output/components/domain.css chains: [3, 9] prereqs: ["03", "04"] documented-in: Ch09 — Domain Components --- # Prompt 07 — Domain components Generates net-new components unique to your product — generated under the active archetype's visual rules so they look native to the rest of the design system. --- ``` ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ META-HEADER — run before generating any CSS ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ STEP -2 — DETECT ENVIRONMENT Claude Code: save automatically to output/components/domain.css Claude.ai: provide copy-paste instructions at save point. STEP -1 — CONTEXT CHECK output/tokens.css → REQUIRED output/components/foundation.css → REQUIRED output/components/composite.css → REQUIRED specs/.spec.md → REQUIRED output/chain-state.md → read if present STEP 0 — COLLECT DOMAIN COMPONENT DESCRIPTIONS Before generating any CSS, ask the user: "Domain components are unique to your product. Please describe each one you need in 1-2 sentences — the more specific, the better I can generate on-archetype CSS. Example: Policy editor: a two-panel component with a rule-tree list on the left and a detail/edit form on the right. Users expand rule groups and click rules to edit them inline. List all domain components you need, then say 'go'." Wait for the user's response. Do not proceed until you have at least one component description. ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ MAIN PROMPT BODY ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ PROMPT 07 — DOMAIN COMPONENT CSS YOUR ROLE You are generating bespoke components that live inside an existing design system. Your goal is zero visual discontinuity: domain components must look like they grew from the same tokens and archetype constraints as the foundation/composite set. Never introduce new design decisions — if a pattern exists in the foundation or composite set, reference it. If a token is missing, flag it rather than hardcode a value. GENERATION RULES — apply to every domain component 1. COMPOSITION FIRST Before writing any CSS, identify which foundation or composite components the domain component contains: — List-detail → uses Card + foundation Table or list items — Policy editor → uses list items + foundation Form groups — Timeline → uses Badge (status) + dividers Reference those class names as expected children in your CSS. Do not re-implement what foundation.css already defines. 2. TOKEN CONTRACT Every value traces to tokens.css. No raw hex, no px literals. Flag any gap as: /* MISSING TOKEN: --expected-token-name */ 3. ARCHETYPE COMPLIANCE Apply the archetype's VISUAL LANGUAGE rules: — Radius, shadow depth, border weight, colour palette — Typography scale for labels, headings, helper text — Spacing density (compact for Lattice, generous for Meridian) — Dark-first vs light-first surface logic Think: "Would this component look at home next to a Lattice data table?" or "Does this fit a Meridian reading flow?" 4. VARIANTS AND STATES For each domain component, generate: — Base state — All states mentioned in the user description (selected, expanded, empty, loading, error) — Responsive behaviour: what changes below --breakpoint-md? 5. ACCESSIBILITY ANNOTATIONS Add CSS comments noting ARIA requirements the CSS enables: /* requires role="tree" + aria-expanded on group triggers */ /* focus-visible ring: --color-focus-ring, 2px offset */ The CSS does the visual work; annotate the semantic layer. FOR EACH DOMAIN COMPONENT THE USER DESCRIBES: a. Restate the user's description as a comment at the top of that component's section. b. Identify foundation/composite dependencies. c. List the states and variants you will generate. d. Emit the CSS with the token pre-flight: - Token list → confirm each exists in tokens.css - Flag any gaps - Emit CSS COMMON DOMAIN COMPONENT PATTERNS (reference only — generate what the user requested, not this list): Policy / rule editor — tree list + detail form Timeline / audit log — vertical event stream + badges Kanban board — swim-lane columns + draggable cards Data chart wrapper — canvas/svg container + legend Metric tile — KPI number + spark + label Approval flow — stepper + status badges + actions File upload zone — drag-and-drop area + file list Mention picker — input + avatar dropdown Rich text editor — toolbar + content area + word count Pricing table — feature comparison + CTA columns Split-pane editor — resizable two-column layout Notification inbox — list of notification rows + bulk actions Each of these composes foundation + composite pieces rather than inventing new visual primitives. OUTPUT FORMAT /* ── 07 DOMAIN COMPONENTS ──────────────────────────────────── */ /* ── [Component name from user description] ─────────────────── */ /* User description: ... */ /* Dependencies: foundation.css: .card, .input; composite.css: .accordion */ ... One continuous CSS file. No HTML, no JS, no @import. ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ META-FOOTER ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ SAVE INSTRUCTION Save as: output/components/domain.css CHAIN-STATE LOG Append to output/chain-state.md: ## Prompt 07 — Domain components Date: Archetype: Domain components generated: Output: output/components/domain.css Token gaps flagged: HANDOFF "Domain components done. Next → Prompt 08 — Spec page (generates the living component documentation page from all your CSS files). No additional inputs needed beyond what you've already generated." ```