beefiker/superloopy/superloopy-clone

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.
• pathfinder: read-only navigator for target app structure, candidate selectors, route layout, existing component patterns, and asset paths. Use before broad repo searches or when multiple search angles are needed.
• forge: builder for exactly one bounded component, wrapper, or asset integration slice. Give the full spec inline, allowed files, validation command, artifact target, and SUPERLOOPY_EVIDENCE requirement.
• probe: QA lane for build/typecheck/browser checks, screenshot capture, interaction sweep replay, and evidence reports.
• sentinel: drift reviewer. Ask it to compare implementation against the component spec and call out simplified lookalikes, missing states, missing assets, and wrong interaction models.
• assayer: audit lane for high-risk evidence, source attribution, suspicious extraction gaps, and final claim review. It ends with SUPERLOOPY_AUDIT: <artifact>.
• arbiter: final gate lane for fleet status, accepted evidence, outstanding blockers, and release readiness.

Record every dispatch with superloopy loop handoff --agent <name> --assignment <self-contained task>. When a worker returns, update that handoff with --verdict <PASS|REJECT|NEEDS_CONTEXT> and --artifact <path> when accepted. Run superloopy loop fleet --json before any final completion claim. Accepted handoffs require artifacts under the active evidence root; an ack-only worker is inconclusive, never a pass.

Phase 1 - Reconnaissance

Capture the original before building:

• Full-page desktop screenshot at about 1440px.
• Mobile screenshot at about 390px.
• PAGE_TOPOLOGY.md listing sections from top to bottom, fixed layers, z-index relationships, and each section's interaction model.
• BEHAVIORS.md from scroll, click, hover, time, and responsive sweeps.
• DESIGN_TOKENS.md with fonts, colors, spacing, radii, shadows, animation timings, and global page behavior.
• ASSETS.md listing images, videos, background images, SVGs, favicons, fonts, and local target paths.
• DEPENDENCY_GRAPH.md mapping each complex section to its DOM roots, CSS blocks, JS drivers/listeners, keyframes, assets, masks, z-index layers, and third-party libraries.

Use computed styles, DOM inspection, and real assets. Do not estimate colors, spacing, text, or breakpoints when the browser can provide them.

Mandatory Interaction Sweep

Run this sweep after initial screenshots and before component specs:

• Scroll before click. Move slowly from top to bottom first, because scroll-driven sidebars, sticky panels, snap points, reveal animations, and section-aware nav can masquerade as click tabs.
• Click every interactive-looking button, tab, pill, link, card, modal trigger, carousel control, and accordion. Extract each state's content and styles.
• Hover buttons, nav items, cards, images, and links. Record before/after values and transition timing.
• Wait for time-driven elements such as autoplaying carousels, counters, marquees, videos, Lottie animations, canvas loops, and WebGL scenes.
• Repeat at desktop 1440px, tablet 768px, and mobile 390px. Record breakpoints and layout changes.

BEHAVIORS.md is the behavior source of truth. If a component spec conflicts with it, re-extract before building.

Phase 2 - Foundation

Build the shared foundation before sections:

• Fonts and metadata.
• Global CSS tokens and keyframes.
• Shared icon components from extracted SVGs.
• Content/type shapes for repeated section data.
• Downloaded assets under the project's existing public asset structure.
• A scripts/download-assets.mjs script or equivalent existing project script that downloads discovered images, videos, fonts, favicons, OG images, and binary assets into the local public asset tree with stable names.

Run the relevant build or typecheck after the foundation change and save the output under the Superloopy evidence root.

Asset Discovery Script Pattern

Run a browser-side asset inventory before writing download code. Capture at least:

• <img> sources, natural dimensions, alt text, parent classes, sibling image count, position, and z-index.
• <video> sources, posters, autoplay, loop, muted, and source children.
• CSS background images from all elements, including pseudo-layer containers.
• Inline SVG count and deduplicated icon candidates.
• Fonts from link tags and sampled computed styles.
• Favicons, apple touch icons, webmanifest, and OG images.

Layered assets matter. A single visual may be a background, foreground image, mask, overlay icon, and clipped absolute layer. Enumerate all layers before assigning a builder. Do not build mockup HTML for content that is actually video, Lottie, canvas, or WebGL.

Use browser automation to gather this shape:

JSON.stringify({
  images: [...document.querySelectorAll("img")].map((img) => ({
    src: img.currentSrc || img.src,
    alt: img.alt,
    width: img.naturalWidth,
    height: img.naturalHeight,
    parentClasses: img.parentElement?.className?.toString(),
    siblingImages: img.parentElement ? img.parentElement.querySelectorAll("img").length : 0,
    position: getComputedStyle(img).position,
    zIndex: getComputedStyle(img).zIndex
  })),
  videos: [...document.querySelectorAll("video")].map((video) => ({
    src: video.currentSrc || video.src || video.querySelector("source")?.src,
    poster: video.poster,
    autoplay: video.autoplay,
    loop: video.loop,
    muted: video.muted
  })),
  backgroundImages: [...document.querySelectorAll("*")]
    .map((element) => ({ element, backgroundImage: getComputedStyle(element).backgroundImage }))
    .filter((item) => item.backgroundImage && item.backgroundImage !== "none")
    .map(({ element, backgroundImage }) => ({
      url: backgroundImage,
      selectorHint: `${element.tagName.toLowerCase()}.${element.className?.toString().split(" ").slice(0, 3).join(".")}`
    })),
  svgCount: document.querySelectorAll("svg").length,
  favicons: [...document.querySelectorAll('link[rel*="icon"]')].map((link) => ({ href: link.href, sizes: link.sizes?.toString() })),
  fonts: [...new Set([...document.querySelectorAll("*")].slice(0, 250).map((element) => getComputedStyle(element).fontFamily))]
});

Phase 3 - Component Specs

Before building each section, write a component spec at docs/research/<hostname>/components/<component>.spec.md. The spec is the contract for implementation and must include: