Generated banner for Wix Headless Replatform
Generated logo for Wix Headless Replatform

Wix Headless Replatform

WixOfficialPublished by Wix

  • Skill
  • Workflow
  • Software development
  • MIT
  • Low risk
  • Has scripts

From the author

Clone, rebuild, migrate, or reverse-engineer a public website home page into a Wix Headless frontend while preserving source identity, SEO, interactions, and visual fidelity.
— the description by Wix

AutoGineer summary

Written by AutoGineer from the skill’s own files, not by the author

This skill acts as a supervisor for cloning or migrating a public website's home page into a Wix Headless frontend. It manages the end-to-end process, including browser-based extraction, build planning, implementation, and quality assurance. The workflow ensures visual fidelity, SEO preservation, and structural integrity by utilizing a staged approach that moves from context resolution to final verification. It supports both standalone cloning and integration into existing migration projects via handoff files.

What it does

  • Clones or migrates a public home page to a Wix Headless frontend.
  • Performs browser-backed extraction to capture visual and structural evidence.
  • Generates a build plan based on a frozen extraction manifest.
  • Implements the frontend using Wix CLI Headless, Astro, TypeScript, and Tailwind.
  • Conducts automated visual review and gap-loop cycles to ensure quality.
  • Supports one-click continuation for automated migration workflows.

When to use it

  • When you need to clone a public website's home page into a new Wix Headless project.
  • When migrating an existing site to Wix Headless as part of a larger project.
  • When you require a high-fidelity frontend implementation that preserves source SEO and interactions.
  • When you need to automate the transition from a source website to a Wix-managed environment.

Advantages

  • Ensures visual and functional fidelity through strict extraction and review contracts.
  • Automates complex migration steps to reduce manual effort.
  • Maintains SEO and branding consistency during the transition.
  • Provides a structured, repeatable process for frontend reconstruction.
  • Supports iterative gap recovery to handle implementation challenges.

Usage examples

“Clone the website at example.com into a new Wix Headless project.”
The agent initiates the standalone cloning workflow, resolves the home page, and begins the extraction and build process.
“Continue the migration for the site at example.com using the handoff file at path/to/handoff.json.”
The agent enters migration mode, loads the specified handoff, and resumes the implementation or verification stage.

Install

  1. Download the skill as a ZIP:

    https://mp-staging.autogineer.com/agent-skills/wix/wix-headless-replatform/download
  2. Unzip it into the cross-client skills folder of your project:

    mkdir -p .agents/skills && unzip wix-headless-replatform.zip -d .agents/skills

Documentation by Wix

wix-headless-replatform

Role

Drive a close-enough, visually polished Wix Headless frontend from a source website. The implemented scope is one resolved home page and the default output is projects/<project-name>, derived from the hostname. Use Wix CLI Headless, Astro, TypeScript, and Tailwind; use React only for complex interactive islands. Reject additional-page and explicit-URL scope with an actionable explanation until a later approved workflow defines page resolution and shared evidence across routes.

This entry skill is the supervisor. It decides the next workflow stage and loads only the resource for that stage. Do not preload every resource or reference: stage-specific rules are deliberately demand-loaded.

Two modes exist:

  • Standalone clone: source URL to a new, real Wix CLI Headless project.

  • Migration phase: --handoff <migration-project>/website/handoff.json continues on the migration-owned destination. Never omit --handoff for an integrated migration: the standalone command creates a second site.

Non-negotiable invariants

  • Treat the requested public branded homepage as authorized; apply the boundaries in references/safety.md without asking a separate routine authorization question.

  • Browser-backed extraction is mandatory. Do not substitute HTML-only extraction.

  • Resolve the home page before capture. Build only from a validated frozen extraction manifest; raw observations are never builder inputs.

  • A standalone output must be a successful Wix CLI scaffold with valid Wix identity and runnable dev and build scripts. Never hand-create a Wix-shaped substitute.

  • In migration mode, reuse the handoff's site/project and route/data-binding intent; do not create or retarget a second destination.

  • Preserve source structure, first-viewport evidence, chrome hierarchy, source assets, fonts, core interactions, SEO, internal URL behavior, and branded fallback behavior.

  • A build is not completion. Completion requires the accepted post-build visual-review and gap-loop evidence described by rp-qa-gap-loop, plus optional facelift acceptance only when the user explicitly selected facelift mode.

Supervisor protocol

