copy-website-style

name	copy-website-style
description	Use this skill when the user wants to recreate, copy, clone, remix, or closely match the look, layout, motion, or interaction feel of a specific website, URL, screenshot, or template using plain HTML, CSS, and JavaScript. Use it to inspect public source as research, rewrite original code, avoid direct reuse of protected assets, and validate the result in a browser.

Copy Website Style

Goal

Recreate the visible style, layout, motion, and interaction feel of a specific website as a clean static implementation.

This skill is for "make it like this" tasks. It is stricter than a loose theme reference: the output should resemble the target's recognizable composition and behavior while using original, maintainable HTML/CSS/JS.

Core principle:

• Copy the style and interaction pattern.
• Do not copy protected code, assets, personal identity, private links, or analytics by default.
• Rewrite a clean static version.
• Use page-relative internal links and assets so the result works by direct file open, local HTTP, and static hosting.
• Validate against the target in a real browser.

Contract

Inputs:

• Target URL, screenshot, template, local reference, or concrete visual/motion reference.
• Desired scope: homepage, selected pages, or full navigable static recreation.
• Output folder, permission context, and any user identity/content to replace target content.

Outputs:

• A clean plain HTML/CSS/JS static recreation of the target's recognizable layout, motion, interaction feel, and page types.
• Placeholder or user-owned content instead of copied target identity.
• EDITING.md with page map, content locations, simplified interactions, and omitted routes.
• Comparison and validation summary.

Boundaries:

• Do not redistribute protected code, private assets, analytics, original personal content, or unlicensed media.
• Do not stop at a single homepage when the requested scope implies a navigable site.
• Do not preserve root-absolute framework routes by default; convert to static relative paths.
• Do not publish; use publish-static-site.

Success gate:

• The local recreation matches the target's signature layout, visual language, and core interactions closely enough for the requested fidelity.
• Important page types exist and are linked.
• Target identity has been replaced or explicitly permitted.
• review-static-site can pass or only report accepted limitations.

If gate fails:

• Reinspect the target and iterate on signature layout/motion.
• Use personalize-site for identity residue.
• Use review-static-site for structural/path/encoding/browser blockers.

Short Pipeline

Follow this pipeline for website recreation:

1. Explore the target in a browser.
2. Map the target's internal pages and clickable routes.
3. Inspect source and assets as research.
4. Extract signature layout, motion, interactions, and visuals.
5. Replace original-site identity and personal content.
6. Rebuild the full navigable site with plain HTML/CSS/JS.
7. Convert framework/root routes into static page-relative links.
8. Add an editing guide for future model/user edits.
9. Validate locally over HTTP in a real browser.
10. Compare against the target and iterate.
11. Audit for leftover target-specific text or assets.

Use When

Use this skill when the user says or implies:

• Copy this website style.
• Recreate this page.
• Clone this site.
• Make a static version of this website.
• Make it look like this URL or screenshot.
• Match the original animation, scroll, hover, or interaction.
• 1:1, high-fidelity, pixel-like, same feel, same motion.

Use it for references from websites, v0, Figma, GitHub themes, Astro, Hugo, Jekyll, Quartz, Next, React, Tailwind, or other framework-based templates when the user wants close recreation rather than loose inspiration.

Do Not Use When

Do not use this skill when:

• The user only wants to search for themes. Use search-blog-theme.
• The user wants an original personal site from a chosen direction. Use make-personal-site.
• The user wants content migration or post import. Use add-blog-posts.
• The user only wants deployment help. Use publish-static-site.
• The user asks to directly copy protected code, private assets, or personal content from a site they do not own.
• The user explicitly wants to keep the original framework and build system instead of making a plain static version.

Inputs

Use whatever is available:

• Target URL, screenshot, video, template link, or local reference.
• User's desired output folder.
• Whether the final result should keep placeholder content or use the user's own content.
• Required pages or sections.
• Expected scope if the user provides one: homepage only, selected pages, or full navigable site.
• Whether the user owns the target or has permission to reuse assets/code.
• Any required static constraints: no build step, no external dependencies, local deploy only, etc.

Browser Exploration Pass

Before implementation, explore the target in a real browser when a URL or interactive reference is available.

Use an actually available interactive browser tool as the first-choice way to observe the target and local preview. "Available" means the tool is exposed in the current turn's callable tool list, not merely mentioned in a skill, plugin list, or system description. In Codex this may be the Browser/in-app browser plugin when the user or client has routed it into the turn; in other agents it may be an equivalent visible browser, browser-use tool, or devtools-backed browser. The goal is to see the page as the user sees it: viewport, motion, scrolling, hover/click behavior, mobile layout, console state, and network failures.

