@xiaoerzhan: Replica skill release - I used this skill to 1:1 replicate the currently recognized top-notch frontend website, achieving 100% fidelity. See comments. Here I explain the principles. I. Core understanding: Where is the "true source code" of a website? The key is to distinguish two types of websites— A. Server-side rendered / data-driven sites (Taobao, backend systems, most SaaS…

X AI KOLs Timeline Tools

Summary

This article explains how to 1:1 replicate a recognized top-notch frontend website (oryzo), including methods for capturing dynamic assets and modifying a small amount of configuration, achieving high fidelity.

Replica skill release I used this skill to 1:1 replicate the currently recognized top-notch frontend website The fidelity can be 100% See comments Here I explain the principles I. Core understanding: Where is the "true source code" of a website? The key is to distinguish two types of websites— A. Server-side rendered / data-driven sites (Taobao, backend systems, most SaaS) The real logic runs on a server you can't see; the browser only receives fragmented results from the server. B. Static build sites (Astro / Vite SSG / Hugo — oryzo is this type) The entire client runtime (HTML + JS bundle + CSS + all 3D/images/font assets) is fully packaged into downloadable static files during the build and thrown onto a CDN. There is no hidden backend computing the visuals. ▎ So obviously B can be scraped~~ II. Why this site is tricky: assets are "pulled out when scrolling" You can't simply `wget` the HTML and be done. Because the heaviest things in oryzo— - .sog Gaussian splatting data (3MB 3D scene) - 25 .buf files (geometry + camera animation curves) - wasm sorter, Rive animation are all dynamically fetched by JavaScript as you scroll down, with URLs built on the fly. Static scanning of HTML cannot find them at all. So the approach of `mirror-site.mjs` is: open a real browser, scroll from top to bottom, record every actual network request that occurs during this process, and then download them one by one according to this "actual request list." — This is the only way to capture all dynamic assets. This time it captured 135 of them. III. Why does it render exactly the same after moving it? It relies on root-relative paths. All the code in oryzo uses paths starting with `/`, like `/_astro/hoisted.js`, `/models/coaster.buf`, `/splats/props.sog`. As long as I serve the `site/` folder as the web root, the browser resolves `/models/coaster.buf` to my local copy. Same code, same paths, same bytes → the browser can't tell if this is the original site. It runs exactly the same real code and assets from Lusion, so even the quirk of the original site's two mp4s aborting is identical. The only two places that need changes (neither is a "rewrite", but a "redirect"): 1. Typekit fonts — Adobe locks authorization by domain; switching to localhost might not serve the fonts → download the font files and self-host, change one line of @import to point locally. 2. Remove Cloudflare tracking — cut one line of <script>. The remaining 133 files have zero changes. So the final hero pixel diff is only 36/1.3 million — that tiny difference is just the random jitter of Gaussian splatting sorting per frame.
Original Article
View Cached Full Text

Cached at: 06/30/26, 01:42 PM

Recreating a Skill Release

I took this skill and 1:1 recreated the currently recognized best front-end website. The reproduction accuracy is 100% (see comments). Here I’ll explain the principles.

1. Core Insight: Where Does the “Real Source Code” Actually Live?

The key is to distinguish two types of websites:

  • A. Server-side rendered / Data-driven sites (Taobao, admin systems, most SaaS)
    The actual logic runs on a server you can’t see. The browser only receives fragmented results spit out by the server.

  • B. Static built sites (Astro / Vite SSG / Hugo — oryzo is this type)
    The entire client runtime (HTML + JS bundle + CSS + all 3D/images/font assets) is packaged into downloadable static files at build time and thrown onto a CDN. There’s no hidden backend computing frames.

Obviously, type B is the one you can dig into.


2. Why This Website Is Tricky: Assets Are Loaded Lazily on Scroll

You can’t just use wget to grab the HTML and call it done. Why? Because the heaviest parts of oryzo are:

  • .sog Gaussian splatting data (3MB 3D scene)
  • 25 .buf files (geometry + camera animation curves)
  • wasm sorter, Rive animations

All these are dynamically fetched by JavaScript when you scroll — the URLs are even constructed on the fly in code. Static HTML scanning won’t find them.

That’s why mirror-site.mjs works like this: it spins up a real browser, scrolls from top to bottom, records every real network request that happens during that process, then downloads each one according to that “actual request list”. This is the only way to capture all dynamic assets. This time it captured 135 files.


3. Why Does It Render Identically After Moving?

It relies on root-relative paths. All paths in oryzo’s code start with /, e.g., /_astro/hoisted.js, /models/coaster.buf, /splats/props.sog.

As long as I serve the site/ folder as the web root directory, the browser will resolve /models/coaster.buf to my local copy. Same code, same paths, same bytes → the browser can’t tell if it’s the original site. It’s running Lusion’s real code + real assets, so it even replicates the original site’s quirk where two mp4s would abort.

The only two things that needed changes (not rewrites, but redirections):

  1. Typekit fonts — Adobe locks licenses by domain; switched to localhost may block fonts → download the font files and self-host them, then change one line of @import to point locally.
  2. Remove Cloudflare tracking — one line deletion.

All other 133 files remain unchanged. So the final hero pixel diff is only 36 out of 1.3 million — that tiny difference is just the random jitter from Gaussian splatting per-frame sorting.

I really open-source everything, you know~~ remember to give me a star:
https://github.com/Jane-xiaoer/web-clone…

Here’s the link for you to play: http://oryzo.ai
Save it — you’ll have ammunition when you need it.

It turns out to be a daily trending product — seems like my pain point is everyone’s pain point.

My “Little Ear Find” lives inside my computer. Hit option+F and it pops up with a panel. You just ask directly.

Behind it is a huge amount of work: embedding all local content. I switched between two RAG methods. The principle of the second method is more worth learning.

Before: cutting content into fixed chunks of 500 characters — that approach didn’t work well.

Now: the core idea is converting content into Q&A pairs, then merging and tagging them hierarchically. This makes searching much smarter.

I’ll post the second method’s link in the comments. You can use it yourself to process the base data on your computer.

Similar Articles

@TEEMO648517: Recently I tried to replicate Teacher @wenhaoqi's website online, but the results were unsatisfactory. Until I saw posts shared by Teacher @hal__lee, @xiaolinbythesea, @dingyi, and @KrisYi777 — absolutely mind-blowing. I had tried many skills and agents before, but none worked well. Turns out evidence-driven workflow skills are incredibly powerful for web page reproduction.

X AI KOLs Timeline

The author's attempt to replicate a teacher's website fell short until discovering that evidence-driven process skills and agents are remarkably powerful for web reproduction, citing posts shared by several teachers.

@VincentLogic: Share a powerful tool that can 'one-click clone' any website into code! ai-website-cloner-template Simply put: give it a URL, and AI helps you reverse-engineer it, directly generating a clean Next.js codebase. What makes it powerful? Extremely high fidelity: It doesn’t just copy the surface; the AI automatically takes screenshots...

X AI KOLs Timeline

Introduces a tool named ai-website-cloner-template that uses AI to reverse-engineer any website into a high-quality Next.js codebase, supporting mainstream AI coding assistants.