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

The wix-headless-replatform skill acts as a central supervisor for migrating or cloning a public website's home page into a Wix Headless environment. It enforces a structured, multi-stage process that includes browser-based extraction, build planning, implementation, and visual verification. The skill ensures visual fidelity, SEO preservation, and structural integrity by utilizing a frozen manifest approach, where every stage produces durable artifacts that inform the next. It supports both standalone cloning and integrated migration modes, with specific protocols for handling gaps and ensuring the final output is a functional Wix CLI project.

What it does

  • Clones or migrates a public website home page to a Wix Headless frontend.
  • Manages the end-to-end workflow through distinct stages: context, evidence, implementation, and verification.
  • Uses browser-backed extraction to capture visual and structural data.
  • Enforces strict visual fidelity and SEO preservation standards.
  • Supports one-click automation for migration handoffs.
  • Generates a final report and terminal receipt for migration completion.

When to use it

  • When you need to clone a public website home page into a new Wix Headless project.
  • When performing a migration of an existing site to a Wix Headless architecture.
  • When you require a structured, verifiable process for rebuilding a frontend with high visual fidelity.
  • When working within a migration handoff that provides specific project and data-binding intent.

Advantages

  • Ensures consistent results through a rigid, stage-based supervisor protocol.
  • Maintains high visual and functional fidelity to the source website.
  • Provides a clear path for recovery and gap resolution during the build process.
  • Automates the transition from extraction to a runnable Wix CLI scaffold.

Usage examples

“Clone the home page of a website into a new Wix Headless project.”
The agent initiates the standalone clone workflow, resolving the source URL and proceeding through the context and evidence stages to create a new Wix CLI project.
“Migrate this website using the provided handoff file.”
The agent enters migration mode, reads the handoff configuration, and continues the build process within the existing migration-owned project structure.

Install

  1. Download the skill as a ZIP:

    https://autogineer.com/agent-skills/wix/wix-headless-replatform-p46x/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.

In migration mode the build must also leave the final route manifest that old-link preservation consumes (output-contract.md, "Migration terminal receipt"). A built site is not proof that old URLs work; redirect application and public verification stay pending until the cutover step runs them.

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/qa-checklist.md

Home-page QA checklist

Run QA after manifest-derived implementation. A build is not acceptance.

Frozen boundary

  • extraction/latest.json matches the frozen manifest hash.

  • Every spec and dependency hash verifies before QA.

  • Every typed replay packet/reference hash verifies; a changed packet rejects replay.

  • Every build-plan unit has a matching implementation-ledger entry and spec hash.

  • qa/visual-qa.json contains one unitAcceptance record per planned unit and every required frozen criterion is verified, pending, failed, or explicitly gap-backed.

  • Accepted units contain every classification-required field; every provisional omission is represented by an owned local gap.

  • No builder/QA code rediscovered a source fact or read observations to fill a spec gap.

Unit fidelity

For foundation, metadata, shared chrome, each recursive component, and every section:

  • Run the spec's content/order, asset, layer, layout, responsive, behavior, accessibility, and visual/geometry acceptance checks at every required viewport.

  • Preserve exact visible copy, menu/footer hierarchy, links, logos/media/font tuples, background/media role, positioned layers, and important text geometry.

  • Preserve observed control states, keyboard semantics, initial state, interaction end states, reduced motion, and runtime initialization markers.

  • Keep each finding on its smallest owning unit. Do not compensate through unrelated global CSS or another section.

  • Mark status verified only from rendered/browser evidence. Keep gap-backed work provisional; human acceptance is user-accepted, not verified.

Page fidelity

  • The home route builds and serves in the actual Wix Headless Astro project.

  • Foundation/global CSS is installed once and shared chrome remains a first-class unit.

  • Section order, full-page rhythm, desktop/tablet/mobile reflow, first viewport, and page-level behavior match the frozen page contract.

  • SEO metadata is applied without leaking metadata-only text into visible hero content.

  • Consent infrastructure marked ignored is not cloned as content.

  • No placeholder, clone-process, migration, or development copy appears.

  • External links remain absolute and preserved internal links behave honestly.

Registry

  • build/component-selection.json names the frozen manifest.

  • Every selected item is a pinned local registry revision with a valid human approval, license record, runtime class, source hash, capability-manifest hash, agent-contract hash, and quality evidence.

  • The resolved binding uses only manifest-declared axes/values, slots, states, and compositions; unsupported requirements have deterministic rejection evidence.

  • The builder read only component-selection.json and the selected item's contract.md; candidate reviews/provenance and registry internals were not added to agent context.

  • Astro/static versus React-island use is deliberate; interactive islands declare hydration and accessible no-JavaScript behavior.

  • Items pass accessibility, keyboard, focus, responsive, SSR, RTL, reduced-motion, dependency, styling-isolation, and state/variant checks.

  • When no item qualifies, rejection evidence exists and the bounded custom path is used.

  • build/registry-installation.json proves each selected local file hash and exact dependency/capability binding; qa/registry-opportunities.json records reusable custom gaps.

Browser comparison and recovery

  • Run interaction verification and post-build-gap.mjs against the running home page.

  • Open every desktop/tablet/mobile screenshot pair at original size and write one complete visual-review.json record per pair.

  • Fix missing structure/content/media first, then composition/geometry, core behavior, and supporting polish.

  • For prior critical/high findings, visual-progress.json links canonical source, before-result, and after-result screenshots and proves visible improvement.

  • A local evidence gap uses at most two distinct targeted recovery attempts. Repeating a tactic without new evidence is no progress. After exhaustion, preserve the unit provisionally and continue unrelated QA.

  • Only unresolved home identity, unusable page-wide capture, corrupt integrity, unisolatable safety failure, or inability to assemble/build/serve any shell is blocked.

Final report

  • final-report.json and .md name every unresolved/user-accepted gap, visible location, unavailable fact and reason, evidence/confidence/attempts, provisional implementation, assumptions/omissions, affected checks/dependencies, and user choices.

  • No gaps plus reviewed passing browser evidence may become done.

  • Remaining local gaps become done_with_gaps.

  • Only a global blocker becomes blocked.

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 · 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 or Wix.

Download ZIP

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