/superloopy-clone

name: superloopy-clone
description: Use when the user asks for Superloopy clone or asks to clone, rebuild, reverse-engineer, replicate, or copy a website or page into a Superloopy-governed implementation. Triggers on "loopy clone", target URLs plus requests such as "clone this site", "rebuild this page", "make a copy of this website", "pixel-perfect clone", or "AI website clone". Requires browser automation and records component specs, assets, implementation, build output, and visual QA as Superloopy evidence.

Superloopy Clone

Reverse-engineer a target URL into a working local implementation with audit artifacts. Use this only for authorized cloning, migration, learning, or recovery work. Do not help with phishing, deceptive impersonation, credential capture, or evading a site's terms.

When multiple URLs are provided, process each host independently. Keep every site's research, screenshots, assets, and evidence isolated under paths like `docs/research/<hostname>/`, `docs/design-references/<hostname>/`, and `.superloopy/evidence/website-clone/<hostname>/`.

This is not "inspect once, then redraw." Act as the foreman: inspect one section, write the exact spec, dispatch or build that bounded slice, then keep extracting the next section while builders run. A hard section is where extraction gets stricter, not where approximation becomes acceptable.

Reference Example

Transferloom.com is a reference result for this workflow: `superloopy-clone` reproduced the page locally and passed desktop/mobile browser validation with preserved sticky navigation, animated hero, app preview sections, comparison table, security panel, sister app banner, footer, local assets, and a Superloopy evidence trail.

Use that bar for completion claims. A clone is successful only when it has this shape of evidence: source screenshots, research notes, component specs, downloaded assets, local browser screenshots, validation output, visual QA notes, and a final evidence artifact.

Superloopy Contract

• Create or reuse a Superloopy plan. Use an evidence root like `.superloopy/evidence/website-clone/<hostname>/`.
• Preserve extraction artifacts: screenshots, topology, behavior notes, component specs, asset inventory, validation output, and visual QA notes.
• Record final proof with `SUPERLOOPY_EVIDENCE: <path-under-active-evidence-root>` when a worker is involved, or `superloopy loop evidence` when recording from the parent.
• Do not add dependencies without asking. If a clone needs a package for parity, explain why and get approval first.

Scope Defaults

Unless the user gives different requirements, clone exactly what is visible at the target URL:

• Fidelity: pixel-focused parity for layout, spacing, typography, color, animation, responsive behavior, and visible interactions.
• In scope: visual layout, component structure, client-side interactions, responsive design, local assets, and demo data needed to render the page.
• Out of scope: real backend, authentication, payment flows, analytics, SEO optimization, and accessibility audit unless the user explicitly asks.
• Customization: none. Do not improve, restyle, rewrite copy, or replace assets during extraction.

Fidelity Gate

Pixel-perfect means the default is extraction-first, not inspired reconstruction. If a section is driven by custom JavaScript, CSS keyframes, canvas, video, Lottie, WebGL, marquees, scroll timelines, masks, or layered absolute positioning, use **verbatim port** mode first:

• Preserve the original DOM subtree, CSS class block, and JS driver, then adapt asset URLs and framework boundaries.
• Write a dependency graph for the section: DOM roots, CSS selectors/keyframes, scripts/listeners, assets, timing, z-index, masks, and external libraries.
• Reimplementation is allowed only after proving the original implementation cannot be ported cleanly, recording why in the spec, and getting user approval when fidelity would drop.
• An unapproved approximation of an above-the-fold, animated, fixed, sticky, or interaction-heavy section is a blocker, not a known gap.
• Do not choose a similar redraw because the section is difficult. Dissect the original implementation and transplant it; if you cannot, stop and report the blocker with evidence.

Preflight

1. Verify browser automation is available. Prefer Chrome or Playwright-style tools. If none are available, ask for a browser tool before proceeding. 2. Normalize and validate each target URL. Confirm the page loads. For multiple targets, prepare separate `docs/research/<hostname>/` and `docs/design-references/<hostname>/` folders before extraction. 3. Inspect the local app stack and existing commands before editing. Run the smallest existing check that proves the baseline, such as `npm run build`, `npm run typecheck`, or `npm test`. 4. Create research folders if needed: `docs/research/<hostname>/`, `docs/research/<hostname>/components/`, `docs/design-references/<hostname>/`, `scripts/`, and the Superloopy evidence root. 5. State authorization assumptions if the target is a third-party site.

Superloopy Crew Dispatch

Use Superloopy actively when the clone has independent extraction, build, QA, or review lanes. Superloopy handoffs are parent-side bookkeeping; the host spawns workers, while Superloopy records and reconciles them.

• Treat `loopy team ... loopy clone`, `loopy team <url> clone`, `loopy crew ... clone`, `loopycrew ... clone`, and `ultrawork ... clone` as full-crew clone requests. Start with the crew plan, split extraction/build/QA/review lanes early, and record handoffs from the first dispatched lane.
• A plain `loopy clone` may stay solo only for a small static page or one clearly bounded component. The moment there are multiple sections, responsive states, animations, unknown assets, or parallelizable QA/review work, escalate to crew dispatch instead of continuing solo.
• `nami`: read-only navigator for target app structure, candidate selectors, route layout, exi