URL to HTML

Clone a live URL as a real, interactive, frontend-only local app or website. The clone should look and interact like the source — you are copying an existing page, not designing a new one.

Self-contained: this skill does not require any other skill to be installed. Where a companion skill (mdbox-media, taste-frontend) is available it's used opportunistically, but every step has a built-in fallback.

0. Gate — is this actually a clone request?

Continue only when the user wants to reproduce an existing page as-is:

• ✅ "clone this site", "recreate this page", "copy <url> locally", "rebuild this exactly".
• ❌ "make something like this", "better", "redesign", "improve", "inspired by" → that's a design task, not a clone. Hand off to a design skill (e.g. image-to-code for an image, or a general frontend build) instead.
• ❌ Source is an image / screenshot, not a live URL → use image-to-code.

Legality gate (state this to the user before capturing): only clone pages the user owns or has permission to recreate, and they must respect the target site's terms. Say this once, then proceed.

1. Capture the source with webread

webread <url> is the capture tool — it renders the page (including JS-rendered content) and returns the DOM, text, and structure. Use it, not raw curl/HTML-only fetches, so single-page-app content is included.

Check the page is the right one first. Do not continue if webread returns a login wall, a blocked/consent page, a promo/app-install interstitial, a loading skeleton, an error page, or an unrelated redirect. If capture is blocked, stop and tell the user exactly what you can see and ask how to proceed (e.g. provide HTML, a screenshot, or an authenticated export).

Capture thoroughly — desktop first, then mobile (390 × 844):

• Read the full page top to bottom; note every section (header, hero, feature rows, gallery, footer, sticky bars).
• Pull everything needed to rebuild it:
  • Structure & components, all text and links, buttons/controls and their states
  • Images, icons, logos, SVGs, videos, background images
  • Fonts (families, weights), colors, spacing, layout sizes, responsive behavior
• Identify interactions: nav, menus, drawers, modals, tabs, carousels, hover/focus/active states, sticky elements, form inputs. Note what each one does so you can reproduce the behavior, not just the static look.

Build a short capture inventory (sections, assets, fonts, colors, interactions) before writing any code. Do not scaffold or write app code until desktop + mobile are captured and the asset/font/icon list is resolved or has a fallback.

2. Assets — use the real ones, never fake them

CRITICAL RULE — never substitute CSS art, hand-drawn/inline SVG, div/gradient "art", emoji, or text glyphs for real image assets or real icons. That is the #1 way a clone looks wrong.

Copy the real assets the page loads. If the page uses an image, logo, icon, font, video, SVG, sprite, or background image, save it locally and reference the local copy. Do not hotlink source assets in the final app.

When an asset can't be copied, replace it — and note the swap:

• Image / logo / illustration / background → regenerate with mdbox-media using the gpt-image-2 model, matching the original's aspect ratio, dimensions, palette, and art direction (use a screenshot/description of the original as the reference). If mdbox-media is not installed, use https://picsum.photos/seed/{descriptive-seed}/{w}/{h} for photo slots and leave a labeled <!-- TODO: real asset WxH, matches source -->, then list what's still needed at handoff.
• Font → closest freely-available match (Google Fonts / self-host).
• Icon / glyph → closest-matching open-source icon set. Do not default to Lucide unless it genuinely is the closest match — check first.
• Text baked into an image (hero art, signage, packaging) stays in the image; don't rebuild it as overlaid HTML/CSS text.

Briefly note any asset, font, or icon you replaced and why.

(You can generate assets in parallel with scaffolding — do critical above-the-fold assets first. Keep asset generation separate from code edits so neither blocks the other.)

3. Build — from captured evidence only

Recreate the page as a frontend-only local app. Build only from what you captured or copied:

• Do not add new visual ideas, invent sections, or "improve" the design — this is a clone.
• Do not build from memory, screenshots alone, guessed CSS, or generic assets when source evidence exists.
• Do not leave temporary CSS/emoji/placeholder blocks "until assets are ready" — resolve assets first (§2), then build.

Make it actually interactive — reproduce the interactions you captured (nav, menus, modals, tabs, carousels, hover/focus states, form inputs as visual/local behavior). No backend, auth, or persistence — frontend only.

Stack

• Adapt to an existing project if one is present (check package.json for react/next/vue/svelte, etc.) and build in that stack.
• New project → Vite + React + Tailwind by default. The project must expose an npm dev script.
• If taste-frontend happens to be installed, you may use it for build discipline — but do not require it. This skill stands alone.

