# A website rebuild skill that treats the mirror as evidence and the pixel diff as a judge > website-rebuild-skill is an agent skill that mirrors a site read-only, ports its minified code line by line, and gates the result with console, network, DOM, geometry and pixel comparisons. Its README is the Chinese one; an English version sits next to it. **boyang-hu/website-rebuild-skill** — 复刻网站的 Agent Skill：抓只读镜像、从压缩代码逐行还原、自动比对验收。An agent skill that mirrors a website, rebuilds it from the minified code, and verifies the result with automated diffs. - Repository: https://github.com/boyang-hu/website-rebuild-skill - Stars: 1,346 · Forks: 248 - Language: JavaScript - License: MIT - Published: 2026-09-10 · Updated: 2026-09-10 · Language: en - Canonical page: https://hysenlabs.com/projects/boyang-hu-website-rebuild-skill ## An unregistered difference counts as a bug, not a decision Six rules run through every stage, and the project presents them as rules that repay violations later as bugs, not as style preferences. The mirror is read-only and never modified, because it is the single evidence baseline for the whole project. Source code is the only judge, so effects are never tuned by eye. Everything the original has must be present and nothing it lacks may be invented. Bugs, dead code and odd constructs are copied rather than fixed, on the grounds that every strange line in minified code may be the behaviour itself. An intentional difference must be registered, spelling out how the source does it, how the rebuild does it and why, and any difference that is not registered counts as a bug. Code and documentation land in one commit. The raycast.com keyboard page is the worked example of rule four: an unloaded lazy-load placeholder bar above the keyboard appears identically on both sides, and reproducing that broken state is the point. ## Grading runs before any work, and refusal is a designed outcome The first action is to probe which category the target belongs to and whether it can be done at all. A target that cannot be rebuilt produces a stated reason rather than a forced run that emits rubbish, and the agent gives a difficulty rating and a time estimate before it starts. Duration is stated as converging over versions: early projects were counted in weeks, small and medium sites within a few dozen routes now finish unattended from grading through to source-ification inside a single session, and heavy WebGL or proprietary engine sites take one to three days. Progress is tracked on a three-step ladder, L1 mirror archive, L2 engineered rebuild, L3 source-ification, and the ladder only goes one way, so choosing a lower level loses nothing and the run can be resumed and upgraded later. Sites that have disappeared but survive in an archive are routed into a separate rescue path instead of being abandoned. ## The installer only copies files, and it checks both directions Installing is one command, and the three forms differ only in where the directory lands: ```bash npx website-rebuild-skill # → ~/.claude/skills/website-rebuild npx website-rebuild-skill --project # → ./.claude/skills/website-rebuild npx website-rebuild-skill --dir # 其他 runtime，目录名 website-rebuild 会自动追加 ``` The first target is the user-level skills directory, the second is the project-level one, and the third takes any other runtime's skills directory and appends the directory name automatically. What the installer does not do is the interesting part: it never runs the skill, never opens a browser and never touches the network, and it has no dependencies of its own. It copies, then verifies every file in both directions by sha256, and only a full match counts as success. If the target already exists it prints the installed version and refuses, and replacement requires the force flag. A dry run flag shows what it intends to write before anything lands. The alternative path is a manual copy of the same directory: ```bash # 用户级（或项目级 .claude/skills/） cp -R skills/website-rebuild ~/.claude/skills/website-rebuild ``` ## Node 22 and a local Chrome are the whole prerequisite list Three rows, and they are specific. Node.js at version 22 or newer, because the tooling uses the built-in fetch and opens a WebSocket straight to the Chrome DevTools Protocol. Chrome or Chromium installed on the machine, used for the headless comparison. And npx, needed because individual process steps spawn version-pinned external tools without ever importing them. The same floor is enforced in package.json, where the engines field requires Node 22 or newer, so an older runtime fails at install time rather than halfway through a mirror. The repository also carries its own checks as scripts: one runs the self test, one runs a browser variant, and a third is a version gate. Nothing in that list is published to the package registry, since the files field ships only the bin directory and the skill directory, which is worth knowing before you go looking for those scripts inside an installed copy. ## Five comparison layers, and pixel equality is what unlocks the last stage Acceptance compares console, network, DOM, geometry and pixels automatically, and the project is explicit that its target is correctness rather than resemblance. The worked numbers show how strict that is. A proprietary WebGL engine site reports a mean absolute difference of 0.00 across three routes once the simulation's random state is pinned on both sides, and that pinning is the only concession to a physics-driven scene. A rebuilt AirPods Pro page ports 565 webpack modules verbatim and matches at nine scroll checkpoints. A hubtown.co.in long take driven by Theatre.js lands at 0.96, inside a noise band the pages generate themselves, and a WebGPU scene at samsy.ninja is limited by film grain baked into the asset rather than by the port. A page whose top video is pinned to the same frame on both sides returns to 0.00. The reason this matters is structural: the pixel-exact judge has to exist before refactoring begins, because splitting and renaming afterwards can be proven harmless. The file puts it plainly, that refactoring without a judge is blind refactoring. ## Source-ification must run last, and the pieces reassemble byte for byte The last stage rewrites the verbatim port into something a person can read: modules split, variables named, comments written, assets copied. Where the ported product has no module container, the tool falls back to a concatenation style decomposition, cutting the bundle into semantically named parts that can be rejoined in order to bytes identical to the original. One WebGL site ends as 389 source modules with a median length of 18 lines. One Nuxt and Vite site of 449,000 lines is cut into 2,043 semantically named parts, folded by domain into directories such as scene, camera and wave, and still reassembles byte for byte. Every start performs a per-file byte self-attestation first. Renaming, splitting and commenting in the human copy are explicitly not counted as invention, but two lines do not move: no opportunistic refactoring, since merging duplicates, extracting shared functions or changing an algorithm all make equivalence undecidable, and any speculation inside a comment has to be labelled as speculation. The deliverable also ships a byte manifest and a reassembly gate, so a fork knows exactly where it stopped matching. ## The same page advertises RSC rebuilds and files them as conditional Server-rendered component sites appear twice with different verdicts. A headline feature says even RSC sites can be reconstructed, on the reasoning that server component source is never shipped but its complete output is inlined in every page's HTML as the specification, and that a buildable Next project can be rebuilt from it and closed with a flight semantic gate. The measured results attached to that claim are a Next 16 blog on Turbopack matching 18 of 18 routes, a 144-route site passing 144 of 144, and a blind reconstruction judged against public source at roughly 95 percent structural and 98 percent behavioural agreement. Further down, the table of conditional or impossible scenarios files the same category, C1, under types that cannot be done, and its evidence line ends partway through a figure, at basement.studio followed by the digits 14 and nothing after them. Both statements sit in the same document, and the version note attached to the feature, available from v0.3, is the reconciliation offered. ## The version number exists only in package.json There are no GitHub releases. The version 0.3.23 appears in package.json and nowhere else a user can see it, while the changelog sits in the repository root and the installer will happily print an installed version to compare against. Publishing is narrow: the package ships the bin directory and the skill directory, so the docs, self test and a directory named private stay out of the tarball, even though the handoff guide the README points readers to lives inside the published skill directory at skills/website-rebuild/references/beyond-the-rebuild.md. Naming is split the same way, since the package is website-rebuild-skill while the directory an agent loads is website-rebuild, and the installer appends that directory name itself when pointed at another runtime. The keywords claim both Claude Code and Codex, and the cross-runtime claim is backed by a validation checklist containing one target Codex carried end to end with 166 of 166 response bytes identical. The page itself is the Chinese README, with the English one linked beside it, and the stated legal position is that the skill only gathers evidence and hands it over, leaving the output private and noindex and undeployed until the user rules on it. ## Conclusion This is a tool for an engineer who already owns the rights to the site being rebuilt and wants a defensible answer to whether the copy behaves like the original, and it is the wrong tool for generating a lookalike, for a site whose content you cannot mirror, or for anyone unwilling to accept that bugs from the original ship unchanged. Judge it on four things before a first run: whether your Node is 22 or newer and a local Chrome exists, which of the three levels you are committing to, that you have read the registration rule for intentional differences, and that the output stays private and noindex until you rule on deployment yourself. ## FAQ ### What does website-rebuild-skill need installed? Three things: Node.js at version 22 or newer for its built-in fetch and direct Chrome DevTools Protocol access, Chrome or Chromium installed locally for the headless comparison, and npx, which some process steps use to spawn version-pinned external tools without importing them. The same Node floor is required by the engines field in package.json. ### How do I install website-rebuild-skill? Run `npx website-rebuild-skill` to install into the user-level skills directory, add the project flag for the project-level one, or pass a directory for another runtime. The installer only copies files, verifies each one by sha256 in both directions, and refuses to replace an existing target without the force flag. A dry run shows what it would write. ### Will website-rebuild-skill publish or deploy anything? No. The stated position is that the skill only collects evidence and hands it over, and that output defaults to private, noindex and not deployed. Every judgement about whether something can be made public is left to the user rather than decided by the agent. ### What happens to bugs that exist on the original site? They are copied rather than fixed, because a strange line in minified code may be the behaviour itself. The rule is illustrated by a lazy-load placeholder that never resolves on the keyboard page being rebuilt, which appears identically on both sides as a result. ### Can website-rebuild-skill rebuild React Server Components sites? From v0.3 it claims to, by treating the flight stream inlined in each page's HTML as the specification and reconstructing a buildable Next project closed by a flight semantic gate. The same page also lists the category among its conditional scenarios, where that evidence line stops partway through a figure. ## Sources - [boyang-hu/website-rebuild-skill on GitHub](https://github.com/boyang-hu/website-rebuild-skill) - [Issues](https://github.com/boyang-hu/website-rebuild-skill/issues) - [License: MIT](https://github.com/boyang-hu/website-rebuild-skill/blob/main/LICENSE) - [README](https://github.com/boyang-hu/website-rebuild-skill/blob/main/README.md) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/boyang-hu-website-rebuild-skill