AI Website Cloner Template: cloning a site into Next.js with a coding agent

The problem: a live site with no usable source

The README names two situations. The first is platform migration: a site running on WordPress, Webflow or Squarespace that someone wants in a modern Next.js codebase. The second is lost source code, where the site is live but the repository is gone and the original developer has left. Both are cases where the visual reference exists and the implementation does not.

Hand-rebuilding those pages is slow in a specific way. The work is not hard, it is numerous: every font weight, every hover state, every breakpoint, every icon. A developer with the site open in one window and an editor in the other spends most of the time reading computed values off a devtools panel and typing them into a stylesheet.

The template targets that reading-and-typing loop. It assumes you have a coding agent that can drive a browser, and it gives the agent a written procedure for extracting the design and rebuilding it. The intended user is a developer who already pays for an agent subscription and wants the reconstruction work delegated rather than performed.

One boundary is set explicitly and it is worth stating plainly: the README instructs you to use GitHub's Use this template button and create your own repository, and says not to clone the template repository directly for your website project or open pull requests here with your generated website. The template is scaffolding for your project, not a shared output repository.

The five-phase pipeline behind /clone-website

The skill runs a pipeline the README diagrams as five stages. Reconnaissance takes screenshots, extracts design tokens, and sweeps interactions: scroll, click, hover and responsive states. Foundation updates fonts, colors and globals, and downloads the assets. Component Specs writes files under docs/research/components/ containing exact computed CSS values, states, behaviors and content. Parallel Build dispatches builder agents into git worktrees, one per section or component. Assembly and QA merges the worktrees, wires up the page, and runs a visual diff against the original.

The design decision worth noticing is phase three. Rather than letting each builder agent look at the reference site independently, the pipeline front-loads the extraction into written spec files and hands each builder the full component specification inline. The README claims the agents receive exact getComputedStyle() values, interaction models, multi-state content, responsive breakpoints and asset paths, and that this removes guessing.

That is a real architectural choice with a real cost. Serialising the design into text before any component is built means the spec files become the source of truth, so an error in extraction propagates into every builder that reads it. It also means the pipeline is only as good as the reconnaissance phase's coverage of states. A component whose interesting behaviour only appears after a network response, or behind a login, is unlikely to be captured by a scroll-click-hover sweep.

The parallel build is the other structural bet. Git worktrees keep concurrent agents from writing over each other, and the merge in phase five is where that bet is settled. The README does not document what happens when two worktrees touch the same shared component.

Installing the template and running a first clone

The README's prerequisites are Node.js 24 or later and an AI coding agent from the supported list. Note that the install path is not a package install: the first step happens in the browser. On the project's GitHub page you click Use this template, then Create a new repository, give it a name, choose visibility, and create it. If GitHub offers an Include all branches option, the README says you can leave it off.

Once your own repository exists, clone that copy and install dependencies. The README's terminal example is:

git clone https://github.com/YOUR-USERNAME/YOUR-NEW-REPOSITORY.git
cd YOUR-NEW-REPOSITORY
npm install

With dependencies in place, start your agent. The README recommends Claude Code, and its example command is:

claude --chrome

The --chrome flag matters here: the reconnaissance phase takes screenshots and sweeps interactions, so the agent needs browser access. Then invoke the skill with one or more target URLs:

/clone-website <target-url1> [<target-url2> ...]

Most supported clients expose /clone-website directly, according to the README. If yours activates skills from natural-language requests instead, the fallback phrasing given is Clone <target-url> using the clone-website workflow. Project instructions live in AGENTS.md.

The repository also ships a Docker path. docker-compose.yml defines an app service built from the Dockerfile runner target, publishing ${PORT:-3000} to container port 3000, and a dev service on ${DEV_PORT:-3001} that bind-mounts the working directory and keeps /app/node_modules and /app/.next in anonymous volumes. Both read .env.local and .env if present, and both carry a wget healthcheck against localhost:3000. The Dockerfile defaults to node:24.14.1-slim and installs with npm ci when a package-lock.json is found. For a first clone, though, the browser-and-terminal route above is the one the README walks through.

What the pipeline does not promise you

The README is silent on rollback. There is no documented way to undo a clone that went badly, no snapshot step before the parallel build, and no described behaviour for a merge conflict between worktrees. Since builder agents commit into git worktrees, your own git history is the only recovery mechanism the material implies, and that is an inference rather than a documented feature.