If no interactive browser tool is exposed in the current turn, do not pretend the browser pass happened. If target exploration or local comparison depends on it, ask the user to enable or invoke the browser tool using their client's routing method; for Codex, that may mean sending a request that explicitly mentions @browser. If the user does not re-route or the client has no such tool, fall back to Playwright, screenshots, static audits, or source inspection and state the limitation.

Do not default to Playwright, headless-only screenshots, or raw source inspection when an interactive browser tool is actually callable. Screenshots can document what was observed, but they are not a substitute for an interactive browser pass. Use Playwright only as a fallback when no interactive browser tool is callable, when the user explicitly asks for Playwright, or when repeatable scripted comparison is specifically needed.

Use Chrome automation when the task needs the user's Chrome profile, an existing Chrome tab, extensions, authenticated pages, or Chrome-specific behavior.

During exploration, inspect:

• Desktop first screen: composition, scale, spacing, typography, color, visible navigation, and primary visual motif.
• Mobile first screen: layout changes, hidden navigation, scroll behavior, and content priority.
• Opening sequence: load state, reveal order, opacity/scale/clip changes, delays, and easing feel.
• Scroll behavior: vertical vs horizontal scroll, pinned areas, snap points, inertia, scroll-linked transforms, and minimap changes.
• Pointer behavior: hover states, cursor details, drag behavior, pointer-following elements, and hit areas.
• Click behavior: navigation, toggles, copy states, active states, modals, and transitions.
• Keyboard behavior: arrow keys, tab focus, escape/enter behavior when relevant.
• Internal page map: primary navigation links, header/footer links, cards that open internal pages, article/detail pages, archive/category/search/theme/settings pages, pagination, and mobile-menu-only routes.
• Source clues: DOM structure, CSS variables, class names, inline styles, loaded fonts, image assets, bundled CSS/JS names, and network requests.
• Console state: visible runtime errors or warnings that may affect behavior.

Capture or mentally record enough evidence to guide implementation. Do not expose a long exploration log to the user unless they ask; use it to build the signature inventory and implementation plan.

Source Inspection Rule

For public websites, page source, bundled CSS/JS, network-loaded assets, and DOM structure may be inspected to understand layout, breakpoints, CSS variables, animation timing, scroll behavior, and interaction logic.

Use inspected source as research material, not as default deliverable code.

Do not directly copy, redistribute, or preserve another site's code, images, fonts, personal content, private links, analytics, or bundled assets unless one of these is true:

• The user owns the site.
• The source or asset is clearly open source with a compatible license.
• The user confirms they have permission to reuse it.

For normal replica work, rewrite a clean, maintainable plain HTML/CSS/JS version that captures the visible behavior and design language. If an inspected implementation detail is important, translate the idea into original code.

Fidelity Workflow

Treat these steps as required internal work for a serious recreation:

1. Run the browser exploration pass when possible.
2. Build a target page map from visible navigation and important internal links.
3. Inspect the target source and DOM for implementation clues.
4. Identify the target's signature layout, signature motion, signature interactions, and signature visual details.
5. Implement the shared shell, then the linked internal pages.
6. Preview the local static version over HTTP.
7. Compare the local result with the target in similar browser viewports.
8. Iterate until the result matches the target's feel closely enough for the user's request.
9. Report any meaningful remaining differences.

Do not stop after the HTML structure is similar if the target is motion-first.

Full Site Scope Rule

Default to recreating the target as a navigable static site, not only a single homepage.

Unless the user explicitly asks for "homepage only", create static pages for the target's important internal routes:

• Primary navigation pages.
• Article/detail pages linked from the homepage or primary lists.
• Archive, category, tag, link, theme, preview, settings, or search pages when they are part of the visible experience.
• Mobile-menu-only destinations.
• Pagination or list pages when they define how the site is browsed.

For large sites, do not mirror every real content item. Recreate the site structure and page types with placeholder content:

• One or a few representative article/detail pages.
• Representative archive/category/list pages.
• Placeholder entries that demonstrate pagination, filtering, search, cards, and sidebar behavior.
• Working internal links between the generated static pages.

Record the generated page map in EDITING.md. If any target routes are intentionally omitted, explain why and how to add them.

Signature Inventory

Before coding, build an internal inventory:

• Signature layout: page structure, composition, scale, spacing, navigation, breakpoints, repeated motifs, and unusual layout mechanics.
• Signature motion: opening animation, reveal effects, scroll behavior, easing, spring-like movement, hover states, transitions, loading states.
• Signature interactions: wheel behavior, keyboard behavior, click states, copy states, active navigation, drag/scroll gestures, mobile changes.
• Signature visuals: colors, typography feel, contrast, borders, shadows, masking, blend modes, shapes, illustrations, background treatment.

Recreate these signature pieces before filling secondary content.

Framework And Motion Translation Rule

The target may use any stack. Translate the visible behavior into plain static files unless the user explicitly asks otherwise.

