@wix/agent-skills 1.16.0 → 1.16.1

package/skills/wix-manage/references/sites/site-import.md

@@ -1,6 +1,6 @@
 ---
 name: "Site Import"
-description: Drive the Wix Site Import agent to migrate an existing store or site from another platform (Shopify, WooCommerce, Magento, or any URL) into Wix. Use this skill whenever the user wants to import, migrate, or clone a store/site into Wix, mentions moving off Shopify/WooCommerce/Magento, or gives a source store URL and asks to bring it into Wix. Covers starting the import, polling progress, answering the agent's mid-import questions, handling deploy/failure/auth-expiry states, and sending post-deploy follow-up changes.
+description: Drive the Wix Site Import agent to migrate an existing store or site from another platform (Shopify, WooCommerce, Magento, or any URL) into Wix, or to import from CSV/TSV export files with no source site. Use this skill whenever the user wants to import, migrate, or clone a store/site into Wix, mentions moving off Shopify/WooCommerce/Magento, or gives a source store URL and asks to bring it into Wix. Covers starting the import, polling progress, answering the agent's mid-import questions, handling deploy/failure/auth-expiry states, and sending post-deploy follow-up changes.
 ---
 
 # Site Import
@@ -54,7 +54,20 @@ Example — Start:
 
 ```
 POST https://www.wixapis.com/site-import/v1/imports
-Body: { "request": "Import https://example-store.com into a new Wix site" }
+Body: {
+  "request": "Import https://example-store.com into a new Wix site",
+  "source_url": "https://example-store.com"
+}
+```
+
+Example — Start from exported files (no source site, FILE run):
+
+```
+POST https://www.wixapis.com/site-import/v1/imports
+Body: {
+  "request": "Import these product export files into a new Wix site",
+  "fileUrls": ["https://example.com/exports/products.csv"]
+}
 ```
 
 Example — Poll:
@@ -96,7 +109,8 @@ and act only on the user's explicit yes.
 
 This creates real infrastructure and writes to the user's Wix account. Before
 calling **Start**, confirm:
-- The source URL and platform are correct
+- The source URL and platform are correct — or, for a file-only import, the
+  export file URL(s) are correct
 - The user understands it runs for up to ~60 minutes and may ask questions mid-way
 
 Also confirm before calling **Cancel** — it's irreversible.
@@ -107,7 +121,7 @@ You are the user experience; the API is plumbing. Keep the protocol invisible:
 
 - **Show the `importId` once, right after Start succeeds** — e.g. "Your import
   ID is `abc123` — keep it handy." Never show raw JSON, HTTP codes, artifact
-  ids, or `sourcePlatform`/`sourceConfidence` values.
+  ids, or `sourcePlatform`/`sourceConfidence`/`destinationSiteId` values.
 - **Write for a non-technical audience.** No jargon: no "endpoint", "API",
   "poll", "HTTP", "rate limit", "JSON". Translate events into plain outcomes —
   "the source store limits how fast it can be read" not "hit rate limit (429)".
@@ -148,12 +162,37 @@ You are the user experience; the API is plumbing. Keep the protocol invisible:
 **Single `importId` for the whole import — assigned at Start, never changes.**
 
 1. **Start** — `POST /v1/imports`