Cost is the second gap. The pipeline dispatches multiple builder agents, each receiving a full component specification inline, and the README's recommendation is Claude Code with Opus 5. A multi-page clone on a large site therefore means many agent invocations against a frontier model. The README does not estimate token usage or give a per-site figure, so budget is something you measure yourself on a small target before pointing it at a marketing site with forty sections.

The third limitation is the output format. This produces a Next.js 16 App Router project with React 19, TypeScript strict, shadcn/ui on Radix primitives, and Tailwind CSS v4 with oklch design tokens. If what you actually want is a static HTML mirror, a Wget-style archive, or a WordPress theme, the pipeline is aimed somewhere else entirely. The repository's own keywords list includes website-clone and reverse-engineering, but the deliverable is a codebase.

Finally, the README does not discuss the legality of cloning a site you do not own. That is not a documentation defect so much as an omission the user is expected to fill in, and the template's stated use cases are all framed around sites you own.

How this differs from a scraper or an HTML mirror

The obvious alternative is a site mirroring tool such as HTTrack or wget's recursive download mode, and the difference is not quality, it is category. A mirror fetches the rendered or served HTML, CSS, JavaScript and assets, rewrites links, and writes a directory tree you can open locally. It preserves the original markup, including whatever framework artefacts, inline styles and third-party scripts the site shipped.

This template does the opposite. It throws away the original markup and reconstructs the page as React components in a Next.js App Router project, using shadcn/ui and Tailwind v4 tokens. You get readable source you can edit, type-check and build, and you lose any fidelity guarantee that comes from copying bytes. A mirror is closer to the original by construction; this is closer to a codebase by construction.

That distinction decides which tool fits. Migrating off Webflow into something your team maintains: the template is aimed at that. Archiving a site before it goes offline, or capturing it for offline reading: a mirror is the right instrument, and running an agent pipeline over it would be an expensive way to get a less faithful result.

The other comparison worth drawing is against doing it by hand with devtools open. The template does not replace that judgement, it automates the reading. The spec files under docs/research/components/ are the artefact a human would otherwise keep in their head, and reviewing them is the natural place to catch an extraction mistake before builder agents act on it.

Licence, maintenance and the cost of staying current

The repository is MIT licensed, and package.json declares "license": "MIT" with "private": true. The private flag means the template package itself is not published to npm, which is consistent with the Use this template distribution model. MIT is permissive: it allows commercial use, modification and redistribution with the licence and copyright notice retained. What MIT does not do is grant you any rights to the site you clone. The licence covers the template's code, not the design, copy, images or trademarks of the reference site, and nothing in the repository can transfer those. Whether a given clone is permissible is a question for your own counsel, not for the README.

On maintenance, the last push was on 2026-08-10, which coincides with the v0.4.0 release, Expanded Agent Support and Reliable Multi-Page Cloning. The release history is short and legible: v0.3.0 added multi-URL cloning and CI quality gates, v0.3.1 fixed Windows CRLF handling in the agent rules sync, and v0.4.0 widened agent support. The version in package.json matches the release at 0.4.0.

Upgrade cost is driven by the stack rather than the template. Next.js 16.3.0, React 19.2.4 and Tailwind v4 are pinned, and Node 24 is the floor in both engines and the Dockerfile's NODE_VERSION default. Because you work in your own generated repository, upgrading the template is not an npm update: you would pull changes from the upstream template into your copy by hand. The scripts give you a single gate for that work, npm run check, which chains lint, typecheck and build. The .github/ directory and the v0.3.0 note about CI quality gates suggest the same gate runs in CI.

Editorial conclusion

Adopt it if you own the site being rebuilt and you already work inside Claude Code, Codex, Cursor or one of the other listed clients, because the output is a Next.js 16 App Router codebase and not a static export. Skip it if you want a downloadable HTML mirror, if your Node runtime is below 24, or if the reference site is one you have no rights to reproduce. Verify three things before you commit a sprint: that your agent client actually exposes /clone-website or can trigger it from natural language, that the parallel build step's git worktrees behave in your environment, and that the visual diff in the assembly phase produces a baseline you consider acceptable. The README's own framing of the use case, rebuilding a site you own out of WordPress, Webflow or Squarespace, is the honest boundary of the tool.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes