website-ui-replica

name

website-ui-replica

description

Inspect a live website or supplied webpage with browser/DevTools-style evidence before rebuilding it, then recreate the UI as closely as possible using the same framework, component library, DOM structure, and CSS values when available. Use when the user asks to copy, clone, reproduce, 1:1 restore, reverse-engineer, or match an existing web page, especially when they mention visiting the site, F12, DevTools, framework detection, DOM inspection, screenshots, computed styles, Ant Design/Tailwind/CSS Modules, exact CSS, or exact visual parity.

Website UI Replica

Use this skill to rebuild an existing webpage from evidence, not from memory, visual guessing, or aesthetic redesign.

The goal is fidelity. Treat the source page or the user's reference screenshot as the spec and the judge. Do not improve, modernize, re-theme, simplify, expand, or "make it nicer" unless the user explicitly asks for a redesign.

Fidelity Contract

When this skill is active:

• Recreate the observed page, not a plausible product page in the same domain.
• Never invent the target page when the target page could not be accessed or inspected.
• For URL-based replica tasks, the live page's DOM, computed styles, stylesheets, assets, and framework evidence are mandatory primary evidence. Screenshots are only auxiliary visual checks unless the user explicitly says to replicate from screenshot only.
• If no URL is provided, or the user explicitly requests screenshot-only reproduction, a screenshot can be the primary visual reference.
• Preserve layout direction, navigation placement, header/sidebar structure, copy, visible row counts, empty space, density, colors, border radii, shadows, icons, and button labels from the reference.
• Do not add promotional banners, cards, footer panels, extra table rows, status badges, balances, breadcrumbs, dark sidebars, gradients, or decorative content unless they are visible in the reference.
• Do not merge multiple observed states. If the live page differs from the provided screenshot, ask briefly which state to match or default to the provided screenshot and mention that assumption.
• Do not use "inspired by", "MiMo style", or generic SaaS/dashboard patterns as a substitute for measured evidence.

Access Failure Rule

If the requested target URL cannot be inspected, stop and report the blocker instead of building a guessed replica.

Access blockers include:

• Redirected to login, account selection, SSO, captcha, paywall, 403/404/500, maintenance, or empty shell.
• Page title, URL, or visible content shows a different page than the requested target.
• Required authenticated content is hidden behind a session the agent does not have.
• Scripts/assets fail so the target UI cannot be observed.
• Browser automation cannot run JavaScript, query DOM, or read computed styles because of AppleScript, automation, permission, CSP, or tooling restrictions.

When blocked:

• Do not implement or edit files unless the user explicitly changes the task to screenshot-only reproduction or supplies exported HTML/CSS/assets that replace live inspection.
• Do not reproduce the login page unless the user asked to replicate the login page.
• Return the reason, final URL, page title, and what evidence was visible.
• If the blocker is login/session/authentication, first ask to use the user's authenticated browser session and wait for the user to log in or grant access. After the user confirms login, reopen the original target URL and continue inspection from Required Workflow step 3.
• If an authenticated browser session is not available, ask for one concrete fallback input: a logged-in screenshot, exported HTML/CSS, or HAR/assets.
• If the blocker is inability to execute DevTools-style JavaScript or inspect DOM/computed styles, ask for an inspectable browser path such as remote debugging, browser automation permission, exported HTML/CSS, or HAR/assets. Do not proceed from screenshot alone for a URL-based replica.

Authenticated Browser Session Strategy

When login is required, prefer a lightweight authenticated-session path. Do not blindly copy a full Chrome/Edge profile.

Order of preference:

1. Use an already authenticated browser/tab exposed by the user or the Codex in-app browser, if available.
2. Ask the user to log in in the browser you can inspect, then revisit the original target URL.
3. Attach to an existing Chrome/Edge instance via remote debugging, if the user has already launched one that way.
4. Ask the user for permission to close/reopen Chrome/Edge with a remote debugging port and the same user profile, then connect to that session.
5. Only if the user approves and there is enough disk space, create a minimal temporary profile or copy the smallest necessary profile files.

Before copying any browser profile or creating a temp profile:

