--- title: "Claude Code Design System: 4 Parts for On-Brand UI" canonical: https://wavect.io/blog/claude-code-design-system-files/ language: en description: "Build a Claude Code design system with REFERENCE.md, CLAUDE.md, DESIGN.md and examples. Get prompts, QA checks and a practical rollout plan for product teams." image: "https://wavect.io/img/blog/headers/header_claude-code-design-system-files.png" --- [**Back**](/blog/overview/) [![Kevin Riedl](/img/team/kevin.webp)](/team/kevin-riedl/) [Kevin Riedl](/team/kevin-riedl/) https://linkedin.com/in/wsdt 11 min read · 2 Sep 2026 Last reviewed September 2, 2026 [**Next**](/blog/ai-coding-agents-context-not-intelligence/) # Claude Code Design System: 4 Parts for On-Brand UI TL;DR A Claude Code design system can live in a four-part repository workflow: REFERENCE.md records visual evidence and non-negotiable brand rules, CLAUDE.md tells Claude when to load and verify those rules, DESIGN.md translates them into implementation-ready tokens and component decisions, and examples/ preserves approved work to reuse. Only CLAUDE.md is a native Claude Code instruction mechanism; the other names are useful project conventions, not Anthropic requirements. Start with real work, separate observed facts from chosen rules, name tokens by role, request several variants, and validate the result with screenshots, accessibility checks and automated tests. For teams, assign owners, version the files and pilot the workflow on representative tasks before making it a standard. **A Claude Code design system is a repository-level context stack that tells the agent what your brand looks like, how to implement it and how to check the result.** A practical version uses three Markdown files plus an `examples/` directory. It replaces repeated brand prompts with versioned evidence, rules and approved patterns. The workflow came to wider attention through Charlie Hills's [four-part brand system and prompt set](https://charliehills.substack.com/p/ai-design-system). The useful idea is not that these filenames are magic. It is that an agent performs better when visual evidence, implementation rules and quality checks are durable project inputs rather than instructions buried in a chat. This guide turns that idea into a workflow a product team can review, test and maintain. It targets the long-tail question **how to make Claude Code follow a design system**. It does not compete with our broader article on [context engineering for coding agents](/blog/ai-coding-agents-context-not-intelligence/) or our production-focused [AI-generated software checklist](/blog/vibe-code-production-readiness-checklist/). ## What are the four parts of a Claude Code design system? | Part | Job | What belongs there | What does not | | --- | --- | --- | --- | | `REFERENCE.md` | Evidence | Observed colors, type, spacing, logo use, recurring layouts and prohibited patterns | Unverified guesses or implementation code | | `CLAUDE.md` | Routing | A short instruction to read the design sources before UI work and verify the output afterward | The entire brand manual | | `DESIGN.md` | Implementation contract | Semantic tokens, component rules, responsive behavior, accessibility requirements and decisions | A mood board with vague adjectives | | `examples/` | Approved patterns | Representative screens or assets that your team owns and can reuse | An uncurated dump of inspiration | Strictly speaking, this is a four-part system, not four files. The fourth part is a directory. Only `CLAUDE.md` has special meaning to Claude Code. Anthropic's [Claude Code memory documentation](https://code.claude.com/docs/en/memory) says project-level `CLAUDE.md` files are loaded as persistent instructions and recommends keeping them specific, concise and well structured. `REFERENCE.md`, `DESIGN.md` and `examples/` work because you explicitly point Claude at them. ## How should the project be structured? ``` your-project/ ├── CLAUDE.md ├── REFERENCE.md ├── DESIGN.md ├── examples/ │ ├── README.md │ ├── dashboard-approved.png │ ├── landing-page-approved.png │ └── pricing-card-approved.html ├── src/ └── tests/ ``` Add an `examples/README.md` with one row per artifact: owner, approval date, source, reusable elements and known exceptions. This small manifest stops an old campaign asset or experimental screen from quietly becoming a permanent product rule. ## Prompt 1: turn approved work into REFERENCE.md Choose three to five examples that already represent the brand well. Prefer your own production screens, brand deck, marketing graphics or component library. Do not copy a competitor's protected assets into the repository. Inspiration can inform a decision, but the reusable examples should be work you own or have permission to use. ``` Review every file in examples/. Separate what you can observe from what you must ask. Draft REFERENCE.md with: 1. source inventory and approval status 2. colors with sampled values and observed roles 3. typography, sizes and hierarchy 4. spacing, grid and alignment patterns 5. logo placement and clear-space rules 6. recurring components and compositions 7. five patterns this brand must avoid 8. unresolved questions Do not invent missing values. Show the draft before saving it. ``` The strongest output distinguishes evidence from policy. “The three approved screens use 24 px between cards” is an observation. “All card groups must use 24 px” is a rule that a human should approve. Mixing the two turns accidental legacy choices into doctrine. ## Prompt 2: make CLAUDE.md route design work Keep the pointer short. A large instruction file consumes context every session, while the detailed design material only matters during interface work. ``` ## Interface work Before creating or changing UI, read REFERENCE.md and DESIGN.md, then inspect the closest approved example in examples/. Use existing components and semantic tokens before adding new ones. If the sources conflict or do not cover a consequential choice, ask instead of guessing. Before completion, compare the rendered result with the design rules and report every intentional exception. ``` This routing layer should say when to read, what has priority and how to verify. If your project already has a long `CLAUDE.md`, use a path-scoped rule for frontend files or a short import. Note that an import improves organization but still loads the imported text at launch, according to Anthropic's documentation. ## Prompt 3: convert the reference into DESIGN.md `DESIGN.md` is the build contract. The emerging [Google Labs DESIGN.md format](https://github.com/google-labs-code/design.md/blob/main/docs/spec.md) describes a self-contained file with optional machine-readable tokens in YAML frontmatter and human-readable design rationale in Markdown. You can follow that format for portability, but Claude Code does not require it. ``` Read REFERENCE.md and examples/README.md, then inspect every approved example. Draft DESIGN.md as an implementation contract with: 1. semantic color tokens named by job, not hue 2. type and spacing scales with exact values 3. layout, grid and breakpoint rules 4. component anatomy, states and reuse policy 5. interaction, motion and reduced-motion behavior 6. accessibility requirements 7. responsive examples and edge cases 8. a decision log with date, owner and reason Flag every rule that is inferred rather than approved. Ask where sources disagree. Show the file before saving it. ``` Role-based names survive a redesign better than visual names. `color-text-primary` explains intent; `dark-gray` only describes the current value. If tokens also need to travel into design and build tools, keep a machine-readable token source beside the narrative file. ## Why do examples matter more than a longer prompt? Rules tell an agent what is allowed. Approved examples show proportion, density, hierarchy and composition working together. Anthropic gives similar advice for its separate Claude Design product: its [official design-system setup guide](https://support.claude.com/en/articles/14604397-set-up-your-design-system-in-claude-design) accepts codebases, prototypes, decks and brand assets, and recommends including real examples instead of only specifications. Choose examples by coverage, not volume. One dense dashboard, one marketing page, one form-heavy flow and one mobile state usually teach more than fifty nearly identical hero sections. Each example should answer a question that the text alone leaves ambiguous. ## Should DESIGN.md replace design tokens? **No. DESIGN.md explains design intent; a token file gives tools a strict interchange format.** Use both when values must flow into code, design tools and validation. The stable [Design Tokens Community Group format](https://www.designtokens.org/tr/2025.10/format/) defines a JSON model for token names, values, types and metadata. Let that file own exact machine values, then have DESIGN.md explain when and why to apply them. ## How do you stop the system from copying mistakes? 1. **Label every source.** Mark it approved, historical, experimental or inspiration-only. 2. **Set precedence.** Current tokens beat screenshots for exact values. A reviewed component beats an old marketing graphic for interaction behavior. 3. **Record exceptions.** If a campaign intentionally breaks the grid, say so in the manifest. 4. **Require variants.** Ask for three alternatives before polishing. Selection is a human design decision. 5. **Promote only reviewed patterns.** Add the chosen result to `examples/` after approval, not after generation. The directory should grow slowly. A library of approved patterns compounds consistency; a library of every output compounds errors. ## What should the validation loop check? | Check | Method | Failure signal | | --- | --- | --- | | Token use | Lint CSS or theme references | Hard-coded colors, spacing or type values without an approved exception | | Component reuse | Review imports and rendered states | A near-duplicate component appears instead of extending the owner | | Responsive behavior | Capture representative desktop and mobile screenshots | Overflow, collapsed hierarchy or missing states | | Accessibility | Automated checks plus keyboard and screen-reader review | Contrast, focus, labels, motion or interaction failures | | Visual consistency | Side-by-side review against the closest approved example | Unexplained drift in density, alignment, type or composition | | Product correctness | Acceptance tests and human review | The interface looks right but solves the wrong task | Do not ask the producing agent to be the only judge. Let it run the first comparison, then use deterministic checks and a person with approval authority. The output should include changed rules, intentional exceptions and evidence from the test run. ## Claude Code files vs Claude Design: which should you use? | Need | Repository workflow | Claude Design | | --- | --- | --- | | Versioned rules next to code | Strong fit | Export or sync may be needed | | Use existing components during implementation | Strong fit | Useful when connected to the codebase | | Shared visual ideation for non-developers | Requires a repository workflow | Stronger fit | | Deterministic CI checks | Strong fit | Run checks in the code repository | | Organization-wide managed UI kit | Requires governance you build | Built for shared organization systems | They can complement each other. Claude Design can help teams explore and publish a shared system, while the repository keeps implementation rules, components and tests close to production code. ## How should a team roll this out? 1. **Select representative work.** Cover product UI, marketing and at least one difficult state. 2. **Draft and review the two source files.** Design owns the visual truth; engineering owns implementation feasibility. 3. **Wire the routing rule.** Keep `CLAUDE.md` short and test that Claude actually loads the sources. 4. **Pilot three task types.** Try a new component, an existing screen change and a responsive repair. 5. **Measure rework.** Track review rounds, unapproved tokens, duplicate components, accessibility defects and accepted first-pass changes. 6. **Assign maintenance.** Name owners for tokens, components, examples and the decision log. For a company rollout, the purchase decision is not “Which prompt pack should we buy?” It is “Who owns the design contract, how is compliance tested and which changes require approval?” Wavect's [AI enablement service](/services/ai-enablement/) can help teams turn ad hoc agent use into a governed workflow with repository context, evaluations and review gates. If the generated product already needs hardening, use the [prototype-to-production decision guide](/software-development-guide/vibe-coded-prototype-to-production/) to scope the next step. ## Frequently asked questions ### Does Claude Code read DESIGN.md automatically? No. Claude Code automatically loads supported CLAUDE.md instruction files. Tell it explicitly in CLAUDE.md when to read DESIGN.md and REFERENCE.md, then verify with the memory view or an observed task run. ### Is DESIGN.md an official Anthropic standard? No. It is a project convention and an emerging open format from Google Labs. Claude Code can use any readable filename when your instructions point to it. ### Should REFERENCE.md contain brand rules or observations? Start with observations and label their sources. Turn them into mandatory rules only after a human owner approves them. This prevents accidental patterns from becoming permanent policy. ### How many examples should I give Claude Code? Start with three to five approved examples that cover different interface problems. Add another only when it resolves a recurring ambiguity. Coverage and provenance matter more than volume. ### Can this replace a real component library? No. The files explain decisions and route the agent. Production consistency still comes from reusable components, machine-readable tokens, automated checks and human ownership. ## Research boundary *Reviewed on 2 September 2026 against the original workflow, current Claude Code memory documentation, the Google Labs DESIGN.md specification, Anthropic's Claude Design guidance and the stable Design Tokens Community Group format. Product behavior and beta availability can change. We make no quantified productivity claim because this workflow has no independent cross-team benchmark.* ## Final thoughts The durable advantage is not a clever prompt. It is a small, reviewable system that separates evidence, instructions, implementation rules and approved examples. Start with work your team already trusts. Make uncertainty visible, keep the routing layer short and test the rendered output. Claude can hold the rules consistently. People still decide whether those rules are good. ## You may also like.. [**Coding Agents Need Context, Not More Intelligence** See why durable repository context, focused tasks and independent verification matter beyond visual design.](/blog/ai-coding-agents-context-not-intelligence/) [**AI Enablement vs Generic AI Consulting** Compare a governed implementation workflow with a strategy-only engagement.](/compare/ai-enablement-vs-generic-ai-consultancy/) Agent engineering ## Continue through this cluster Coding agents, MCP, context systems, evaluation and the controls required for dependable automation. [Start with the cornerstone**Graph Engineering for AI Agents: When Does a Knowledge Graph Pay Off?**](/blog/graph-engineering-ai-agents/) - [Obscura Browser Review: Claims, Limits and Production Fit](/blog/obscura-rust-browser-ai-agents/) - [ChatGPT Can Now Log In Without Seeing Your Password](/blog/chatgpt-cloud-browser-secure-login/) - [AI Agent Harness, Explained: The Reliability Layer Around an LLM](/blog/agent-harness-engineering/) - [Why Agent Edits Need Semantic Identity: Building SEMAPRAX in Rust](/blog/semantic-identity-rust-agent-edits/) - [LangChain Deep Agents Review: Is the Agent Harness Ready for Production?](/blog/langchain-deep-agents-review/) [**Back**](/blog/overview/) [![Kevin Riedl](/img/team/kevin.webp)](/team/kevin-riedl/) [Kevin Riedl](/team/kevin-riedl/) https://linkedin.com/in/wsdt 11 min read · 2 Sep 2026 Last reviewed September 2, 2026 [**Next**](/blog/ai-coding-agents-context-not-intelligence/) ## Structured Data ```json { "@context": "https://schema.org", "@graph": [ { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ], "employee": [ { "@id": "https://wavect.io/team/kevin-riedl/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Kevin Riedl", "url": "https://wavect.io/team/kevin-riedl/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } }, { "@id": "https://wavect.io/team/christof-jori/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Christof Jori", "url": "https://wavect.io/team/christof-jori/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } } ], "founder": [ { "@id": "https://wavect.io/team/kevin-riedl/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Kevin Riedl", "url": "https://wavect.io/team/kevin-riedl/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } }, { "@id": "https://wavect.io/team/christof-jori/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Christof Jori", "url": "https://wavect.io/team/christof-jori/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } } ], "legalRepresentative": [ { "@id": "https://wavect.io/team/kevin-riedl/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Kevin Riedl", "url": "https://wavect.io/team/kevin-riedl/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } }, { "@id": "https://wavect.io/team/christof-jori/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Christof Jori", "url": "https://wavect.io/team/christof-jori/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } } ], "name": "Wavect GmbH", "subjectOf": { "@id": "https://wavect.io/verified-claims.json#dataset", "@type": "Dataset", "creator": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] }, "description": "A machine-readable registry of quantitative and qualitative claims published by Wavect, with review dates, localized page appearances and public third-party citations where available.", "inLanguage": "en", "isAccessibleForFree": true, "license": "https://creativecommons.org/licenses/by/4.0/", "name": "Wavect verified publication claims", "url": "https://wavect.io/verified-claims.json" }, "url": "https://wavect.io/" }, { "@id": "https://wavect.io/team/kevin-riedl/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Kevin Riedl", "sameAs": [ "https://www.wikidata.org/wiki/Q139796365", "https://www.linkedin.com/in/wsdt", "https://github.com/wsdt" ], "url": "https://wavect.io/team/kevin-riedl/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } }, { "@id": "https://wavect.io/team/christof-jori/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Christof Jori", "sameAs": [ "https://www.wikidata.org/wiki/Q139796367", "https://www.linkedin.com/in/jocr77/", "https://github.com/jo-chris" ], "url": "https://wavect.io/team/christof-jori/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } }, { "@id": "https://wavect.io/#website", "@type": "WebSite", "inLanguage": [ "en", "de", "es", "zh" ], "name": "Wavect", "potentialAction": { "@type": "SearchAction", "query-input": "required name=search_term_string", "target": { "@type": "EntryPoint", "urlTemplate": "https://wavect.io/search/?q={search_term_string}" } }, "publisher": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] }, "url": "https://wavect.io/" }, { "@id": "https://wavect.io/blog/claude-code-design-system-files/#webpage", "@type": "WebPage", "dateModified": "2026-09-02", "inLanguage": "en", "isPartOf": { "@id": "https://wavect.io/#website", "@type": "WebSite" }, "lastReviewed": "2026-09-02", "url": "https://wavect.io/blog/claude-code-design-system-files/" } ] } ``` ```json { "@context": "https://schema.org", "@type": "BlogPosting", "abstract": "A Claude Code design system can live in a four-part repository workflow: REFERENCE.md records visual evidence and non-negotiable brand rules, CLAUDE.md tells Claude when to load and verify those rules, DESIGN.md translates them into implementation-ready tokens and component decisions, and examples/ preserves approved work to reuse. Only CLAUDE.md is a native Claude Code instruction mechanism; the other names are useful project conventions, not Anthropic requirements. Start with real work, separate observed facts from chosen rules, name tokens by role, request several variants, and validate the result with screenshots, accessibility checks and automated tests. For teams, assign owners, version the files and pilot the workflow on representative tasks before making it a standard.", "articleBody": " Blog overview/AI and agents/Agent engineering Claude Code Design System: 4 Parts for On-Brand UI TL;DR A Claude Code design system can live in a four-part repository workflow: REFERENCE.md records visual evidence and non-negotiable brand rules, CLAUDE.md tells Claude when to load and verify those rules, DESIGN.md translates them into implementation-ready tokens and component decisions, and examples/ preserves approved work to reuse. Only CLAUDE.md is a native Claude Code instruction mechanism; the other names are useful project conventions, not Anthropic requirements. Start with real work, separate observed facts from chosen rules, name tokens by role, request several variants, and validate the result with screenshots, accessibility checks and automated tests. For teams, assign owners, version the files and pilot the workflow on representative tasks before making it a standard. A Claude Code design system is a repository-level context stack that tells the agent what your brand looks like, how to implement it and how to check the result. A practical version uses three Markdown files plus an examples/ directory. It replaces repeated brand prompts with versioned evidence, rules and approved patterns. The workflow came to wider attention through Charlie Hills's four-part brand system and prompt set. The useful idea is not that these filenames are magic. It is that an agent performs better when visual evidence, implementation rules and quality checks are durable project inputs rather than instructions buried in a chat. This guide turns that idea into a workflow a product team can review, test and maintain. It targets the long-tail question how to make Claude Code follow a design system. It does not compete with our broader article on context engineering for coding agents or our production-focused AI-generated software checklist. What are the four parts of a Claude Code design system? PartJobWhat belongs thereWhat does not REFERENCE.mdEvidenceObserved colors, type, spacing, logo use, recurring layouts and prohibited patternsUnverified guesses or implementation code CLAUDE.mdRoutingA short instruction to read the design sources before UI work and verify the output afterwardThe entire brand manual DESIGN.mdImplementation contractSemantic tokens, component rules, responsive behavior, accessibility requirements and decisionsA mood board with vague adjectives examples/Approved patternsRepresentative screens or assets that your team owns and can reuseAn uncurated dump of inspiration Strictly speaking, this is a four-part system, not four files. The fourth part is a directory. Only CLAUDE.md has special meaning to Claude Code. Anthropic's Claude Code memory documentation says project-level CLAUDE.md files are loaded as persistent instructions and recommends keeping them specific, concise and well structured. REFERENCE.md, DESIGN.md and examples/ work because you explicitly point Claude at them. How should the project be structured? your-project/ ├── CLAUDE.md ├── REFERENCE.md ├── DESIGN.md ├── examples/ │ ├── README.md │ ├── dashboard-approved.png │ ├── landing-page-approved.png │ └── pricing-card-approved.html ├── src/ └── tests/ Add an examples/README.md with one row per artifact: owner, approval date, source, reusable elements and known exceptions. This small manifest stops an old campaign asset or experimental screen from quietly becoming a permanent product rule. Prompt 1: turn approved work into REFERENCE.md Choose three to five examples that already represent the brand well. Prefer your own production screens, brand deck, marketing graphics or component library. Do not copy a competitor's protected assets into the repository. Inspiration can inform a decision, but the reusable examples should be work you own or have permission to use. Review every file in examples/. Separate what you can observe from what you must ask. Draft REFERENCE.md with: 1. source inventory and approval status 2. colors with sampled values and observed roles 3. typography, sizes and hierarchy 4. spacing, grid and alignment patterns 5. logo placement and clear-space rules 6. recurring components and compositions 7. five patterns this brand must avoid 8. unresolved questions Do not invent missing values. Show the draft before saving it. The strongest output distinguishes evidence from policy. “The three approved screens use 24 px between cards” is an observation. “All card groups must use 24 px” is a rule that a human should approve. Mixing the two turns accidental legacy choices into doctrine. Prompt 2: make CLAUDE.md route design work Keep the pointer short. A large instruction file consumes context every session, while the detailed design material only matters during interface work. ## Interface work Before creating or changing UI, read REFERENCE.md and DESIGN.md, then inspect the closest approved example in examples/. Use existing components and semantic tokens before adding new ones. If the sources conflict or do not cover a", "articleSection": "Engineering", "author": { "@id": "https://wavect.io/team/kevin-riedl/#person", "@type": "Person", "name": "Kevin Riedl", "sameAs": [ "https://www.wikidata.org/wiki/Q139796365", "https://www.linkedin.com/in/wsdt", "https://github.com/wsdt" ], "url": "https://wavect.io/team/kevin-riedl/" }, "citation": [ { "@type": "WebPage", "name": "four-part brand system and prompt set", "url": "https://charliehills.substack.com/p/ai-design-system" }, { "@type": "WebPage", "name": "Claude Code memory documentation", "url": "https://code.claude.com/docs/en/memory" }, { "@type": "WebPage", "name": "Google Labs DESIGN.md format", "url": "https://github.com/google-labs-code/design.md/blob/main/docs/spec.md" }, { "@type": "WebPage", "name": "official design-system setup guide", "url": "https://support.claude.com/en/articles/14604397-set-up-your-design-system-in-claude-design" }, { "@type": "WebPage", "name": "Design Tokens Community Group format", "url": "https://www.designtokens.org/tr/2025.10/format/" } ], "dateModified": "2026-09-02", "datePublished": "2026-09-02", "description": "A Claude Code design system can live in a four-part repository workflow: REFERENCE.md records visual evidence and non-negotiable brand rules, CLAUDE.md tells Claude when to load and verify those rules, DESIGN.md translates them into implementation-ready tokens and component decisions, and examples/ preserves approved work to reuse. Only CLAUDE.md is a native Claude Code instruction mechanism; the other names are useful project conventions, not Anthropic requirements. Start with real work, separate observed facts from chosen rules, name tokens by role, request several variants, and validate the result with screenshots, accessibility checks and automated tests. For teams, assign owners, version the files and pilot the workflow on representative tasks before making it a standard.", "headline": "Claude Code Design System: 4 Parts for On-Brand UI", "image": "https://wavect.io/img/blog/headers/header_claude-code-design-system-files.svg", "inLanguage": "en", "keywords": "AI Engineering, Design Systems", "mainEntityOfPage": { "@id": "https://wavect.io/blog/claude-code-design-system-files/", "@type": "WebPage" }, "publisher": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] }, "url": "https://wavect.io/blog/claude-code-design-system-files/", "wordCount": 2228 } ``` ```json { "@context": "https://schema.org", "@type": "BreadcrumbList", "itemListElement": [ { "@type": "ListItem", "item": "https://wavect.io/", "name": "Home", "position": 1 }, { "@type": "ListItem", "item": "https://wavect.io/blog/overview/", "name": "Blog overview", "position": 2 }, { "@type": "ListItem", "item": "https://wavect.io/blog/topics/ai-agents/", "name": "AI and agents", "position": 3 }, { "@type": "ListItem", "item": "https://wavect.io/blog/clusters/agent-engineering/", "name": "Agent engineering", "position": 4 }, { "@type": "ListItem", "item": "https://wavect.io/blog/claude-code-design-system-files/", "name": "Claude Code Design System: 4 Parts for On-Brand UI | ", "position": 5 } ] } ``` ```json { "@context": "https://schema.org", "@type": "FAQPage", "mainEntity": [ { "@type": "Question", "acceptedAnswer": { "@type": "Answer", "text": "No. Claude Code automatically loads supported CLAUDE.md instruction files. Tell it explicitly in CLAUDE.md when to read DESIGN.md and REFERENCE.md, then verify with the memory view or an observed task run." }, "name": "Does Claude Code read DESIGN.md automatically?" }, { "@type": "Question", "acceptedAnswer": { "@type": "Answer", "text": "No. It is a project convention and an emerging open format from Google Labs. Claude Code can use any readable filename when your instructions point to it." }, "name": "Is DESIGN.md an official Anthropic standard?" }, { "@type": "Question", "acceptedAnswer": { "@type": "Answer", "text": "Start with observations and label their sources. Turn them into mandatory rules only after a human owner approves them. This prevents accidental patterns from becoming permanent policy." }, "name": "Should REFERENCE.md contain brand rules or observations?" }, { "@type": "Question", "acceptedAnswer": { "@type": "Answer", "text": "Start with three to five approved examples that cover different interface problems. Add another only when it resolves a recurring ambiguity. Coverage and provenance matter more than volume." }, "name": "How many examples should I give Claude Code?" }, { "@type": "Question", "acceptedAnswer": { "@type": "Answer", "text": "No. The files explain decisions and route the agent. Production consistency still comes from reusable components, machine-readable tokens, automated checks and human ownership." }, "name": "Can this replace a real component library?" } ] } ```