Common translations:

• React, Next, or Astro components -> repeated HTML sections with reusable CSS classes.
• Tailwind utility classes -> normal CSS rules.
• Framework routes -> linked .html files.
• Content collections or CMS data -> static HTML lists or small JSON files.
• Theme configuration -> CSS custom properties.
• Framer Motion spring -> vanilla JavaScript spring loop, requestAnimationFrame, or carefully tuned CSS easing.
• scrollX / scrollY transforms -> scroll progress mapped to CSS custom properties and transforms.
• Clip reveal -> overflow: hidden plus translateY, clip-path, or mask animation.
• Scale reveal -> transform: scale(...) with transform-origin and easing.
• Layout motion -> transform and opacity transitions, not layout-thrashing width/height changes.
• Scroll-linked horizontal canvas -> wheel listener plus horizontal scroll, snap points, active panel detection, and optional inertial easing.
• Minimap tracker -> active state plus transform/opacity synced to scroll position.
• Copy-to-clipboard animation -> two-state text switch with translate/opacity transition.
• Cursor/crosshair details -> fixed element or pointer-following transform if central to the reference.
• Blend effects -> CSS mix-blend-mode, masks, or a simplified static contrast when needed.

Respect prefers-reduced-motion, but do not remove signature motion entirely unless reduced motion is active.

Static Path Compatibility Rule

The target site may use server-root routes such as /assets/..., /posts/..., /blog, or framework routing. The recreated static output should not preserve those root-absolute paths by default.

Default rules:

• Use page-relative paths for every site-local asset and internal link.
• From root pages, use assets/style.css, assets/script.js, posts/example.html, and archive/index.html.
• From nested pages, use the correct depth such as ../assets/style.css, ../index.html, or sibling-relative links.
• Convert target routes like /posts/foo, /tags/bar, or /projects into generated static paths such as posts/foo.html, tags/bar.html, projects.html, or projects/index.html according to the output structure.
• Do not keep /assets/..., /posts/..., /data/..., /images/..., or / for internal navigation unless the user explicitly accepts server-root-only behavior.
• Apply this to HTML attributes, CSS url(...), favicons, cover images, fonts, math/vendor assets, JavaScript-generated cards/search results, and copied route data.

Avoid direct-open breakage:

• Do not rely on local fetch() for core page content or navigation when a direct-open static preview is expected.
• If a data object is needed for search/filter/card rendering, prefer a relative JavaScript file that defines local data, or keep essential content in HTML.
• If an interaction absolutely requires local HTTP, make the non-enhanced static content still readable and navigable.

Static Downgrade Rule

Do not downgrade signature layout or signature motion before attempting a vanilla implementation.

Downgrade only after a reasonable attempt, and name the difference.

Examples:

• 3D globe -> static topic map or project constellation only if the globe is not core to the reference.
• Complex physics -> tuned easing or approximate spring.
• Large WebGL scene -> static composition plus lightweight hover/motion if WebGL is not essential.
• Graph view -> tags, related links, or topic map if the exact graph is not critical.

Prefer a simpler original implementation that captures the target's feel over a fragile copied bundle.

Content And Identity Safety

Replace all original-site personal identity content by default.

Do not keep another person's private identity, personal copy, real email, social links, analytics, private URLs, article catalog, article body, friend links, site statistics, community links, domain-specific text, or licensing statements as final template content unless the user explicitly asks and has permission.

Use placeholders or the user's own content while preserving the visual and interaction pattern.

If the task is to study a public website, be clear that the deliverable is a style recreation, not a redistribution of the original site.

Placeholder Content Rule

Default to clearly replaceable placeholder content when the user has not provided their own content.

Keep placeholders easy to find and replace. Prefer storing repeated content in a clearly named place such as a data object, JSON file, or documented section of assets/script.js.

Do not invent a new realistic personal identity unless the user asks for a polished fictional demo. Use placeholder identity and content that clearly signals it should be replaced.

Do not generate a large copied content archive. For full-site recreation, create the navigable page types and representative placeholder entries instead of copying the target's content catalog.

Editing Guide Rule

When creating a reusable style recreation, include an editing guide in the output folder.

EDITING.md is primarily for a future model or agent that will modify the generated site later. It should be concrete enough that another model can safely update content without rediscovering the project.

Prefer a concise but specific EDITING.md that explains:

• Folder hierarchy and what each folder/file is for.
• File formats used by the site: HTML, CSS, JS, JSON/data blocks, image assets.
• Page map: which generated file corresponds to each target page or route.
• Shared layout regions: header, sidebar, mobile nav, main content, right rail, footer, overlays.
• Where each major homepage region lives in index.html, using nearby section/class names.
• Where each subpage template lives and how internal links connect to it.
• Where repeated content is stored and its expected object/markup format.
• How to change site title, tagline, avatar/logo, navigation, featured items, article lists, project/link lists, sidebar/stat cards, images, colors, and theme variables.
• Which content is placeholder-only and should be replaced before publishing.
• Any intentionally omitted routes or simplified interactions.