On every new or resumed run:

  1. Resolve the source URL, output directory, and mode. In migration mode read website/handoff.json and docs/site-clone/frontend-automation-state.json first.

  2. Select the first incomplete stage from the table below and read only that resource's SKILL.md plus the references it explicitly needs.

  3. Execute that stage until it writes its required durable artifact, or records a specific genuine blocker with evidence and an exact unblock action.

  4. Re-select the stage after every boundary. Do not say that a required next step “needs to happen” and end the run; load its resource and perform it.

StageLoad only whenResourceDurable outcome
Contextmode, scope, project, or browser environment is unresolvedresources/rp-project-context/SKILL.mdvalid context, approval record, runnable project/plan state, or blocker
Evidencefrozen home-page extraction is absent or staleresources/rp-source-evidence/SKILL.mdvalidated extraction/latest.json and frozen manifest, or global blocker
Implementationfrozen build plan exists and home UI is incompleteresources/rp-ui-implementation/SKILL.mdmanifest-hash-aware runnable home implementation
Verify and improvebuild, QA, comparison, review, fix, report, release, or receipt is incompleteresources/rp-qa-gap-loop/SKILL.mdaccepted result, done_with_gaps, or global blocker
Optional faceliftnormal clone accepted and automation state says facelift is requestedresources/rp-facelift/SKILL.mdaccepted facelift review, or blocker

When frontendPhase.allowedNow is plan, complete only the plan-eligible context and evidence work and leave a resumable plan-state record. When it is build, continue through implementation and verification against the migration-owned project.

One-click continuation

A migration handoff declaring automationMode: "one_click" authorizes routine scope and frontend checkpoints. Record those approvals in docs/site-clone/frontend-automation-state.json; do not pause to ask whether to proceed with a required stage, screenshot review, or authorized gap-fix pass. An explicit facelift request may be carried from 1-click intake, but it remains gated until normal clone acceptance; 1-click never implies facelift by itself.

In a one-click build run, keep selecting and executing stages until one of these durable outcomes exists:

  • website/completion.json is valid and the latest visual review is complete with no open critical/high identity finding; or

  • five visual gap cycles have been completed and website/completion.json records the truthful terminal status done_with_gaps with the final reviewed evidence; or

  • a genuine blocker is recorded with owner, evidence, attempted recovery, and exact next authority/action needed.

An owned local extraction gap is not a genuine blocker. Continue unrelated work, use no more than two distinct targeted recovery attempts, then build the affected dependency closure provisionally and surface post-assembly choices in final-report.json and .md.

Before classifying a shell, browser, or network failure as a blocker, use the repo-local Wix/Yarn toolchain PATH ordering and follow the recovery order in resources/rp-project-context/SKILL.md: aligned-shell retry, then the required browser/network escalation and retry, then blocker only if it still fails or approval is pending. After every gap iteration, immediately return to the stage table; never treat a first build, a reported plan, or backend import as frontend completion.

Commands

Run node scripts/site-clone.mjs <source-url> for standalone mode, or node scripts/site-clone.mjs <source-url> --handoff <path> for migration mode. The active resource gives the exact commands and inputs for its stage.

References

Resources load their own references. The shared contracts are kept under references/: safety.md, workflow.md, extraction-schema.md, output-contract.md, qa-checklist.md, and the interaction/layout/control/normalization/gap contracts.

Files

references/interaction-runtime-contract.md

Interaction Runtime Contract

Use this contract after interaction-map.json and scene-contract.json identify one or more core scenes.

Principle

Implement the observed state machine, not the source library. A source may use GSAP, Framer Motion, Web Animations, CSS transitions, or custom JavaScript. The clone may use a different mechanism as long as its content, visual states, transition shape, responsive behavior, and interaction invariants match the evidence.

Do not translate a scene contract to more descriptive prose. Start from the declared primitive, bind extracted content and media to it, and expose the QA markers below.

Required markers

Every core scene:

<section data-rp-scene="home-home-section-002" data-rp-initialized="active-card-rail">...</section>

Active-card rail:

<section data-rp-scene="..." data-rp-initial-state="all-collapsed">
<div data-rp-viewport>
  <div data-rp-track>
    <article data-rp-item data-rp-hover-target data-rp-active="true">
      <button data-rp-activate>...</button>
    </article>
  </div>
</div>
</section>

Content switcher:

<button data-rp-item data-rp-activate data-rp-active="true">...</button>
<div data-rp-panel>...</div>

Scroll scene:

<section data-rp-scene="..." data-rp-phase="approach">
  <div data-rp-visual>...</div>
  <div data-rp-content>...</div>
  <div data-rp-curtain="left"></div>
  <div data-rp-curtain="right"></div>
  <div data-rp-panel>...</div>
