# Use real website examples inside Gemini CLI

[Open the live Fudge conversation](https://design.withfudge.com/share/real-website-examples-inside-gemini-cli)

Last updated: 2026-08-25

Use real website examples inside Gemini CLI by turning a few captured pages into a clear comparison and implementation brief. The practical method is to ask Gemini CLI what it can observe, choose which patterns fit your page, and then build against explicit checks instead of relying on a vague style reference.

## Choose references with separate jobs

Start with two to four examples, each selected for a reason. One might show the page structure you want, another might show a useful type scale, and a third might demonstrate cards, navigation, forms, or a strong mobile arrangement. Keep the set limited so Gemini CLI can compare it instead of averaging unrelated ideas.

The examples below include Notion Developer Platform, Claude Code, and Exa MCP Server. Open them and compare their first screen, section rhythm, content density, and action placement. Use them as separate answers to separate questions. A reference can guide a layout decision without becoming a template for the whole page.

## 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)

## Make Gemini CLI describe what it sees

Avoid prompts such as "make my site look like these websites." Ask for a comparison that produces decisions:

- Which sections and components are visible first?
- How do the examples use width, alignment, and whitespace?
- What distinguishes headline, body, label, and button text?
- Which colors serve as background, text, border, accent, or status colors?
- How do cards and controls repeat their spacing, borders, radii, and shadows?
- Which visual patterns appear in more than one reference?
- Which details are unique and should not be treated as a general rule?

Ask Gemini CLI to mark uncertain observations rather than filling gaps with assumptions. You want a useful set of notes that can guide code, not a fictional explanation of how another site's design was made.

## Write the brief before the code

Convert the comparison into a short build brief. It should state the decisions you have actually made:

- The page uses a readable content width and generous spacing between major sections.
- The headline has a clear scale jump over the supporting copy.
- Primary actions use one consistent accent, while secondary controls stay quiet.
- One card style repeats across related content.
- The references provide direction only; their copy, assets, and identity are not being reproduced.

Add practical acceptance checks. For example, the first action must be easy to find, the mobile layout must keep the headline and action in the right order, and repeated components must use the same spacing and border treatment. These checks give Gemini CLI a way to improve the page without chasing subjective adjectives.

## Build and review in small passes

A good sequence is:

1. Select captured references and name the design question each one answers.
2. Ask Gemini CLI for a comparison of structure, typography, color, spacing, and components.
3. Choose one pattern for each decision and record the choice.
4. Ask for a plan covering components, content hierarchy, and responsive behavior.
5. Implement the hero and one representative component first.
6. Review that section against the observations before building the rest.
7. Run a final consistency check across desktop and mobile states.

A design reference tool can inspect captured page structure, typography, colors, spacing, components, imagery, and motion, then return those observed details for your agent to use. The important part is still the decision step: decide what belongs in your page, what does not, and how you will tell whether the result is working.

## Use this in your AI agent

> Compare these captured website references before editing my project. For each one, report observable page structure, typography, color roles, spacing, borders, radii, shadows, imagery, motion, and responsive clues. Separate shared patterns from one-off details and mark anything uncertain. Then write a concise implementation brief that assigns one reference to each design decision, preserves my content and interaction needs, and includes desktop and mobile acceptance checks. Build only the hero and one representative component first so I can review the direction before the rest of the page is updated.

[Install Fudge for your AI agent](/mcp) to bring captured website references into this workflow.

---

Give each reference one job and state that rule directly in the prompt. For example, use one page for section order, one for typography, and one for cards. Tell Gemini CLI not to combine patterns unless you approve the combination.

A short decision table helps:

| Decision | Chosen reference | Rule |
|---|---|---|
| Page structure | Reference A | Keep its section order and content rhythm |
| Typography | Reference B | Borrow hierarchy, not exact copy |
| Cards | Reference C | Repeat its spacing and border treatment |

Then ask it to list conflicts before writing code. If the examples disagree about button shape, page width, or color intensity, choose one and explain why it fits your content. Review the first implemented section while the change is still small. Removing an extra pattern early is easier than repairing a page that has blended three unrelated visual languages.

---

Use a four-part task: context, decisions, constraints, and checks.

**Context:** describe the page you are building and who it serves. **Decisions:** list the selected reference for structure, typography, colors, and components. **Constraints:** say what must remain unchanged, such as content, routes, interactions, or existing assets. **Checks:** define what Gemini CLI should verify on desktop and mobile.

Keep the first coding task narrow: "Implement the hero and the first repeated component using this brief." Ask it to show the files it will change and explain how each change maps to a decision. After reviewing the result, give a second task for the remaining sections.

This staged approach turns reference browsing into an actionable build sequence. It also makes corrections precise. You can say "reduce the section gap and restore the body text width" instead of restarting with a broad request to make the page feel more like a reference.

## Related questions

- [Use real website examples inside GitHub Copilot](/share/real-website-examples-inside-github-copilot)
- [Website design feedback MCP for Claude Code](/share/website-design-feedback-mcp-for-claude-code)
- [Use website design references inside Cline](/share/real-website-examples-inside-cline)
- [Use real website examples inside Claude Desktop](/share/real-website-examples-inside-claude-desktop)