# Website design system MCP for GitHub Copilot [Open the live Fudge conversation](https://design.withfudge.com/share/website-design-system-mcp-for-github-copilot) Last updated: 2026-08-25 GitHub Copilot can apply a website design system more reliably when it receives a clear design brief instead of a vague request to copy a page. The useful process is to capture a small set of references, inspect their structure and visual details, convert those observations into rules, and ask Copilot to implement and check the result. ## Start with a focused reference set Choose references for the job at hand. A developer product, documentation site, marketing page, and dashboard may all use different spacing, density, and interaction patterns. Use one primary reference and one supporting reference when possible. Open the examples below and compare the first screen before borrowing a pattern. Notion Developer Platform, Claude Code, and Exa MCP Server are examples of developer-oriented references in this packet, not proof that their choices fit your product. For each reference, record the decisions that Copilot needs: - **Structure:** navigation, hero, supporting copy, feature groups, code examples, calls to action, and footer. - **Layout:** content width, columns, alignment, section rhythm, and responsive stacking. - **Type:** families, display sizes, body sizes, weights, line heights, and text width. - **Color:** background, surfaces, text, muted text, accents, borders, and status colors. - **Components:** buttons, cards, forms, tabs, badges, navigation, and code blocks. - **Finish:** corner radii, border strength, shadows, gradients, image crops, and state changes. This list gives Copilot implementation targets without forcing it to reproduce every visual detail. ## 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) ## Write rules Copilot can follow A good brief has a decision section, a token section, and a component section. In the decision section, describe the intended character in ordinary language: "calm technical interface with compact controls and generous reading space." In the token section, give named roles for size, spacing, color, radius, and shadow values. In the component section, explain how those tokens are used. Separate observed details from adaptations. An observed detail might be a wide content column, a quiet border, or a short hero paragraph. An adaptation might be your brand accent, a different typeface, or a mobile layout that suits your content better. This distinction helps Copilot use the reference as guidance rather than treating it as an exact specification. Put the brief where the project already keeps working guidance, such as a design notes file or contributor instructions. Keep the scope explicit: name the route, components, and files Copilot may change. Ask it to reuse existing components and tokens before creating new ones. ## A useful Copilot request Ask for a plan before broad edits. For example: > Review the design brief and the existing page. Propose the smallest set of component and token changes needed to apply the system. Preserve routing, content, and behavior. Identify any conflicts between the reference and the current codebase. After approval, implement the changes, check responsive states and keyboard focus, and summarize the files changed. For a new page, include the content hierarchy and the required action. For a redesign, include what must not change. If the project uses Tailwind v4, CSS variables, or an existing component library, name that convention and ask Copilot to use it rather than adding competing styles. A website reference tool can also help turn observed details into Tailwind v4, CSS, JSON, or DESIGN.md notes before implementation. Review those notes first, then provide the relevant subset to Copilot. This keeps the coding request focused and makes it easier to compare the result with the intended system. You can [use Fudge with your AI agent](/mcp) when you want website observations available alongside the coding task. ## Review checklist - Does the page still meet its original user goal? - Are repeated elements controlled by shared rules? - Do desktop and mobile layouts preserve hierarchy and action order? - Are typography, contrast, focus, hover, disabled, and error states readable? - Did Copilot preserve existing routes, content, and interactions? - Did it create unnecessary one-off values or duplicate components? - Can a teammate extend the system without reopening the reference? The strongest workflow is inspect, document, implement, and review. Use references to explain the decisions, not to replace product judgment. If the final rules are clear enough for another developer to use, the design system has become part of the project rather than a screenshot on the side. ## Use this in your AI agent > Review the selected website references and this GitHub Copilot project. Create a concise design brief covering structure, typography, colors, spacing, borders, radii, shadows, gradients, responsive behavior, and component states. Label each point as observed, adapted, or recommended. Propose the smallest changes needed, reuse the existing component system, preserve routing and behavior, then implement only the approved scope and report files, assumptions, and responsive checks. [Install Fudge for your AI agent](/mcp). --- Make the reuse rule explicit before asking for implementation. Tell Copilot to inspect the existing tokens and components first, and to prefer extending a shared component over adding a local variant. Ask it to stop and report a conflict when the reference cannot fit the current system cleanly. Give repeated patterns names and rules. For example, define one card surface, one button family with primary and secondary treatments, one field style, and one content-width rule. Then state where exceptions are allowed. Without an exception rule, agents often solve each section locally because the task appears to reward visual similarity. Ask for a token audit before the visual pass. Copilot should identify duplicate colors, near-duplicate spacing values, repeated radii, and components that perform the same job. Consolidate those values first, then apply the page treatment. Review the diff for new arbitrary values and duplicated markup. You can also require a short architecture report: components reused, components changed, tokens added, and exceptions introduced. If the exception list grows, narrow the reference or revise the system instead of continuing to patch individual sections. --- Use a four-part review that takes less time than comparing every pixel. First, compare the hierarchy: can you identify the page purpose, primary action, supporting proof, and next step in the same order? If hierarchy is wrong, visual polish will not fix the page. Second, sample repeated elements. Check two or three buttons, cards, headings, inputs, and code blocks across the page. Look for shared height, padding, type, border, radius, and state behavior. Repeated inconsistency usually points to a missing token or a duplicated component. Third, resize through narrow and wide viewports. Check whether the main action remains visible, columns stack in the intended order, headings wrap without awkward breaks, and images or gradients do not cover controls. Tab through the page to check focus visibility. Finally, compare the implementation report with the brief. Confirm that Copilot changed only the requested scope, preserved routes and content, and recorded assumptions. If the result feels close but inconsistent, ask for a token and component cleanup pass rather than another round of section-by-section styling. ## Related questions - [Website Design System MCP for Windsurf](/share/website-design-system-mcp-for-windsurf) - [Website Reference MCP for Claude Code](/share/website-reference-mcp-for-claude-code) - [Website references for Claude Desktop](/share/website-reference-mcp-for-claude-desktop) - [Use website design references inside Codex](/share/website-design-system-mcp-for-codex)