• Check free disk space for /tmp and the intended destination.
• Estimate profile size if copying is considered.
• Avoid copying cache, code cache, service worker cache, GPU cache, crash reports, media cache, and other large non-auth files.
• If free space is low or copying fails with No space left on device, stop immediately and report disk space as the blocker. Do not keep retrying large copies.
• Explain the lighter next path: use the existing logged-in browser, ask the user to log in in an inspectable browser, or reopen Chrome/Edge with remote debugging.

Suggested disk/profile-blocked response:

I cannot copy the browser profile because disk space is too low / the profile is too large, and I will not guess the authenticated page.
Reason: insufficient space for temporary browser profile.
Evidence: /tmp free space ..., profile size or copy error ...
Next step: please allow me to use your existing logged-in browser session, or close/reopen Chrome with remote debugging so I can inspect the real target page without copying the full profile.
Fallback: provide a logged-in screenshot, exported HTML/CSS, or HAR/assets.

Suggested login-blocked response:

I reached a login page instead of the requested target, so I will not guess the UI.
Reason: redirected to login / missing authenticated session.
Requested URL: ...
Final URL: ...
Page title: ...
Visible evidence: ...
Next step: please log in in your browser or allow me to use an already logged-in browser session. After you confirm login, I will reopen the original URL and continue DevTools-style inspection.
Fallback: if browser access is not possible, provide a logged-in screenshot, exported HTML/CSS, or HAR/assets.

Required Workflow

1. Establish the reference state before coding:
   • If the user provides screenshots, identify whether they are auxiliary visual references or whether the user explicitly requested screenshot-only reproduction.
   • If only a URL is provided, open the target page and capture a screenshot at the current viewport before coding.
   • If a screenshot and URL conflict in a URL-based task, default to live DOM/CSS evidence and ask which state to match if the difference is material.
2. Open the target link in a browser before implementation whenever a URL is provided. Use the in-app Browser for local targets and ordinary inspection. Use Chrome when the page needs the user's logged-in session, cookies, extensions, or an already-open authenticated tab.
3. Confirm access to the requested target before coding:
   • Check final URL, page title, visible route, and main content.
   • If the requested route redirects to login or another non-target page, apply the Access Failure Rule.
   • For login/session redirects, request the user's authenticated browser session first. Do not ask only for screenshots if an authenticated browser path is plausible.
   • If DevTools-style inspection is blocked, apply the Access Failure Rule. Do not continue using a screenshot as the primary reference unless the user explicitly changes the task to screenshot-only reproduction.
4. Inspect the page like F12/DevTools before implementing. Do not skip this when a live URL is accessible:
   • framework/library signals
   • DOM hierarchy and class names
   • computed styles for key elements
   • layout dimensions and spacing
   • assets, icons, fonts, and images
   • component library class names
   • loaded CSS files, CSS variables, reset styles, font declarations, and hashed CSS module classes
5. Capture or save evidence before editing code: screenshot, DOM skeleton, component-library signals, stylesheet URLs or extracted CSS rules, and computed styles for major regions.
6. Identify the implementation stack and replicate it. If the target uses React/Vue/Next/Nuxt, Ant Design/Element Plus/MUI/etc., Tailwind/CSS Modules/styled-components/global CSS, use the same framework, component library, and styling system in the replica unless impossible in the current project.
7. Extract or mirror the source CSS as closely as possible:
   • Reuse exact CSS variables, colors, font stacks, radii, shadows, table styles, and layout measurements when accessible.
   • Preserve original class names or create one-to-one mapped local class names when hashes/build tooling make direct reuse impractical.
   • Copy only the rules needed for the target surface; do not import unrelated site-wide CSS that creates breakage.
8. Rebuild from the observed DOM structure first, then visual styling. Do not invent a simpler wrapper hierarchy when the source DOM hierarchy is known.
9. Verify in the browser with screenshots and computed measurements. Iterate until visible differences are explained or fixed.

Inspection Checklist

Read references/inspection-checklist.md when starting a replica task. Use it as the evidence checklist before editing code.

Minimum evidence to collect:

• The page framework: React, Vue, Next.js, Nuxt, Vite, webpack, etc.
• UI libraries: Ant Design, MUI, Element Plus, Radix, shadcn, Bootstrap, etc.
• Styling system: Tailwind utility classes, CSS Modules hashes, styled-components, global CSS, inline styles.
• DOM skeleton for the target area: header, sidebar, content shell, panels, toolbars, table wrappers, pagination.
• Exact computed values for repeated surfaces: widths, heights, padding, gaps, border radius, background color, border color, font size, font weight, line height.
• Table details: header background, row height, cell padding, column widths, sorting/filter icons, fixed columns, pagination placement.
• Responsive behavior for at least desktop and the smallest viewport the user cares about.

