Use real website examples inside GitHub Copilot

Contents

• [A practical workflow](#a-practical-workflow)
• [What to ask GitHub Copilot to inspect](#what-to-ask-github-copilot-to-inspect)
• [A checklist before you ship](#a-checklist-before-you-ship)
• [Use this in your AI agent](#use-this-in-your-ai-agent)

Real website examples can make GitHub Copilot more useful for design work, but the agent needs more than a URL or a vague instruction like "make it feel modern." Give it captured references, then ask it to compare visible structure, typography, colors, spacing, and interaction patterns before it writes code.

A practical workflow

Use this five-step process:

1. Choose two or three references with a clear reason for each. Pick one for page structure, one for typography or visual tone, and one for a specific component such as a pricing section, navigation bar, or developer documentation layout.
2. Capture the references at the state you want to study. A homepage, logged-out screen, mobile view, and opened menu can each suggest different design decisions.
3. Ask for observations before implementation. Have Copilot list the page sections, hierarchy, spacing rhythm, type choices, color roles, borders, shadows, and repeated components. This separates what is visible from what the agent is guessing.
4. Turn the observations into constraints. Ask for a small design brief with rules such as maximum content width, heading scale, button treatment, card radius, and spacing units.
5. Build one section at a time and compare it against the references. Start with the first screen, then check navigation, content blocks, forms, and responsive behavior.

Open the examples below and compare the first screen before borrowing a pattern. Notion Developer Platform, Claude Code, and Exa MCP Server are useful starting points for different developer-focused directions, but treat them as references to study rather than templates to copy.

What to ask GitHub Copilot to inspect

A useful request names the evidence you want and the decision it should support. Ask Copilot to describe:

• The order and purpose of the major sections
• The visual hierarchy between eyebrow text, headings, body copy, buttons, and supporting labels
• The approximate content width and alignment rules
• How cards, borders, shadows, and background changes separate content
• Which colors act as page background, text, muted text, accent, success, warning, or action colors
• Font families, available weights, sizes, line heights, and letter spacing
• How images are cropped, positioned, rounded, or layered
• What changes between desktop and narrow screens

Then ask: "Which of these choices should become reusable components, and which are specific to this page?" This helps prevent a one-off imitation from becoming a brittle component system.

For each reference, record pattern, evidence, use, and risk. For example, a strong first-screen headline may provide a useful hierarchy for a product landing page, but its spacing may create too much empty space on mobile. Dense developer navigation may help a documentation page, but it can make scanning harder for new visitors. Large rounded cards may separate feature groups, but using them everywhere can make sections feel interchangeable.

A checklist before you ship

Check the page with its real content length, not only placeholder copy. Make sure the main action remains visible, headings do not create awkward wraps, body text is easy to scan, and cards do not hide the difference between primary and secondary information. Compare the narrow layout separately because a desktop reference can conceal problems with navigation, tables, forms, and image crops.

Also check whether the reference shows a special state. A captured hover, open menu, selected tab, or signed-in view should not quietly become the default behavior in your implementation. Record the state beside each observation so Copilot can use it correctly. Keep your wording, logo treatment, illustrations, brand colors, interaction behavior, and content priorities distinct from the references.

Use this in your AI agent

> Compare the attached website references before changing my interface. First list the visible page sections, hierarchy, typography, color roles, spacing rhythm, card and button treatments, image crops, and responsive clues. Then create a short design brief that distinguishes reusable rules from reference-specific details. Recommend the smallest set of changes to my current page, explain the tradeoffs, and implement only the first-screen improvements. Keep my content and brand identity distinct from the references.

Use Fudge with your AI agent to bring captured website references into this workflow.

Compare decisions, not identities. For each reference, write down what the visitor can observe: the order of sections, the width of the reading column, the relationship between heading and supporting copy, the number of actions in the first screen, the spacing between blocks, and the way color separates primary actions from background content.

Translate those observations into neutral rules. For example, "keep the hero copy within a narrow measure and place one primary action beside one quiet secondary action" is more useful than "make it look like this site." Compare the same pattern across two references. If both use compact navigation but one emphasizes search and the other emphasizes a call to action, the difference reveals a product decision rather than a style to copy.

Keep a separate list of what must remain yours: wording, logo treatment, illustrations, brand colors, interaction behavior, and content priorities. Ask GitHub Copilot to explain how each proposed change supports your audience and to flag anything that depends on a reference-specific detail. This gives you a page informed by examples without turning it into a replica.

Use a narrow prompt that asks for analysis, a recommendation, and one implementation pass:

> Review the captured references and my current landing page hero. Compare them on headline width, supporting copy length, action placement, navigation density, background treatment, typography scale, spacing, and image or illustration use. Make a table with: current behavior, reference observation, recommended change, and reason. Keep my wording, brand colors, and product claims unless a change is necessary for clarity. Recommend no more than three improvements, then implement only those changes. Preserve responsive behavior and explain any tradeoff you notice.

After the agent updates the section, review it at desktop and mobile widths. Ask it to inspect the result against the same checklist rather than asking whether it "looks better." If the change feels too close to one reference, request a second pass that keeps the structural lesson but replaces distinctive styling with your existing design language.

Related questions

• Use Real Website Examples Inside Windsurf
• Website design feedback MCP for Claude Code
• Use website design references inside Cline
• Use real website examples inside Gemini CLI