-   Body: `{"request": "<natural language; MUST include the source store URL>"}`
-   Returns: `importId`, `sourcePlatform`, `sourceConfidence`.
-   One import per store at a time: if the same user re-starts for the same store,
-   the server returns the existing `importId` (no new import is created). If a
-   different user on the account already owns an import for that store, Start
-   returns `409 { "code": "IMPORT_IN_PROGRESS" }` — tell the user and stop.
+   Body: `{"request": "<natural language; MUST include the source store URL when crawling a live site>", "source_url": "<the source store URL>", "fileUrls": ["<CSV/TSV export URL>", ...]}`
+   `request` is required (1–20000 chars). `source_url` and `fileUrls` are both
+   optional, but send whichever applies — never leave both out with no way to
+   identify what to import:
+   - **`source_url`** — send it whenever the user names a site to crawl. It's
+     the identity the service uses to select which migration the request joins,
+     not just an extra hint.
+   - **`fileUrls`** — send it when the user has CSV/TSV export file(s) to import
+     instead of crawling a live site. Setting it makes this a **FILE run**: no
+     source site is probed and no source credentials are requested, even if
+     `source_url` is also present — `source_url` only changes what the
+     migration is keyed on (see below), it does not add a crawl on top of the
+     file import. Up to 20 URLs, http/https only (ports 80/443), each ≤2048
+     chars. If `source_url` is absent, the file set itself is the migration
+     identity — re-sending the same URLs continues the same migration; a
+     different set starts a new one. If a URL isn't reachable, the whole call
+     is rejected with `INVALID_FILE_URL` (nothing is silently dropped).
+   - A request with neither `source_url` nor a URL/site identifiable in
+     `request`, and no `fileUrls`, is rejected with `SITE_UNIDENTIFIED`.
+   Returns: `importId`, `sourcePlatform`, `sourceConfidence`, `destinationSiteId`.
+   `sourcePlatform` comes back as `CSV` for a FILE run (no site was probed, so
+   `sourceConfidence` is meaningless there). `destinationSiteId` is the id of
+   the Wix site being imported into — returned as soon as Start succeeds,
+   even before a source is confirmed.
+   **One import per store at a time, keyed on `source_url`** (or the file set
+   when there's no `source_url`): re-starting with the same identity continues
+   the SAME migration (server returns the existing `importId`, no new import
+   created). A different identity always starts an independent migration, even
+   for the same user. If a different user on the account already owns an
+   import for that identity, Start returns
+   `409 { "code": "IMPORT_IN_PROGRESS" }` — tell the user and stop.
 
 2. **Poll** — `GET /v1/imports/{importId}?includeRecentActivity=true`
    Returns: `status`, `deployUrl`, `message`, `options[]` (only when
@@ -230,13 +269,26 @@ the user has no way to open a file.
 - Never invent a `deployUrl` — only report the one returned with `DEPLOYED`.
 - Treat `NEEDS_INPUT` and `AUTH_EXPIRED` as normal conversation turns, not
   errors.
-- **Site Import is in limited rollout.** If Start returns `404` or `403` with
-  `"code": "NOT_ENABLED"`, tell the user plainly that site import isn't
-  supported on their account yet and they can contact Wix support — then stop.
-  Do not retry or fall back to another site-creation tool.
+- **Site Import is in limited rollout, with no self-service enablement path.**
+  If Start returns `404` or `403` with `"code": "NOT_ENABLED"`, tell the user
+  plainly that site import isn't available on their account yet — then stop.
+  **Do not tell them to "contact Wix support"**: this API is unlisted and
+  ALPHA, Wix Support has no visibility into it or way to grant access, and the
+  public "importing a site created outside of Wix" help-center article is an
+  unrelated, long-stalled feature-request page — sending a user to either is a
+  dead end. If a Wix feedback tool is available in your environment, you may
+  offer to send feedback noting their interest; that is the only channel that
+  reaches the team. Do not retry or fall back to another site-creation tool.
 - Any other `403` on Start means the caller is not authorized — tell the user
   and stop. Do not probe other endpoints to diagnose this. A `400` means a
-  required field is missing (`request`/`message` must be 1–20000 chars).
+  required field is missing (`request`/`message` must be 1–20000 chars),
+  `source_url` exceeds 2048 chars, or `fileUrls` has more than 20 entries or
+  one over 2048 chars. A request with no identifiable site (no `source_url`
+  and no URL in `request`) and no `fileUrls` is rejected with
+  `SITE_UNIDENTIFIED` — ask the user for the store URL or export file(s) and
+  retry. A `fileUrls` entry that isn't a reachable http/https URL rejects the
+  whole call with `INVALID_FILE_URL` — tell the user which link failed and ask
+  for a working one.
 - Requesting an unknown id in `artifactIds` is silently ignored — not an error.
   A document simply may not exist yet on an earlier turn.
 - **The user cannot open files.** If a message mentions a document by filename,

package/skills/wix-replatform/resources/rp-target-wix/lib/wix-writers.js

@@ -324,7 +324,7 @@ function applySafeModeToRequestBody(body, safeModeOptions) {
 // media import, Contacts manage/schema, and Members manage.
 //
 // Auth scheme normalization: Wix API keys (`IST.…`) are sent RAW in the Authorization
-// header; OAuth access tokens (e.g. a Wix CLI token from `npx @wix/cli token --site …`)
+// header; OAuth access tokens (e.g. a Wix CLI token from `npx @wix/cli@latest token --site …`)
 // must be sent as `Bearer <token>`. Detect and prefix so both credential kinds work.
 function authHeaderValue(token) {
   const t = String(token).trim();

package/skills/wix-vibe-headless/SKILL.md

@@ -149,7 +149,8 @@ installed, not what the business is about. Never default to store/bookings on si
    `INSTRUCTIONS.md`.
 3. **Ensure the vertical's files are in place** — copy `references/<vertical>/app/` and
    `references/shared/app/` into the app's `src/`, and set `WIX_CLIENT_ID` in `wix-config.js`. (Where
-   and how they get there is your platform's call — see its instructions.)
+   and how they get there is your platform's call — see its instructions. On base44 the install step
+   writes and verifies `wix-config.js` for you, so there's nothing to set by hand.)
 4. **Wire the shipped client** following the vertical's INSTRUCTIONS: the components are themed by
    base44's design tokens (`src/index.css` — shadcn palette, already set by the design phase), so
    there's no re-skin step; just wire routes + header/footer through the Layout. The UI ships as

package/skills/wix-vibe-headless/install/deploy.cjs

@@ -1,6 +1,8 @@
 // Post-install deploy — run by base44.md STEP 1 with the vertical(s) the app needs:
-//   node deploy.cjs <vertical> [<vertical> …]
+//   node deploy.cjs <vertical> [<vertical> …] --client-id <id> --metasite-id <id>
 //   (storefront | bookings | blog | cms | portfolio | pricing-plans | events | members)
+// Pass the two ids from the prompt and this writes src/rest/wix-config.js for you — see WRITE below.
+// Retyping those ids into the file by hand is how a storefront ships with a dead client id.
 // ONE mechanism: recursively copy `app/` -> /app/src. The shared transport (app/rest/wix-client.js,
 // wix-config.js) is copied always; then each named vertical's app/ (its UI + app/rest/ helpers).
 // Deploy every vertical the app actually uses, in one call or across several — an app that needs both
@@ -13,9 +15,10 @@
 // No vertical arg -> deploys just the shared transport; re-run with the vertical(s) once known.
 // NOTE: .cjs on purpose — the app is an ESM package ("type":"module"); a .js here would load as ESM
 // and require()/module.exports would throw.
-const { existsSync, cpSync, readFileSync } = require('fs');
+const { existsSync, cpSync, readFileSync, writeFileSync } = require('fs');
 
 const REF = '/app/.agents/skills/wix-vibe-headless/references';
+const WIX_CONFIG = '/app/src/rest/wix-config.js';
 const VERTICALS = ['storefront', 'bookings', 'blog', 'cms', 'portfolio', 'pricing-plans', 'events', 'members', 'restaurants'];
 
 // force:false + errorOnExist:false — fill in only files that AREN'T there yet; never overwrite.
@@ -66,11 +69,55 @@ function replaceMembersAuthLeftovers() {
   return result;
 }
 
+// --- WRITE the credentials ----------------------------------------------------------------------
+//
+// The two ids arrive as flags so this script writes them once, character-for-character, instead of a
+// later hand-edit of the placeholder file.
+//
+// An id already in the file wins; the flags only fill what is unset. A host that writes this file
+// at app creation (Base44) has each id as an exact value rather than a copy read out of a prompt.
+// Per id, so a host that resolved one but not the other still gets the gap filled.
+//
+// This briefly worked the other way round for WIX_METASITE_ID, while Base44 could write a different
+// site than the business: it shared one field between the launch and a metasite it provisions per
+// app, and the launch's id lost. Fixed on that side, and the ids it stores now verify against the
+// site each launch came from, so the file is trusted again.
+function readWixConfig() {
+  if (!existsSync(WIX_CONFIG)) return {};
+  const src = readFileSync(WIX_CONFIG, 'utf8');
+  const pick = (name) => {
+    const v = (src.match(new RegExp(`${name}\\s*=\\s*["']([^"']*)["']`)) || [])[1] || '';
+    return v.startsWith('<') ? '' : v;   // the shipped file's `<YOUR-…>` placeholders count as unset
+  };
+  return { clientId: pick('WIX_CLIENT_ID'), metaSiteId: pick('WIX_METASITE_ID') };
+}
+
+function writeWixConfig(clientId, metaSiteId) {
+  const body = [
+    '// Wix credentials — written by the skill\'s deploy step from the ids in your prompt.',
+    '// Safe to commit: WIX_CLIENT_ID is a public, buyer-facing id (it only mints anonymous visitor',
+    '// tokens); WIX_METASITE_ID just identifies the site.',
+    `export const WIX_CLIENT_ID = "${clientId}";`,
+    `export const WIX_METASITE_ID = "${metaSiteId}";`,
+    '',
+  ].join('\n');
+  writeFileSync(WIX_CONFIG, body);
+}
+
 // --- main ---------------------------------------------------------------------------------------
 
 // Accept one or many: `deploy.cjs members cms`. Duplicates collapse; order is preserved so the
 // first vertical listed wins any same-path file (the copy never overwrites).
-const requested = [...new Set(process.argv.slice(2))];
+const argv = process.argv.slice(2);
+const flag = (name) => {
+  const i = argv.indexOf(`--${name}`);
+  return i !== -1 && argv[i + 1] && !argv[i + 1].startsWith('--') ? argv[i + 1] : null;
+};
+const clientId = flag('client-id');
+const metaSiteId = flag('metasite-id');
+// Verticals are the positional args — drop the flags and their values.
+const flagArgs = new Set(['--client-id', '--metasite-id', clientId, metaSiteId].filter(Boolean));
+const requested = [...new Set(argv.filter((a) => !flagArgs.has(a)))];
 const deployed = { verticals: [] };
 
 // Shared transport — always (app/rest/wix-client.js, wix-config.js -> src/rest/).
@@ -92,4 +139,18 @@ if (!requested.length) {
   deployed.note = 'no vertical given — deployed the shared transport only; re-run: node deploy.cjs <vertical> [<vertical> …]';
 }
 
+const onDisk = readWixConfig();
+const finalClientId = onDisk.clientId || clientId;
+const finalMetaSiteId = onDisk.metaSiteId || metaSiteId;
+
+if (!finalClientId || !finalMetaSiteId) {
+  deployed.wixConfig = 'missing_ids — src/rest/wix-config.js is not configured; re-run with '
+    + '--client-id and --metasite-id rather than editing the file by hand';
+} else if (finalClientId === onDisk.clientId && finalMetaSiteId === onDisk.metaSiteId) {
+  deployed.wixConfig = 'already_set';
+} else {
+  writeWixConfig(finalClientId, finalMetaSiteId);
+  deployed.wixConfig = 'written';
+}
+
 console.log(JSON.stringify(deployed));

package/skills/wix-vibe-headless/platforms/base44.md

@@ -18,10 +18,7 @@ Install two skills — they land under `.agents/skills/`:
 - **`wix-docs`** — a **fallback**: search + read the Wix API docs for anything `wix-vibe-headless`
   doesn't cover.
 
-Install via the skills CLI — run this through exec_tool, exactly as written. It installs the two
-skills, then runs `deploy.cjs <vertical…>` (lays the shared transport + **each** listed vertical's
-REST scaffolds and UI client into `src/`) and `pin-agents-md.cjs` (pins the project's AGENTS.md
-note so later turns keep the rules).
+Run this through exec_tool, exactly as written — installs both skills, deploys REST scaffolds + UI into `src/`, writes `wix-config.js`, and pins the AGENTS.md note.
 
 **Set `VERTICALS`** to what the prompt asks for (too vague to tell? do STEP 2 first, then set it):
 
@@ -37,19 +34,20 @@ note so later turns keep the rules).
 | `members` | let visitors sign in — this is **auth** |
 | `cms` | keep its own structured content — user submissions, galleries, listings, anything the rows above don't already cover |
 
-**List every vertical the app actually uses** — one is the common case, and name more when the intent
-spans them, so all their scaffolds come from the skill rather than being written by hand. Anything the
-app stores itself needs `cms`, and anything where visitors sign in needs `members`, so those two often
-join whichever vertical is the main one. Adding one later is fine too: re-run with the extra name (the
-copy only fills in missing files).
+**List every vertical the app uses.** `cms` for app-stored content, `members` for visitor sign-in — these often join the main vertical. Adding one later: re-run with the extra name.
 
 ```js
 const { execSync } = require('child_process');
-const { readdirSync } = require('fs');
+const { existsSync, readdirSync } = require('fs');
 const VERTICALS = ['storefront'];        // ← set from the prompt; list every vertical the app uses
 // const VERTICALS = ['members', 'cms']; // ← e.g. visitors sign in AND the app stores what they submit
+// COPY these two straight from the prompt — deploy writes them into src/rest/wix-config.js, so never
+// retype either one into a file by hand afterwards.
+const WIX_CLIENT_ID = '<client id from the prompt>';
+const WIX_METASITE_ID = '<site id from the prompt>';
 const results = {};
 for (const skill of ['wix-vibe-headless', 'wix-docs']) {
+  if (existsSync(`/app/.agents/skills/${skill}/SKILL.md`)) { results[skill] = 'already_installed'; continue; }
   try {
     const out = execSync(`CI=1 npx -y skills add wix/skills/skills/${skill} --yes 2>&1`,
       { cwd: '/app', timeout: 60000, shell: '/bin/bash' }).toString().replace(/\x1b\[[0-9;]*m/g, '');
@@ -57,18 +55,12 @@ for (const skill of ['wix-vibe-headless', 'wix-docs']) {
       : out.includes('No valid skills') ? 'not_found' : 'unknown';
   } catch (e) { results[skill] = 'error: ' + e.message; }
 }
-// Deploy the shared transport + each listed vertical's scaffolds/UI into src/.
-const deploy = execSync(`node /app/.agents/skills/wix-vibe-headless/install/deploy.cjs ${VERTICALS.join(' ')}`, { cwd: '/app' }).toString();
-// Pin the project's AGENTS.md note (idempotent) so the rules survive after this doc leaves context.
+const deploy = execSync(`node /app/.agents/skills/wix-vibe-headless/install/deploy.cjs ${VERTICALS.join(' ')} --client-id ${WIX_CLIENT_ID} --metasite-id ${WIX_METASITE_ID}`, { cwd: '/app' }).toString();
 const agentsMd = execSync(`node /app/.agents/skills/wix-vibe-headless/install/pin-agents-md.cjs`, { cwd: '/app' }).toString();
 return { results, installed: readdirSync('/app/.agents/skills'), deploy: JSON.parse(deploy), agentsMd: JSON.parse(agentsMd) };
 ```
 
-Read the skills with **`read_file`** (rooted at `/app` → workspace-relative path, e.g.
-`.agents/skills/wix-vibe-headless/SKILL.md`; absolute `/app/...` fails — exec_tool/shell wants
-absolute). Prefer it over `cat`/exec_tool and web-fetch, which cap output (~5000 chars) and
-truncate. Always read from **`.agents/skills/` exactly**, on later turns too — don't guess; ignore
-stray copies like `agent/skills/`.
+Read skills with **`read_file`** using workspace-relative paths (e.g. `.agents/skills/wix-vibe-headless/SKILL.md`) — absolute `/app/...` fails. Always read from `.agents/skills/` exactly on every turn; ignore stray copies like `agent/skills/`.
 
 ## STEP 2 (optional) — Brief doesn't say what to build? Read the site
 
@@ -96,13 +88,7 @@ fails or shows nothing relevant, ask the user what they offer.
 Read `.agents/skills/wix-vibe-headless/SKILL.md` and follow it **EXACTLY** — the single source of
 truth for how the client is built.
 
-**REST scaffolds are already in `src/rest/`** (STEP 1). Write `src/rest/wix-config.js` with your
-`WIX_CLIENT_ID` and `WIX_METASITE_ID` from the prompt — the one place both ids live (a single write,
-nothing to read). Some
-verticals also ship a **ready UI client** under `src/` (STEP 1 deployed it) — theme + wire it per
-`INSTRUCTIONS.md`, don't rebuild. STEP 1 already deployed these files — **don't `read_file` the
-deployed component/page source to inspect them**; every field shape is in `INSTRUCTIONS.md`. Read a
-deployed file only on a real fallback (an error, or a field the snippets don't cover).
+**REST scaffolds + `wix-config.js` are already in `src/rest/`** (STEP 1 wrote them). Some verticals also ship a ready UI client in `src/` — theme + wire it per `INSTRUCTIONS.md`, don't rebuild. **Don't `read_file` deployed files** — every field shape is in `INSTRUCTIONS.md`; read one only on a real error or gap.
 
 **`src/App.jsx`: edit surgically, never rewrite.** It carries required platform auth scaffolding
 (`AuthProvider`/`useAuth` from `@/lib/AuthContext`); a full rewrite drops them → the validator
@@ -147,11 +133,6 @@ build the client, so the urls are ready by the time you seed.
 The connector + seeding are **admin-only** (STEP 4) — **not** part of the client, which is built
 solely per the `wix-vibe-headless` skill.
 
-## Parallelism
-
-Run STEP 3 and STEP 4 in parallel — building and seeding are independent. Within each, also
-parallelize independent work (API calls, multiple entities).
-
 ## STEP 5 — Wrap up
 
 Once the site is built and seeded:
@@ -163,13 +144,7 @@ Once the site is built and seeded:
    metasite id) to complete setup in Wix (required), and mention that the preview shows a dismissible
    top banner linking to this same dashboard.
 
-**Preview briefly, don't chase images.** A quick render check is enough. Generated images show as
-alt-text/broken in this preview because `generate_image` returns a `/__generating__/…` placeholder —
-the platform swaps every placeholder for the final url **automatically at the end of the turn**
-(failed ones get a stock fallback), in your own components and the seeded data alike. So a broken
-image in the preview is expected and already handled: **do NOT swap, re-seed, re-attach, or debug
-image urls.** Hand-editing a placeholder `src` is wasted work and just risks find_replace errors on
-urls that are about to be replaced anyway. Leave them and finish.
+**Preview briefly, don't chase images.** Broken images are expected — `generate_image` returns a `/__generating__/…` placeholder that the platform swaps for the final url automatically at turn end (failures get a stock fallback). **Do NOT edit, re-seed, or debug image urls.** Leave them and finish.
 
 ## Later admin requests
 

package/skills/wix-vibe-headless/references/blog/INSTRUCTIONS.md

@@ -25,11 +25,11 @@ don't need to open them:**
 | `hooks/usePostDetail.js` | post-detail data — load by slug, not-found state, resolved category/tag chips, body paragraphs |
 | `components/PostCard.jsx`, `PostGrid.jsx` | post listing UI (grid + card, with cover image + empty state) |
 | `components/PostChips.jsx` | category/tag chips for a post (resolves ids via the taxonomy, routes by slug) |
-| `components/WixManageBanner.jsx` | preview-only manage banner — drop it into your Layout (STEP 4) |
+| `components/WixManageBanner.jsx` | preview-only manage banner — drop it into your Layout (STEP 3) |
 | `pages/Blog.jsx` | the feed route (`/blog`) — lists posts, paginates, empty state |
 | `pages/PostDetail.jsx` | the post route (`/blog/:slug`) |
 | `pages/CategoryPage.jsx`, `TagPage.jsx` | the taxonomy landing routes (`/blog/category/:slug`, `/blog/tag/:slug`) |
-| `rest/wix-config.js` | **you set the ids here** (STEP 2) |
+| `rest/wix-config.js` | the two ids, written by the install step |
 | `rest/wix-client.js` + `rest/wix-blog.js` | REST transport + blog helpers (posts/categories/tags) |
 
 They're already in place — go **straight to theming + wiring**, nothing to verify first. **Don't
@@ -39,11 +39,8 @@ real fallback — a runtime error, or a field the snippets don't cover (see "Fal
 end). (Files missing? the install's `deploy` result lists what it wrote; re-run install, or copy
 `references/blog/app/` → `src/`.)
 
-## STEP 2 — Credentials
-Write `src/rest/wix-config.js` with your `WIX_CLIENT_ID` and `WIX_METASITE_ID` from the prompt — the
-one place both ids live.
 
-## STEP 3 — Theme (nothing to style on the shipped components)
+## STEP 2 — Theme (nothing to style on the shipped components)
 The shipped components carry **no palette of their own** — they render from base44's design tokens in
 `src/index.css` (`:root`/`.dark`: `--background`, `--foreground`, `--card`, `--primary`, `--muted`,
 `--border`, `--radius`, `--font-*`) via shadcn Tailwind classes (`bg-card`, `text-foreground`,
@@ -51,10 +48,10 @@ The shipped components carry **no palette of their own** — they render from ba
 are **already set to the brand by the design phase**, so the shipped pages are themed with zero work
 here. To adjust the palette, edit `index.css` (`:root` **and** `.dark`) — the base44 way; **never add
 a parallel theme file (e.g. a `theme.css`) or restyle the shipped JSX.** Build the Home/Header you add
-(STEP 4) from the **same** base44 tokens/classes so it matches automatically. A dark brand is just
+(STEP 3) from the **same** base44 tokens/classes so it matches automatically. A dark brand is just
 base44's dark palette in `index.css` — no per-component work.
 
-## STEP 4 — Wire routes + provider (surgical `find_replace` on `src/App.jsx`, never a rewrite)
+## STEP 3 — Wire routes + provider (surgical `find_replace` on `src/App.jsx`, never a rewrite)
 **No file reads needed to wire this.** Every shipped page and `WixManageBanner` is a default export that takes **no props** — wire them exactly as the snippet shows; nothing in those files needs looking up.
 `App.jsx` carries required platform auth scaffolding (`AuthProvider`/`useAuth`) — edit it in, don't
 replace it.
@@ -120,7 +117,7 @@ function Layout() {
 
 ## What you build (not shipped)
 The **home / landing page**, the **`Header`** and a **`Footer`** — the two you drop into the `Layout`
-(STEP 4) so they wrap every route — plus the overall brand story, styled with the same base44
+(STEP 3) so they wrap every route — plus the overall brand story, styled with the same base44
 tokens/classes. **Compose the shipped pieces** — a "latest posts" strip is just `queryPosts` + the shipped
 `PostGrid`; a category nav is `useTaxonomy()` + links to `/blog/category/:slug`:
 
@@ -212,9 +209,8 @@ Fallback only — when you hit an error or need something not shown here: read t
 under `src/`, or look it up via the **`wix-docs`** skill.
 
 ## Hard rules
-- Set `WIX_CLIENT_ID` (STEP 2) — not the placeholder.
 - Style via base44 design tokens (`index.css` / shadcn Tailwind classes), never by rewriting the shipped components or adding a parallel theme file.
-- Header/footer live in a `Layout` around `<Outlet/>` (STEP 4) — never edit the shipped `Blog`/`PostDetail`/category/tag pages to add chrome.
+- Header/footer live in a `Layout` around `<Outlet/>` (STEP 3) — never edit the shipped `Blog`/`PostDetail`/category/tag pages to add chrome.
 - The Layout's fixed top region owns positioning: `<WixManageBanner/>` above `<Header/>`; your `Header` is plain in-flow markup (not `position:fixed`).
 - Route by `slug` through the shipped helpers — never hand-build a post/category/tag URL. Display categories/tags by `.label` (not `.name`).
 - Render live Wix data or the shipped empty state — never mock posts, authors, comments, likes, or view counts; never use a stock/placeholder cover image.

package/skills/wix-vibe-headless/references/bookings/INSTRUCTIONS.md

@@ -36,9 +36,9 @@ so you don't need to open them:**
 | `components/ServiceCard.jsx`, `ServiceGrid.jsx` | service listing UI (grid + card, with empty state); the card shows price, tagline and a `60 min · 1-to-1` meta row |
 | `components/SlotPicker.jsx` | bookable-slot chips + paging (pure UI, driven by `useServiceDetail`) |
 | `components/BookingForm.jsx` | contact + participant form (pure UI, driven by `useServiceDetail`) |
-| `components/WixManageBanner.jsx` | preview-only manage banner — drop it into your Layout (STEP 4) |
+| `components/WixManageBanner.jsx` | preview-only manage banner — drop it into your Layout (STEP 3) |
 | `pages/Services.jsx`, `pages/ServiceDetail.jsx` | the two shipped routes (`/services`, `/service/:serviceId`); the detail page is two-column — service + a duration/price/where strip on the left, the sticky booking panel on the right |
-| `rest/wix-config.js` | **you set the ids here** (STEP 2) |
+| `rest/wix-config.js` | the two ids, written by the install step |
 | `rest/wix-client.js` | REST transport — mints/persists the anonymous visitor token |
 | `rest/wix-bookings-services.js` | services + availability: `queryServices`, `queryServicesByCategory`, `categoriesOf`, `getService`, `countServices`, `listSlotsForService`, `listAvailableSlots`, `listEventTimeSlots`, `getAvailableSlot`, `mediaUrl` |
 | `rest/wix-bookings-checkout.js` | booking + checkout: `createBooking`, `checkoutBooking`, `bookAndCheckout` |
@@ -50,11 +50,8 @@ on a real fallback — a runtime error, or a field the snippets don't cover (see
 the end). (Files missing? the install's `deploy` result lists what it wrote; re-run install, or copy
 `references/bookings/app/` → `src/`.)
 
-## STEP 2 — Credentials
-Write `src/rest/wix-config.js` with your `WIX_CLIENT_ID` and `WIX_METASITE_ID` from the prompt — the
-one place both ids live.
 
-## STEP 3 — Theme (nothing to style on the shipped components)
+## STEP 2 — Theme (nothing to style on the shipped components)
 The shipped components carry **no palette of their own** — they render from base44's design tokens
 in `src/index.css` (`:root`/`.dark`: `--background`, `--foreground`, `--card`, `--primary`,
 `--muted`, `--border`, `--radius`, `--font-*`) via shadcn Tailwind classes (`bg-card`,
@@ -62,10 +59,10 @@ in `src/index.css` (`:root`/`.dark`: `--background`, `--foreground`, `--card`, `
 `font-display`). Those tokens are **already set to the brand by the design phase**, so the shipped
 pages are themed with zero work here. To adjust the palette, edit `index.css` (`:root` **and**
 `.dark`) — the base44 way; **never add a parallel theme file (e.g. a `theme.css`) or restyle the
-shipped JSX.** Build the Home/Header you add (STEP 4) from the **same** base44 tokens/classes so it
+shipped JSX.** Build the Home/Header you add (STEP 3) from the **same** base44 tokens/classes so it
 matches automatically. A dark brand is just base44's dark palette in `index.css` — no per-component work.
 
-## STEP 4 — Wire routes (surgical `find_replace` on `src/App.jsx`, never a rewrite)
+## STEP 3 — Wire routes (surgical `find_replace` on `src/App.jsx`, never a rewrite)
 **No file reads needed to wire this.** Every shipped page and `WixManageBanner` is a default export that takes **no props** — wire them exactly as the snippet shows; nothing in those files needs looking up.
 `App.jsx` carries required platform auth scaffolding (`AuthProvider`/`useAuth`) — edit it in, don't
 replace it. Bookings needs **no cross-page provider** (there's no cart — each booking completes on
@@ -123,7 +120,7 @@ function Layout() {
 
 ## What you build (not shipped)
 The **home / landing page**, the **`Header`** and a **`Footer`** — the two you drop into the
-`Layout` (STEP 4) so they wrap every route — plus the overall brand story, styled with the same
+`Layout` (STEP 3) so they wrap every route — plus the overall brand story, styled with the same
 base44 tokens/classes. **Compose the shipped pieces** — a "featured services" strip is just
 `queryServices` + the shipped `ServiceGrid`; the nav is a link to `/services`:
 
@@ -227,9 +224,8 @@ the areas they sit in:
 - Headless redirect session (hosted checkout): https://dev.wix.com/docs/api-reference/business-management/headless/redirects.md
 
 ## Hard rules
-- Set `WIX_CLIENT_ID` (STEP 2) — not the placeholder.
 - Style via base44 design tokens (`index.css` / shadcn Tailwind classes), never by rewriting the shipped components or adding a parallel theme file.
-- Header/footer live in a `Layout` around `<Outlet/>` (STEP 4) — never edit the shipped
+- Header/footer live in a `Layout` around `<Outlet/>` (STEP 3) — never edit the shipped
   `Services`/`ServiceDetail` to add chrome.
 - The Layout's fixed top region owns positioning: `<WixManageBanner/>` above `<Header/>`; your
   `Header` is plain in-flow markup (not `position:fixed`).

package/skills/wix-vibe-headless/references/cms/INSTRUCTIONS.md

@@ -13,7 +13,7 @@ using the official Wix Data endpoints — never hand-build a Wix Data URL, never
 | `rest/wix-cms.js` | Wix Data helpers over the official endpoints: `queryDataItems`, `getDataItem`, `getDataItemBy`, `countDataItems`, `insertDataItem`, `updateDataItem`, `removeDataItem`. |
 | `lib/wixImage.js` | `wixImage(uri)` — converts a `wix:image://…` media field into a renderable URL (passes `https://` / `//` through). |
 | `collection.config.js` | Optional one-file mapping: `COLLECTION_ID` (your collection's **name**, not a GUID) + `FIELDS` (map `title`/`image`/`summary`/`body`/`date`/`slug` to your field keys). Keeps field mapping in one place; skip it and pass field keys inline if you prefer. |
-| `wix-config.js` *(shared)* | Set `WIX_CLIENT_ID` + `WIX_METASITE_ID` here (the one place both ids live). |
+| `wix-config.js` *(shared)* | the two ids, written by the install step. |
 | `WixManageBanner` *(shared)* | Dev-only manage banner — mount it in your Layout (see the platform doc's "Done" step). |
 
 ## Prerequisites
@@ -131,7 +131,6 @@ Validate the mime type and the size there as well.
 - Import File: https://dev.wix.com/docs/api-reference/assets/media/media-manager/files/import-file.md
 
 ## Hard rules
-- Set `WIX_CLIENT_ID` (in `wix-config`) — not the placeholder.
 - Read/write **only** through the `wix-cms.js` helpers (official Wix Data endpoints) — never hand-build a URL.
 - `queryDataItems` → `{ items, nextCursor }` (destructure, iterate `.items`); `sort` is `[{ fieldName, order }]`; date comparands wrap as `{ "$date": ISO }`.
 - Read date fields through the wrapper — `new Date(v?.$date ?? v)`. Dates arrive as `{ "$date": ISO }` (including `_createdDate` / `_updatedDate`), and `new Date(object)` puts the text "Invalid Date" on the page. See RETRIEVAL SHAPES in `rest/wix-cms.js` for the field types that need a converter.

package/skills/wix-vibe-headless/references/events/INSTRUCTIONS.md

@@ -32,9 +32,9 @@ don't need to open them:**
 | `components/EventRegistration.jsx` | branches on `registration.type` (RSVP / TICKETING / EXTERNAL / NONE) |
 | `components/RsvpForm.jsx` | RSVP form UI over `useRsvpForm` |
 | `components/TicketPicker.jsx` | ticket list + quantity + checkout UI over `useTicketing` |
-| `components/WixManageBanner.jsx` | preview-only manage banner — drop it into your Layout (STEP 4) |
+| `components/WixManageBanner.jsx` | preview-only manage banner — drop it into your Layout (STEP 3) |
 | `pages/Events.jsx`, `pages/EventDetail.jsx` | the two shipped routes (`/events`, `/events/:slug`) |
-| `rest/wix-config.js` | **you set the ids here** (STEP 2) |
+| `rest/wix-config.js` | the two ids, written by the install step |
 | `rest/wix-client.js` | visitor-token mint/refresh + REST transport (reads `wix-config.js`) |
 | `rest/wix-events-browse.js` | browse/discovery helpers (`queryEvents`, `getEventBySlug`, categories, count) |
 | `rest/wix-events-registration.js` | RSVP + ticketing helpers (`createRsvp`, `reserveTickets`, `getTicketCheckoutUrl`, `checkoutTickets`) |
@@ -46,12 +46,8 @@ real fallback — a runtime error, or a field the snippets don't cover (see "Fal
 end). (Files missing? the install's `deploy` result lists what it wrote; re-run install, or copy
 `references/events/app/` → `src/`.)
 
-## STEP 2 — Credentials
-Write `src/rest/wix-config.js` with your `WIX_CLIENT_ID` and `WIX_METASITE_ID` from the prompt — the
-one place both ids live. The visitor refresh token minted from this id is persisted to localStorage
-and **is** the identity of the visitor's ticket reservation — don't re-mint anonymously per load.
 
-## STEP 3 — Theme (nothing to style on the shipped components)
+## STEP 2 — Theme (nothing to style on the shipped components)
 The shipped components carry **no palette of their own** — they render from base44's design tokens in
 `src/index.css` (`:root`/`.dark`: `--background`, `--foreground`, `--card`, `--primary`, `--muted`,
 `--border`, `--radius`, `--font-*`) via shadcn Tailwind classes (`bg-card`, `text-foreground`,
@@ -59,10 +55,10 @@ The shipped components carry **no palette of their own** — they render from ba
 are **already set to the brand by the design phase**, so the shipped pages are themed with zero work
 here. To adjust the palette, edit `index.css` (`:root` **and** `.dark`) — the base44 way; **never add
 a parallel theme file (e.g. a `theme.css`) or restyle the shipped JSX.** Build the Home/Header you add
-(STEP 4) from the **same** base44 tokens/classes so it matches automatically. A dark brand is just
+(STEP 3) from the **same** base44 tokens/classes so it matches automatically. A dark brand is just
 base44's dark palette in `index.css` — no per-component work.
 
-## STEP 4 — Wire routes + provider (surgical `find_replace` on `src/App.jsx`, never a rewrite)
+## STEP 3 — Wire routes + provider (surgical `find_replace` on `src/App.jsx`, never a rewrite)
 **No file reads needed to wire this.** Every shipped page and `WixManageBanner` is a default export that takes **no props** — wire them exactly as the snippet shows; nothing in those files needs looking up.
 `App.jsx` carries required platform auth scaffolding (`AuthProvider`/`useAuth`) — edit it in, don't
 replace it. (Events needs no cross-page provider — there's no cart; the RSVP/ticketing state is local
@@ -120,7 +116,7 @@ function Layout() {
 
 ## What you build (not shipped)
 The **home / landing page**, the **`Header`** and a **`Footer`** — the two you drop into the `Layout`
-(STEP 4) so they wrap every route — plus the overall brand story, styled with the same base44
+(STEP 3) so they wrap every route — plus the overall brand story, styled with the same base44
 tokens/classes. **Compose the shipped pieces** — a "featured events" strip is just `queryEvents` + the
 shipped `EventGrid`; the nav is a link to `/events`:
 
@@ -213,9 +209,8 @@ Fallback only — when you hit an error or need something not shown here: read t
 under `src/`, or look it up via the **`wix-docs`** skill.
 
 ## Hard rules
-- Set `WIX_CLIENT_ID` (STEP 2) — not the placeholder.
 - Style via base44 design tokens (`index.css` / shadcn Tailwind classes), never by rewriting the shipped components or adding a parallel theme file.
-- Header/footer live in a `Layout` around `<Outlet/>` (STEP 4) — never edit the shipped `Events`/`EventDetail` to add chrome.
+- Header/footer live in a `Layout` around `<Outlet/>` (STEP 3) — never edit the shipped `Events`/`EventDetail` to add chrome.
 - The Layout's fixed top region owns positioning: `<WixManageBanner/>` above `<Header/>`; your `Header` is plain in-flow markup (not `position:fixed`).
 - Paid ticket checkout goes through the shipped reserve → `getTicketCheckoutUrl` redirect (the Wix-hosted ticket form) — never a hand-built registration/ticket/payment URL.
 - Render live Wix data or the shipped empty/closed/not-found state — never mock events, tickets, guest counts, or "X spots left".

package/skills/wix-vibe-headless/references/members/INSTRUCTIONS.md

@@ -52,10 +52,10 @@ so you don't need to open them:**
 | `components/SocialButtons.jsx` | "Continue with Google/Facebook" buttons (kick off the redirect) |
 | `components/MemberMenu.jsx` | header account control — "Log in" vs. member name + log-out (like a cart button) |
 | `components/RequireAuth.jsx` | route gate: renders children for a member, else redirects to `/login` |
-| `components/WixManageBanner.jsx` | preview-only manage banner — drop it into your Layout (STEP 4) |
+| `components/WixManageBanner.jsx` | preview-only manage banner — drop it into your Layout (STEP 3) |
 | `pages/Login.jsx`, `pages/Account.jsx` | the shipped login + account routes (`/login`, `/account`) |
 | `pages/Callback.jsx` | social/SSO return route — mount at **exactly** `/callback` |
-| `rest/wix-config.js` | **you set the ids here** (STEP 2) |
+| `rest/wix-config.js` | the two ids, written by the install step |
 | `rest/wix-client.js` + `rest/wix-members-auth.js` | REST transport + the auth helper (copy verbatim) |
 
 They're already in place — go **straight to theming + wiring**, nothing to verify first. **Don't
@@ -71,11 +71,8 @@ fallback — a runtime error, or a field the snippets don't cover (see "Fallback
 > *calling* the exports, never by editing them. Its full JSDoc (state machine, `profile`, errors) is at
 > the top of the file — read that, not the whole body, if you need the contract.
 
-## STEP 2 — Credentials
-Write `src/rest/wix-config.js` with your `WIX_CLIENT_ID` and `WIX_METASITE_ID` from the prompt — the
-one place both ids live.
 
-## STEP 3 — Theme (nothing to style on the shipped components)
+## STEP 2 — Theme (nothing to style on the shipped components)
 The shipped components carry **no palette of their own** — they render from base44's design tokens
 in `src/index.css` (`:root`/`.dark`: `--background`, `--foreground`, `--card`, `--primary`, `--muted`,
 `--border`, `--radius`, `--font-*`) via shadcn Tailwind classes (`bg-card`, `text-foreground`,
@@ -83,10 +80,10 @@ in `src/index.css` (`:root`/`.dark`: `--background`, `--foreground`, `--card`, `
 are **already set to the brand by the design phase**, so the shipped auth surfaces are themed with
 zero work here. To adjust the palette, edit `index.css` (`:root` **and** `.dark`) — the base44 way;
 **never add a parallel theme file (e.g. a `theme.css`) or restyle the shipped JSX.** Build the
-Home/Header you add (STEP 4) from the **same** base44 tokens/classes so it matches automatically. A
+Home/Header you add (STEP 3) from the **same** base44 tokens/classes so it matches automatically. A
 dark brand is just base44's dark palette in `index.css` — no per-component work.
 
-## STEP 4 — Wire routes + provider (surgical `find_replace` on `src/App.jsx`, never a rewrite)
+## STEP 3 — Wire routes + provider (surgical `find_replace` on `src/App.jsx`, never a rewrite)
 **No file reads needed to wire this.** Every shipped page and `WixManageBanner` is a default export that takes **no props** — wire them exactly as the snippet shows; nothing in those files needs looking up.
 `App.jsx` carries required platform auth scaffolding (`AuthProvider`/`useAuth`, the **Base44 builder
 account**) — edit it in, don't replace it. The Wix member session is separate and ships under its own
@@ -152,7 +149,7 @@ function Layout() {
 
 ## What you build (not shipped)
 The **home / landing page**, the **`Header`** (mount `<MemberMenu/>` in it) and a **`Footer`** — the
-two you drop into the `Layout` (STEP 4) so they wrap every route — plus the overall brand story,
+two you drop into the `Layout` (STEP 3) so they wrap every route — plus the overall brand story,
 styled from the same base44 tokens/classes. The nav's account control is a `<MemberMenu/>` (shows
 "Log in" for a visitor, the member's name + log-out once signed in — render it as-is, don't wrap it in
 your own auth text button):
@@ -260,13 +257,12 @@ connection ids, a profile field these snippets don't have): read the relevant sh
 `src/rest/`, or look it up via the **`wix-docs`** skill.
 
 ## Hard rules
-- Set `WIX_CLIENT_ID` (STEP 2) — not the placeholder.
 - Style via base44 design tokens (`index.css` / shadcn Tailwind classes), never by rewriting the shipped components or adding a parallel theme file.
 - **Custom login only** — the member logs in on **your** UI; never redirect them to a Wix-hosted login page.
 - **One shared client** — login swaps the token set on `wix-client.js`; reuse it for everything so the
   member identity carries across the app. Never mint a second client or re-mint anonymously after login.
 - Copy `wix-members-auth.js` verbatim; extend by *calling* its exports, never by editing them.
-- Header/footer live in a `Layout` around `<Outlet/>` (STEP 4) — never edit the shipped `Login`/`Account`/`Callback` to add chrome; the fixed top region owns positioning (`<WixManageBanner/>` above a plain in-flow `<Header/>`).
+- Header/footer live in a `Layout` around `<Outlet/>` (STEP 3) — never edit the shipped `Login`/`Account`/`Callback` to add chrome; the fixed top region owns positioning (`<WixManageBanner/>` above a plain in-flow `<Header/>`).
 - **Never fake a member** — no mock logged-in state, invented profile, or roles. Render the real member or the real logged-out state.
 - **Fail loudly** — the helper throws `MemberAuthError`; surface `.message`, don't swallow it.
 - No `elevate` / admin scope, and no headless MFA/TOTP — those security layers are dashboard-governed.