Implementation Rules

• Build the actual target page or app surface. Do not create a landing page unless the source is a landing page.
• Match the reference viewport first. If the screenshot includes the browser chrome or desktop background, do not recreate those unless the user explicitly asks for a full screenshot mockup; recreate only the webpage content inside the browser viewport.
• Match the source technology pattern before adding abstractions. "Same style" means same framework, same component library, same styling system, and same CSS values whenever the evidence supports it.
• If the existing workspace uses a different framework from the source, pause only when switching framework would rewrite the project or create non-obvious risk. Otherwise, install/use the matching library and explain the dependency choice.
• Use library components where the source uses them. For example, use Ant Design Table, Pagination, Button, DatePicker, Modal, Tooltip, Select if the source has ant-* DOM.
• Use Tailwind utility classes for layout when the source uses Tailwind-like classes such as flex, gap-4, px-[16px], text-[13px].
• Use CSS Modules for local component overrides when the source has module hashes such as FancyTable_fancyTable__....
• Keep global CSS for tokens and broad resets only.
• Preserve source copy, ordering, and interaction states unless the user asks for changes.
• Do not replace detailed source structure with generic classes like content-shell or panel if the inspected DOM shows a different hierarchy.
• Do not substitute handcrafted components for source library components unless the library cannot be installed or the source component cannot be identified.
• Do not approximate CSS with "close enough" design tokens before checking computed styles or stylesheet rules.
• Prefer omission over invention: if an element is not visible or evidenced, leave it out.
• Keep placeholder data to the minimum needed to match the visible screenshot. Do not add extra rows/cards to make the app feel complete.
• For Chinese UI screenshots, preserve Chinese labels exactly, including punctuation and spacing. Do not translate or rewrite copy.

Anti-Patterns That Fail This Skill

These are failures, even if the result looks polished:

• Continuing to build a target console page after the URL redirected to a login page and no target screenshot/HTML/CSS was supplied.
• Treating an access-blocked login/account page as evidence for the requested authenticated console page.
• Saying a screenshot is "enough" for a URL-based replica after browser automation cannot read DOM or computed styles.
• Starting a static replica from screenshots when the user asked to inspect a link/F12/DOM/CSS.
• Turning a light console page into a dark-sidebar SaaS dashboard when the reference has a white header and light sidebar.
• Adding announcement banners, balance cards, guide cards, breadcrumbs, or multiple API key rows that are not visible in the reference.
• Changing button text such as + 新建 API Key to 创建 API Key.
• Replacing a compact table with a custom card/table hybrid.
• Using generic CSS after the source CSS, variables, or component classes were available in DevTools.
• Rebuilding an Ant Design/Element Plus/MUI table with plain divs when the target clearly uses that component library.
• Guessing colors, spacings, or table dimensions without measuring or sampling the screenshot/source.
• Stopping after one screenshot when obvious differences remain.

Verification

Before finishing:

1. Run the project build or relevant checks.
2. Open the page in the browser.
3. Compare the screenshot to the reference at the same viewport and zoom.
4. Query computed styles for the key elements the user mentioned.
5. Fix obvious mismatches before final response.
6. Report what was matched and any remaining known differences.

Minimum comparison points:

• page/background color
• header height and nav placement
• sidebar width, selected item color, and bottom links
• main content top/left offsets
• card/container radius and padding
• title size/weight
• alert bar color/height/copy
• primary button size/color/label
• table header color, row height, columns, visible row count
• pagination placement and labels

Useful browser checks:

Array.from(document.querySelectorAll('*'))
  .map((el) => el.className)
  .filter(Boolean)
  .join(' ')

const el = document.querySelector('.target-selector');
const s = getComputedStyle(el);
({
  width: el.getBoundingClientRect().width,
  height: el.getBoundingClientRect().height,
  padding: s.padding,
  background: s.backgroundColor,
  fontSize: s.fontSize,
  fontWeight: s.fontWeight,
  lineHeight: s.lineHeight,
  borderRadius: s.borderRadius,
});