# Use website design references inside Codex [Open the live Fudge conversation](https://design.withfudge.com/share/website-design-system-mcp-for-codex) Last updated: 2026-08-25 Codex can use a website design reference more effectively when you give it observed details instead of a vague request to "make it look like" another site. The practical workflow is: choose references, inspect the page structure and visual rules, then give Codex a short implementation brief with the decisions it should preserve. ## A practical workflow Start with two or three references that match the job you are doing. For a marketing page, compare the hero, navigation, calls to action, section spacing, and card treatment. For an application, compare tables, forms, empty states, sidebars, and responsive behavior. Do not copy every detail. Decide which reference answers each design question best. Then turn the references into a checklist: - Page structure: header, hero, content sections, supporting panels, footer - Layout: maximum content width, column count, gaps, alignment, and mobile stacking - Typography: family, available weights, heading scale, body size, line height, and letter spacing - Color roles: page background, surface, text, muted text, borders, accent, success, and danger - Components: button height, radius, padding, border style, shadows, and hover treatment - Content rules: short labels, paragraph width, heading length, and how much information appears above the fold Give Codex the checklist before asking it to write components. This keeps the implementation tied to visible decisions rather than isolated styling guesses. Open the examples below and compare the first screen before borrowing a pattern. The Notion Developer Platform, Claude Code, and Exa MCP Server references are useful prompts for different kinds of developer-facing pages, but the cards alone do not prove that their internal systems are identical. Use them to decide what to inspect, then verify the details you want to carry over. ## Captured pages [![Notion Developer Platform](https://pin.fontofweb.com/9283?format=jpg)](https://design.withfudge.com/share/pin-9283) [Notion Developer Platform](https://design.withfudge.com/share/pin-9283) [![Claude Code](https://pin.fontofweb.com/1446?format=jpg)](https://design.withfudge.com/share/pin-1446) [Claude Code](https://design.withfudge.com/share/pin-1446) [![Exa MCP Server](https://pin.fontofweb.com/6429?format=jpg)](https://design.withfudge.com/share/pin-6429) [Exa MCP Server](https://design.withfudge.com/share/pin-6429) ## What to ask Codex to inspect Ask for a design-system pass before the build pass. A useful request is: identify the page regions, list the recurring component patterns, record typography and color roles, and separate observations from recommendations. This matters because a reference may show a visual result without revealing the exact token name, breakpoint, or implementation choice behind it. For each observation, ask Codex to record: 1. What is visible. 2. Where it appears. 3. How confident the observation is. 4. Whether it should become a reusable token or remain a one-off choice. For example, "cards have a medium corner radius" is an observation. "Use radius-md for every panel" is an implementation decision. Keeping those separate makes later review easier. ## A Codex-ready design brief Paste a brief like this into your agent after reviewing the references: > Build the page using the attached reference notes. Preserve the following priorities in order: clear hierarchy, readable body text, consistent spacing, and restrained use of accent color. Create tokens for page background, surfaces, text, muted text, borders, accent, radii, shadows, and spacing. Use the recorded font family and weights where available. Build shared components for navigation, buttons, cards, form fields, and section headings. Match the reference structure and rhythm, but do not copy brand names, proprietary illustrations, or page content. Before coding, summarize the token values and component states you plan to use. After coding, check desktop and mobile layouts against the reference notes. This gives Codex enough direction to make coherent choices while leaving room for your product's content and accessibility needs. ## A review checklist Before accepting the result, check the page at the same viewport sizes as the references. Look for hierarchy first: can someone identify the page purpose, primary action, and next section quickly? Then check consistency: do buttons share height and radius, do headings use a predictable scale, and do panels align to the same grid? Finally, check the small details that often make a system feel unfinished: font loading, focus states, long labels, narrow screens, empty states, and contrast between muted text and its background. A design reference is most useful when it gives Codex repeatable rules, not just a mood. Keep the final brief short enough to reread during implementation, and update it when you intentionally depart from a reference. ## Use this in your AI agent > Review these website references as design references for a Codex implementation. First list the visible page structure, typography, color roles, spacing rhythm, component patterns, and responsive behaviors. Separate direct observations from recommendations. Then propose a small token set and reusable components for the new page. Preserve the hierarchy and interaction patterns that are relevant to the task, but do not copy brand content or unsupported details. Build the page, check desktop and mobile states, and report any remaining differences or uncertain observations. > > [Install Fudge for your AI agent](/mcp) --- Choose one reference for overall structure, one for typography and spacing, and one for component behavior. Avoid asking Codex to average them together. That usually produces a page with mixed visual signals. Create a short comparison table with columns for structure, type, color, controls, cards, and responsive behavior. For every row, mark one choice as primary and explain why. For example, use one reference's wide editorial layout, another's compact form controls, and your own brand colors. Record values only when you can verify them, and label estimates as estimates. Then ask Codex to convert the selected choices into tokens before it writes page-level CSS. A useful token group includes font families and weights, type sizes, line heights, content widths, spacing steps, radii, border colors, surface colors, and shadow levels. Ask it to use those tokens across shared components instead of placing one-off values in each section. Finish with a contradiction check: ask Codex to list places where the references disagree and choose a rule for resolving each conflict. This prevents a visually polished page from quietly using three different button styles or unrelated spacing scales. --- Ask Codex to review the result in four passes. First, check hierarchy: the page purpose, main action, headings, and supporting content should be easy to identify without reading every word. Second, check consistency: buttons, links, cards, inputs, labels, and headings should use the same token rules wherever their roles match. Third, test stress cases. Use a long heading, a long button label, an empty list, a validation error, a narrow mobile width, and a zoomed text size. These cases reveal whether the design system is real or only works for the sample content. Also check keyboard focus and whether muted text remains readable. Fourth, compare screenshots at matching viewport sizes. Ask Codex to report differences by category: layout, typography, color, spacing, component state, and responsive behavior. Have it fix the highest-impact differences first rather than chasing tiny pixel changes. Keep a final decision log with intentional departures from the references. That gives future Codex sessions a reliable source of truth and prevents the same visual questions from being reconsidered on every change. ## Related questions - [Website design system MCP for Cursor](/share/website-design-system-mcp-for-cursor) - [Use Website Design References in Cline](/share/website-design-system-mcp-for-cline) - [Website design research MCP for Windsurf](/share/website-design-research-mcp-for-windsurf) - [Website Reference MCP for Claude Code](/share/website-reference-mcp-for-claude-code)