AutoGineer summary
Written by AutoGineer from the skill’s own files, not by the author
The rp-destination skill manages the lifecycle of a migration destination site, ensuring a deterministic setup process. It prioritizes existing site configurations or receipts before creating new Headless, Wix Studio, or Wix Harmony sites. The skill coordinates with the Wix CLI to provision sites, verify editor status, and ensure sites remain unpublished until cutover. It handles complex state management, including recovery requests for account confirmation, site type selection, and editor verification, while maintaining strict idempotency to prevent accidental site deletion or unauthorized publication.
What it does
- Resolves or creates a destination site (Headless, Wix Studio, or Wix Harmony) for migrations.
- Ensures deterministic site creation using the Wix CLI and internal coordination scripts.
- Manages site-scoped credentials and persists site IDs in project configurations.
- Verifies editor status and publication state to ensure readiness for import.
- Patches project configuration files for Headless sites to support remote development environments.
- Handles recovery workflows for account mismatches, site limits, or creation failures.
When to use it
- When a migration project requires a verified destination site on the Wix platform.
- When you need to adopt an existing site or provision a new one for a migration.
- When you need to ensure a site is correctly configured and unpublished before starting data import.
- When you need to resolve ambiguous site creation states or handle recovery requests during a migration.
Advantages
- Prevents duplicate site creation through strict receipt and lock management.
- Ensures consistent environment configuration for Headless projects.
- Provides clear, actionable recovery paths for common migration blockers.
- Maintains site security by enforcing account-specific credential binding.
Usage examples
- “Ensure the destination site is ready for the current migration project.”
- The agent runs the coordinator to check for an existing site ID or triggers the creation flow if none exists, reporting the dashboard URL upon completion.
- “I need to set up a new Headless site for this migration.”
- The agent initiates the Headless scaffolding process, confirms the Wix CLI account, and records the new metasite ID in the project receipt.
Install
Download the skill as a ZIP:
https://mp-staging.autogineer.com/agent-skills/wix/rp-destination-fnu5/downloadUnzip it into the cross-client skills folder of your project:
mkdir -p .agents/skills && unzip rp-destination.zip -d .agents/skills
Documentation by Wix
rp-destination
Use only when no authoritative destination is available or the destination contract conflicts.
Precedence is the creation receipt orchestration/destination.json, then a non-empty
config/wix.env site id (an existing or legacy destination: adopt it, never ask for a type),
then one new site of the operator's explicitly chosen type. A conflict is a hard stop;
never retarget on a guess.
New site: run the coordinator
For a new site, run the deterministic coordinator; do not compose creation requests yourself:
node <skill>/scripts/wix-destination.js ensure --project-dir <projectDir>It prints a JSON outcome and never prints credentials:
awaiting_site_type— notargetSiteTypeis recorded. It raised the one required site-type request (headless,studio,harmony_store,harmony_bookings,harmony_other, orharmony= "not sure, start blank"). In chat, ask that combined question once; in one-click, group it with the other missing intake; inreplatformruns, end the turn — the request is the question. Record a chat answer withorchestration-state.js decide --key targetSiteType --value <type> [--business-type store|bookings|other]; a Harmony answer without a business type recordsunknown. Never ask a separate business-type question, never answer for the operator, and never turn a generic "Editor" answer into Studio or Harmony. There is no default type, including in one-click and backend-only runs.awaiting_editor_website_decision—management_and_websitewith Studio/Harmony: the request explains that RePlatform has no automatic Editor website migration. The operator chooses backend only (scope becomesmanagement) or a separate Editor website handoff.awaiting_account_confirmation— before the first Studio/Harmony create, the request names the account the Wix CLI is logged into and the site name. Relay it; never answer it for the operator.confirm_accountbinds that account;switched_accountshows the account again after a login change. A login that differs from the confirmed account is never used for a create.After the coordinator runs, the run's telemetry picks up the confirmed Wix CLI login automatically (the coordinator does it). If you confirm the login by other means first, run
node resources/rp-telemetry/scripts/rp-telemetry.js identityin the project; it is silent and harmless when there is nothing to adopt.verified/created/existing_destination— report the dashboard URL (and, for an Editor site, the verified editor URL) and return to the router.failed_before_create,ambiguous,awaiting_recovery,blocked— a durable recovery request is pending (named byrecoveryRequestId). Relay it; never retry around it.
When the run context already establishes the business type for a Harmony site, write it
before running the coordinator so the request collapses Harmony to one choice:
orchestration/destination-brief.json with businessType (store, bookings, other) and
businessTypeEvidenceRef (where the evidence came from). The type is context for the run; it
does not change how the site is created. Never invent details.
What the coordinator does:
Holds
orchestration/destination.lock, rechecks the receipt andconfig/wix.env, and writes an attempt marker before any create. Studio and Harmony use their blank templates throughPOST /msm/v1/meta-site/create-from-templatewith the Wix CLI account login. Harmony's AI site generation runs on a private Wix service with no stability promise, so it is not used for any business type. Headless delegates once towix-headless-scaffold.js(below).Saves the returned metasite id in the receipt, checks that the response's owner is the confirmed login, then writes
WIX_SITE_IDtoconfig/wix.env(never over a different value), mints a site-scoped Wix CLI credential, and verifies the editor (WIX_STUDIO/ODEDITOR) and that the site is unpublished (published-URLs readback). Only a freshunpublishedreadback lets import continue: every rerun on averifiedsite repeats the readback, and the router sends setup/import back here (destination_publication_recheck) when the last readback is more than 10 minutes old.A Headless receipt is resumed, never re-delegated: a confirmed site is adopted, and any
WIX_SCAFFOLD_STATUSmarker stays the wrapper's recovery. After creation and on every rerun, a confirmed Headless site gets the same editor (EDITORLESS) and published-URLs readback, recorded in the receipt. The published-URLs list names the free URL even for an unpublished Headless site, so the public URL decides: 2xx published, 404 unpublished, anything else unknown. For Headless the readback is evidence only: it never blocks, never raises a recovery request, and the status stayscreated.Never repeats a create whose outcome is unknown, never publishes, unpublishes or deletes a site, and never falls back to another editor or to Headless.
Recovery requests and what each answer does (each answer triggers one bounded step):
| Request | Choice | Effect |
|---|---|---|
| Pre-create rejection (access, site limit, template, name) | retry_create | one new creation attempt after the prerequisite is fixed |
| Uncertain creation (Requires Import Operator) | text: the metasite id, or none-created: <evidence> | adopt and verify that site, or one new attempt only with recorded evidence that nothing was created |
| Response owner missing or not the confirmed login (Requires Import Operator) | text: owner-verified: <evidence> | editor and publication verification of the kept site; any other reply asks again |
| Editor not verified | recheck | one new editor + publication readback; no create |
Publication unknown | recheck | one new readback; the answer itself proves nothing |
Publication published | recheck_after_unpublish | one new readback after a person unpublished the site in Wix |
Import Operator prompt for an uncertain creation, editor mismatch or a
published/unknown readback: "In the original migration workspace, reconcile the
destination creation attempt against the intended account, preserve the returned metasite ID,
rerun editor verification and the published-URLs
readback, and resume only after recording the resolved receipt. Do not create a replacement
site, and do not publish or unpublish it without an explicit human publication decision."
An Editor site is not a website build: never scaffold Headless frontend files for it, and
never hand it to wix-headless-replatform. Its website and publication stay outstanding for
the site owner/designer and the Cutover Operator (completion-report operatorActions).
Headless
For Headless creation, the coordinator runs the wrapper once; the wrapper confirms the Wix
CLI is logged into the intended account, scaffolds inside the active migration project, and
persists the metasite id. Always scaffold with
--site-template blank, whatever the delivery mode or whether the migration carries a
catalog — Catalog V3 is guaranteed at provisioning regardless of template, so there is no longer a reason to start
from a non-blank template. Let wix-headless-replatform supply the actual page content;
do not skip this module just because there is no backend work. Do not create probe, test,
replacement, or second sites without the explicit recovery authority in the existing
destination contract.
Scaffolding (wix-headless-scaffold.js) passes --no-publish: a new Headless site stays
unpublished until cutover, like an Editor site. RePlatform never publishes it. While the last readback is not
published and no website release is recorded, the completion report carries
headless_site_publication_outstanding for the Cutover Operator (or the Import Operator
when the state could not be read). A wix release publishes the site; the next readback
records that and clears the item.
The script also patches the generated astro.config.mjs/package.json right after a
destination is confirmed, once, so a website-mode project's local dev server works
without manual fixes, on any client running it from a Wix Remote Machine: a Vite
allowedHosts wildcard + host: true (the remote machine's dynamic preview hostname and
its 127.0.0.1-only default otherwise break a local preview with a host-block or a 504),
and predev/prebuild/prerelease hooks that re-run wix env pull (the frontend's
.env.local — WIX_CLIENT_ID and friends — is gitignored and is wiped whenever the
remote machine restarts, so it must be re-derived, not assumed to persist). The Vite patch
is conservative: it skips (logging why) rather than touch a config shape it doesn't
recognize, so a template that already sets these deliberately wins. The hooks patch instead
composes wix env pull in front of whatever a hook already runs — idempotently, never
duplicated on a re-run — since an existing hook is almost always doing something unrelated
(e.g. codegen) and skipping it outright would silently leave that project without a working
preview.
After resolution, report the deterministic dashboard URL and return to the router. Source credentials are never requested until this destination exists.
Output
config/wix.env's WIX_SITE_ID persisted, orchestration/destination.json for a new site
(choice, creation method, attempt, metasite id, verified editor and publication readback),
and the reported dashboard URL — or a durable request in orchestration/user-actions/ that
names what is missing. This is what a dispatched run must produce.
Files
- ATTRIBUTION.mdAdded by AutoGineer840 B
- LICENSELicence file added by AutoGineer1.0 KiB
- SKILL.md9.6 KiB
ATTRIBUTION.md
Attribution
This folder is an unmodified copy of the Agent Skill "rp-destination", distributed by AutoGineer (https://autogineer.com/agent-skills).
Commit: d168bc2ca76c1641b3273334542e479291c2b23d
Published by: Wix (https://github.com/wix)
Publisher: Wix (https://github.com/wix)
Licence: MIT License (https://github.com/wix/skills/blob/d168bc2ca76c1641b3273334542e479291c2b23d/LICENSE)
Licence evidence: repository licence LICENSE
Retrieved: 2026-11-07
The skill's own files are unmodified copies. AutoGineer is not affiliated with or endorsed by the author or the publisher.
Files added by AutoGineer
ATTRIBUTION.md: this file, written by AutoGineer
LICENSE: copied from LICENSE
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
No issues found by our static scan· No issues found
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-replatform/resources/rp-destination · 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 rp-destination.zip