Keep the guide practical and specific to the generated files.

Residual Source Audit

Before final delivery, search the generated output for target-site-specific strings and remove or replace them unless the user owns the target or has permission.

Check for:

• Site name, author name, nickname, handle, and domain.
• Original article titles, article body text, categories, tags, and summaries.
• Emails, social links, friend links, community IDs, analytics IDs, and private URLs.
• Licensing or statistics text copied from the target.

If source-specific text intentionally remains, report why.

Asset Safety Rule

Do not keep downloaded target-site avatars, article covers, friend icons, fonts, screenshots, or other visual assets in the final output by default.

Use neutral placeholders, CSS shapes, generated simple graphics, or user-provided assets instead. Keep external assets only when the user owns them, the license allows reuse, or the user confirms permission.

Encoding Integrity Rule

Generated source files must be valid UTF-8 and human-readable in source form, not only correct-looking in browser screenshots.

For pages or editing guides containing Chinese, Japanese, Korean, accented Latin text, or other non-ASCII content:

• Include <meta charset="utf-8"> in HTML files.
• Write files as UTF-8.
• Verify source readability with a UTF-8-aware reader before final delivery.
• Check generated HTML, CSS comments, JavaScript string data, JSON/data blocks, and EDITING.md.
• Do not leave mojibake, replacement characters, or text that is only readable after accidental browser encoding recovery.

If the shell or terminal displays mojibake but the browser looks correct, confirm with a UTF-8-aware file read before deciding the file is broken. If the file content itself contains mojibake, rewrite the affected strings from clean source text rather than layering another encoding conversion on top.

Output Structure

For a new static recreation, prefer a full navigable structure:

site/
  index.html
  EDITING.md
  archive/
    index.html
  category/
    index.html
  links/
    index.html
  posts/
    sample-post.html
  assets/
    style.css
    script.js
    images/

Adapt folder names to the target site's routes. Add more pages when the target exposes them through navigation, cards, lists, pagination, or mobile menus:

site/
  about.html
  projects.html
  notes/
  posts/
  tags/
  theme/
  preview/

Keep CSS in assets/style.css and JavaScript in assets/script.js unless the existing project structure suggests otherwise.

Make sure every generated page uses paths relative to its own location. Do not copy a root page's assets/style.css link into a nested page without adding the needed ../ prefix.

Browser Validation Loop

Use a real browser before final delivery.

Serve local static files over HTTP for automation and screenshots, not file://:

python -m http.server 8000

Then open:

http://127.0.0.1:8000/

For recreation tasks:

• Open the target and local replica in comparable desktop viewports.
• Capture or inspect both first screens.
• Compare composition, scale, spacing, colors, typography, and visible motifs.
• Test the target's core interactions, then test the replica's matching interactions.
• Check opening animation, scrolling/wheel behavior, keyboard behavior when relevant, hover/click states, active navigation, copy states, and mobile layout.
• Click through generated internal pages and verify they render, keep the shared shell, and preserve the target's page-type feel.
• Check that direct file opening will keep CSS, JS, images, fonts, and internal navigation working by using page-relative paths instead of root-absolute paths.
• For full-site recreation, validate at least one screenshot or browser pass for every generated page type, including home, list/archive/category/link pages, article/detail pages, theme/settings pages, and any special interactive page types.
• Verify generated source files are UTF-8-readable and free of mojibake in the source, especially index.html, subpage HTML files, JavaScript data strings, JSON/data files, and EDITING.md.
• Check console errors.
• Revise until the signature layout and motion feel close, not merely structurally similar.
• Report meaningful remaining differences.

Use an actually available interactive browser tool first for the final local HTTP comparison. In Codex this may be the Browser/in-app browser plugin if it is exposed in the current turn's callable tools. Do not replace this with Playwright-only screenshots unless no interactive browser tool is callable, the user does not re-route, or the user explicitly requested Playwright. Use Chrome automation when the task needs the user's Chrome profile, an existing Chrome tab, extensions, or authenticated remote pages. Do not rely on Chrome extension automation for file:// pages; use local HTTP instead.

For a dedicated final QA pass before handoff or publishing, use review-static-site on the generated static folder.

What To Tell The User

Keep the final response concise and honest.

Tell the user:

• What target was recreated.
• What files were created or changed.
• How to preview the result locally.
• Which signature layout, motion, and interaction details were matched.
• Any meaningful differences from the original.
• Whether any assets or content were replaced with placeholders for safety.

Do not over-explain internal inspection steps unless the user asks.