Clone Website
Reverse-engineer a target URL into pixel-perfect frontend specs and fan out parallel builder agents in isolated worktrees as each section is extracted.
Overview
clone-website is an agent skill most often used in Build (also Validate prototype) that reverse-engineers URLs into section specs and parallel frontend builder runs for pixel-perfect clones.
Install
npx skills add https://github.com/julianromli/ai-skills --skill clone-websiteWhat is this skill?
- User-invocable with argument-hint for one or many URLs processed in parallel
- Foreman workflow: extract section specs to files, dispatch specialist builders immediately—not inspect-then-build
- Default pixel-perfect fidelity for colors, spacing, typography, and animations
- Per-host artifact isolation under docs/research/<hostname>/
- Triggers on clone, replicate, rebuild, reverse-engineer, and copy-site phrasing
- Parallel builder agents dispatched per extracted section
- Per-host paths like docs/research/<hostname>/
Adoption & trust: 1.1k installs on skills.sh; 167 GitHub stars; 2/3 security scanners passed (skills.sh audits).
What problem does it solve?
You have a reference site but no systematic way to extract sections and spin up parallel implementers without losing fidelity or mixing multi-URL artifacts.
Who is it for?
Indie builders rebuilding a known-good landing, cloning their own legacy site, or parallel-cloning several reference pages for A/B structure tests.
Skip if: Greenfield brand design with no reference URL, backend-only API work, or copying competitor sites without legal clearance.
When should I use this skill?
User wants to clone, replicate, rebuild, reverse-engineer, or copy a website; phrases like make a copy of this site or pixel-perfect clone with one or more URLs.
What do I get? / Deliverables
Each hostname gets isolated research folders, section-level specs, and parallel worktree builds that converge on a pixel-perfect replica of what is visible at the URL.
- Section-level spec files per hostname
- Extracted assets and CSS notes
- Parallel frontend implementation in worktrees
Recommended Skills
Journey fit
Spans multiple journey phases - primary shelf plus alternate fits below.
Clone-website is shelved under Build frontend because its primary deliverable is reconstructed UI fidelity, even when it also supports validate-time landing clones. Frontend is the canonical shelf for section-by-section CSS, assets, typography, and layout reproduction rather than backend API design.
Where it fits
Stand up a credible pricing landing clone from a reference URL before interviewing users.
Rebuild the marketing homepage section-by-section while builder agents start in parallel worktrees.
Replicate a high-converting page layout for a new campaign URL with identical spacing and motion.
How it compares
Use for orchestrated multi-agent site cloning, not for a single-shot HTML save or a generic CSS linter.
Common Questions / FAQ
Who is clone-website for?
Solo builders and small teams using Claude Code-style agents who want pixel-perfect UI reproduction from live URLs with parallel implementation.
When should I use clone-website?
During Validate when you need a credible landing prototype from a reference URL; during Build frontend when rebuilding marketing or app shells; during Launch distribution when duplicating a proven page structure for a new offer.
Is clone-website safe to install?
The skill drives network fetches and filesystem writes in worktrees—review target site terms and your repo hygiene. Check the Security Audits panel on this Prism page before enabling in shared environments.
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