</section>

Markers are implementation instrumentation. Do not copy source selectors into them.

site-clone.mjs installs framework-source copies and browser-ready public copies. The default and safest startup is the exact contract bootstrap, included once by the page:

<script type="module" src="/site-clone/rp-interactions-bootstrap.mjs"></script>

Do not use an inline raw-browser import of ../lib/rp-interactions.mjs; a browser URL is not resolved from src/. The bootstrap auto-binds complete marker contracts after DOM readiness. data-rp-initialized is runtime evidence, not a marker to hard-code in markup. Source-specific CSS and content still belong in the page/component implementation.

Primitive rules

active-card-rail
  • Render every captured repeated item in source order.

  • Keep a real horizontal track inside a separate scroll viewport; do not substitute a grid.

  • Put overflow-x and scrolling on data-rp-viewport; put width: max-content or the equivalent row sizing on data-rp-track. A max-content track cannot be its own viewport.

  • Use the exact captured initial active indexes. Set data-rp-initial-state="all-collapsed" when source has none; runtime initialization must not auto-open an item.

  • Reproduce the measured separation mechanism: track gap, geometric gap, item margin, divider, inner inset, or flush.

  • Preserve the observed expanded/collapsed width ratio within the contract tolerance.

  • Controls and direct item activation must update the same state.

  • Mark the source hover surface with data-rp-hover-target and reproduce its visual hover treatment with keyboard-equivalent focus styling.

  • Reproduce nested reveal order and approximate settle time from the captured timeline.

content-switcher
  • Use visible controls with one current state.

  • Keep all captured state content in the implementation.

  • Change the visible data-rp-panel content and active marker on activation.

  • Preserve keyboard access and relevant ARIA state.

  • Give controls and panels matching data-rp-state values so bindContentSwitcher can manage state deterministically.

scroll-scene
  • Derive progress from the scene's own scroll range.

  • Preserve entry/approach phases and internal pinned phases in their captured order.

  • Keep data-rp-phase synchronized with the visual state.

  • Expose continuous --rp-entry-progress and --rp-scroll-progress custom properties.

  • Mark only the measured pinned/cropped/scaled visual wrapper with data-rp-visual.

  • Mark independently positioned copy with data-rp-content and keep it outside visual scaling unless source content geometry explicitly scales.

  • Reproduce large sibling reveal layers from sceneLayers, including paired curtains or masks. Mark observed curtains with data-rp-curtain so reveal distance is verified even when the media itself stays full-width.

  • Do not flatten the scene into static columns when source evidence includes pinning.

  • Pass captured phase names/progress thresholds to bindScrollScene; combine it with bindContentSwitcher when tabs share the same scene.

sticky-header and media-scene
  • Preserve the captured trigger threshold and material chrome changes.

  • Keep source-backed media interactive with the recorded URL and playback flags.

  • Treat a poster or background with fallbackPolicy: "fallback-only" as mutually exclusive with a successfully loaded video/iframe. Do not leave it as a visible layer behind media.

Runtime QA

Start the clone locally, then run:

node scripts/verify-interactions.mjs \
  --out projects/<project-name> \
  --clone-url http://127.0.0.1:4321 \
  --project-root <project-root>

The command writes docs/site-clone/interaction-qa.json and exits non-zero if a core scene is absent, lacks its runtime initialization token, or violates its assertions. Fix failures before final visual polish.

Requirements and compatibility

Works with: Claude Code, Claude apps, OpenAI Codex, GitHub Copilot, Cursor, Gemini CLI, Kiro, OpenCode, Goose, Amp, Roo Code, JetBrains Junie, Factory Droid, Devin (ex-Windsurf), Mistral Vibe, OpenHands, Letta

“Works with” means the tool reads the open Agent Skills format; a skill written for one tool may use features others lack.

Needs: Needs Node.js

Security

What our scanner noticed· Low risk

  • Scripts that your agent may run

This skill includes scripts that your agent may run. Read them before you use it.

A static scan is not a guarantee. Skills are third-party content: review a skill before you let an agent use it.

Attribution and licence

Published by
Wix
Publisher
Wix (Official)
Source
wix/skills · wix-headless-replatform · commit d168bc2
Licence
MIT License (redistribution allowed)
  • LICENSE (added by AutoGineer from LICENSE)
  • ATTRIBUTION.md (written by AutoGineer)
Synced

AutoGineer is not affiliated with or endorsed by Wix.

Download ZIP

The ZIP holds the skill’s files, its licence files and an ATTRIBUTION.md. Download wix-headless-replatform.zip