CRITICAL — relative asset paths (or the published page is blank)

The final build is served from a sub-path (/api/v1/media/<project-id>/public/), not the site root. A bundler's default of absolute asset URLs (/assets/…) makes the browser look at the root — the files aren't there → 404 on JS/CSS → blank page. Every asset reference must be relative to the entry HTML.

• Vite → set base: './' in vite.config.js. After build, verify the emitted dist/index.html references ./assets/… (relative), not /assets/… (absolute). This is the single most common failure of published clones — do it up front.
• Other bundlers → set the equivalent public-base / homepage to relative:
  • CRA / react-scripts: "homepage": "." in package.json.
  • Next.js static export: not path-portable by default — prefer Vite for a portable static clone, or set assetPrefix/basePath and verify.
  • Plain HTML: use relative src/href (./… or bare assets/…), never leading-/ paths.
• In-code asset references (images, fonts, fetches) must also be relative — ./logo.png / imported assets, never /logo.png.

4. Run + verify against the source (blocking gate)

Starting a dev server is not verification. Verification means rendering the clone in a browser and comparing it to the source.

1. Install deps if needed; run npm run dev (ensure Vite binds a host/port you can open). Serve a static build directly if there's no dev server.
2. Open the rendered clone and capture screenshots at the same viewports and interaction states as the source (desktop + 390 × 844 mobile). If the source shows an open menu/modal state, capture that state on both sides.
3. Visual QA (blocking) — write design-qa.md in the project root:
   • Compare source vs clone side by side, per viewport and per captured interaction.
   • Tag each issue P0 (broken/wrong), P1 (clearly off), P2 (noticeable), P3 (polish).
   • Fix P0/P1/P2, re-capture, repeat until the report can say final result: passed. Don't loop on P3 — list remaining P3s as follow-ups.
   • If source capture, clone capture, or the comparison is blocked, stop and set design-qa.md to final result: blocked with the reason.

Do not hand off unless design-qa.md exists and says final result: passed (or is clearly reported as blocked).

Mobile: target 390 × 844 unless the source is clearly a different device. No horizontal scroll, no clipped text/controls, no off-screen primary actions.

5. Handoff — publish and give a clickable link

Only after design-qa.md says final result: passed. Never leave the result only on disk, and never hand out a localhost/port URL for a static clone. Publish it inline (no dependency on any other skill):

1. Produce a relative-path build. Confirm base: './' (or the stack equivalent from §3) is set, then build. Grep the built index.html and confirm every src/href is relative (./assets/…), with no leading-/ absolute paths — an absolute /assets/… reference here means the published page will be blank. Fix and rebuild before publishing.
2. Save the build under public/ in the work dir — public/index.html (or the entry file) with all assets (images, css, js, generated_images/) copied under public/ so the relative links resolve. Create public/ if missing. (Copy the built dist/ contents into public/, don't just move the HTML.)
3. Resolve <project-id> = the current project's folder name (the UUID that is the last path segment of the working directory). Read it from cwd — do not hardcode or invent one.
4. Post a clickable Markdown link as the final message:

   [页面标题](/api/v1/media/<project-id>/public/index.html)
   

   SmartJ serves public/ directly at that media URL — no server, no port needed. Before printing the link, verify the entry file and its assets are actually present under public/ (e.g. public/assets/… exist).

Then summarize: what you cloned, what's interactive vs visual-only, any assets/fonts/icons you replaced (and why), and any remaining P3 follow-ups or still-needed real assets.

Only start a real server/port if the clone genuinely needs a live backend/API — a frontend-only clone never does. Static → always the public/ media link.

Anti-patterns (fail conditions)

• Treating "make something like this / better / redesigned" as a clone — that's a design task, wrong skill.
• Cloning from a written brief or an image instead of a live URL (image → image-to-code).
• Capturing with HTML-only fetch and missing JS-rendered content — use webread.
• CSS/SVG/emoji/div-shape "art" or hand-drawn icons standing in for real image assets or icons.
• Hotlinking source assets in the final app.
• Publishing an absolute-path build (/assets/…) under public/ — served from the media sub-path it 404s and the page is blank. Build with base: './' (relative paths) and verify the built HTML before publishing.
• Building from memory/screenshots/guessed CSS when source evidence was available.
• Rebuilding baked-in image text as overlaid HTML/CSS.
• Declaring done on "dev server started" without a browser comparison to the source.
• Requiring another skill to be installed — this skill must complete on its own.
• Handing off with the result only on disk, or with a localhost:<port> link, instead of the public/ media link.