Clone Website
Clone one or more live URLs into pixel-perfect static or app frontends while parallel builder agents work from section specs in isolated worktrees.
Overview
clone-website is an agent skill most often used in Build (also Validate for quick visual prototypes) that reverse-engineers target URLs section-by-section and dispatches parallel builder agents from auditable extraction
Install
npx skills add https://github.com/jcodesmore/ai-website-cloner-template --skill clone-websiteWhat is this skill?
- Foreman workflow: extract each visible section, write auditable specs, dispatch parallel builder agents as you go—not in
- Default pixel-perfect fidelity for colors, spacing, typography, and animations unless the user overrides scope.
- Multi-URL support with per-host artifact folders (e.g. docs/research/<hostname>/) and isolated parallel processing.
- Triggers on clone, replicate, rebuild, reverse-engineer, copy site, and pixel-perfect clone phrasing with URL arguments.
- Argument hint supports one or more target URLs in a single invocation.
- Foreman model: parallel extraction and construction per visible section (not a fixed two-phase inspect-then-build checkl
Adoption & trust: 433 installs on skills.sh; 16.6k GitHub stars; 0/3 security scanners passed (skills.sh audits).
What problem does it solve?
You have a reference site or competitor page but no structured spec or parallel pipeline to rebuild it faithfully without weeks of manual layout work.
Who is it for?
Solo builders cloning marketing pages, portfolios, or multi-page references who already use agent worktrees and want extraction plus build in one orchestrated pass.
Skip if: Teams that only need loose inspiration, lack permission to copy the target site, or want backend or auth flows replicated without explicit scope—the skill clones what is visible at the URL by default.
When should I use this skill?
User wants to clone, replicate, rebuild, reverse-engineer, or copy any website; phrases like make a copy of this site, rebuild this page, or pixel-perfect clone; provide target URL(s) as arguments.
What do I get? / Deliverables
You get isolated extraction artifacts per hostname, detailed per-section specification files, and parallel builder agents producing a pixel-aligned rebuild of each provided URL.
- Per-hostname extraction artifacts and section specification files
- Pixel-aligned frontend rebuild for each URL in scope
Recommended Skills
Journey fit
Spans multiple journey phases - primary shelf plus alternate fits below.
Canonical shelf is Build because the skill’s output is rebuilt UI, assets, and layout—not discovery or distribution. Frontend is the primary artifact: CSS, typography, spacing, animations, and per-section visual fidelity from the target page.
Where it fits
Mirror a competitor landing URL to validate layout and messaging before committing to your own design system.
Rebuild the hero, features, and footer sections from specs while a second agent handles another URL in parallel.
Store per-hostname research under docs/research for auditable handoff to future redesigns.
Diff cloned output against the reference for spacing and typography before launch.
How it compares
Use instead of ad-hoc “screenshot and guess CSS” chats when you need filed section specs and parallel specialist agents rather than a single monolithic rewrite.
Common Questions / FAQ
Who is clone-website for?
Indie and solo builders using Claude Code–style agents who need to replicate one or more public web pages with documented section specs and parallel frontend builders.
When should I use clone-website?
In Validate when you want a visual prototype that mirrors a live reference; in Build when you are implementing the real frontend from that reference; and anytime the user asks to clone, replicate, rebuild, or pixel-perfect copy a URL with arguments.
Is clone-website safe to install?
Treat cloning third-party sites as a legal and licensing decision you own; review the Security Audits panel on this Prism page before installing and avoid copying sites you do not have rights to reproduce.
SKILL.md
READMESKILL.md - Clone Website
# Clone Website You are about to reverse-engineer and rebuild **$ARGUMENTS** as pixel-perfect clones. When multiple URLs are provided, process them independently and in parallel where possible, while keeping each site's extraction artifacts isolated in dedicated folders (for example, `docs/research/<hostname>/`). This is not a two-phase process (inspect then build). You are a **foreman walking the job site** — as you inspect each section of the page, you write a detailed specification to a file, then hand that file to a specialist builder agent with everything they need. Extraction and construction happen in parallel, but extraction is meticulous and produces auditable artifacts. ## Scope Defaults The target is whatever page `$ARGUMENTS` resolves to. Clone exactly what's visible at that URL. Unless the user specifies otherwise, use these defaults: - **Fidelity level:** Pixel-perfect — exact match in colors, spacing, typography, animations - **In scope:** Visual layout and styling, component structure and interactions, responsive design, mock data for demo purposes - **Out of scope:** Real backend / database, authentication, real-time features, SEO optimization, accessibility audit - **Customization:** None — pure emulation If the user provides additional instructions (specific fidelity level, customizations, extra context), honor those over the defaults. ## Pre-Flight 1. **Browser automation is required.** Check for available browser MCP tools (Chrome MCP, Playwright MCP, Browserbase MCP, Puppeteer MCP, etc.). Use whichever is available — if multiple exist, prefer Chrome MCP. If none are detected, ask the user which browser tool they have and how to connect it. This skill cannot work without browser automation. 2. Parse `$ARGUMENTS` as one or more URLs. Normalize and validate each URL; if any are invalid, ask the user to correct them before proceeding. For each valid URL, verify it is accessible via your browser MCP tool. 3. Verify the base project builds: `npm run build`. The Next.js + shadcn/ui + Tailwind v4 scaffold should already be in place. If not, tell the user to set it up first. 4. Create the output directories if they don't exist: `docs/research/`, `docs/research/components/`, `docs/design-references/`, `scripts/`. For multiple clones, also prepare per-site folders like `docs/research/<hostname>/` and `docs/design-references/<hostname>/`. 5. When working with multiple sites in one command, optionally confirm whether to run them in parallel (recommended, if resources allow) or sequentially to avoid overload. ## Guiding Principles These are the truths that separate a successful clone from a "close enough" mess. Internalize them — they should inform every decision you make. ### 1. Completeness Beats Speed Every builder agent must receive **everything** it needs to do its job perfectly: screenshot, exact CSS values, downloaded assets with local paths, real text content, component structure. If a builder has to guess anything — a color, a font size, a padding value — you have failed at extraction. Take the extra minute to extract one more property rather than shipping an incomplete brief. ### 2. Small Tasks, Perfect Results When an agent gets "build the entire features section," it glosses over details — it approximates spacing, guesses font sizes, and produces something "close enough" but clearly wrong. When it gets a single focused component with exact CSS values, it nails i