@wix/agent-skills 1.14.0 → 1.15.0

package/skills/wix-headless/references/stores/PRODUCT_CATALOG_DATA.md

@@ -1,252 +0,0 @@
-# Recipe: Product Catalog Data Setup (seed scope)
-
-Replace the default sample products Wix Stores installs with on-brand products via the Stores REST API (`curl` against `wixapis.com/stores/v3/...` with the standard headers from `../shared/AUTHENTICATION.md`). This file covers the `seed` scope — data seeding only. Frontend wiring lives in the astro scope references (`../astro/stores/SHARED_WIRING.md`, `../astro/stores/PRODUCT_PAGES.md`, `../astro/ecom/CART_PAGES.md`, `../astro/stores/HOME_AND_NAV.md`) and should not be read by `seed`.
-
-> **Critical Rules — Read Before Starting**
-> 1. **V3 only** — all endpoints under `/stores/v3/...` for products.
-> 2. **No improvised endpoints** — if an REST call returns 404, stop and report. Do not guess alternative URLs. Do not loop on `docs-search REST (see DOCS_SEARCH.md)` more than twice on the same topic.
-> 3. **Do not seed categories** — they are merchant-driven. See Step 6 for the full rule and how the storefront still wires up automatically.
-
-> **V3 Catalog:** New Wix sites use Catalog V3. All endpoints below live under `/stores/v3/...`. The V1 product endpoints should not be used — they silently return 0 results on V3 catalogs.
-
-## Prerequisites
-
-- Wix Stores app must be installed on the site (installed via the apps-installer REST endpoint after scaffolding — see Step 0)
-
-## Setup: Replace Default Products via REST
-
-> **Conditional:** This section only applies when ALL of these are true:
-> - The Stores app was just installed (default sample products exist)
-> - CLI auth works (`npx @wix/cli@latest token --site "$SITE_ID"` returns a token)
-> - Discovery context is available in your prompt (business type, brand name, style)
->
-> **If CLI auth is not available, skip this entire section.** The 12 default products remain and can be customized later in the Wix dashboard.
-
-> **API error guard:** If any REST call in this seed scope returns a 404 or an unexpected error, do **not** retry the same call with a guessed alternative URL or namespace. Report the failing endpoint, request body, and error verbatim to the user, then stop.
-
-> **Stores appDefId** for install and `catalogReference.appId`: `215238eb-22a5-4c36-9e7b-e7c08025e04e`. (A different defId — `1380b703-ce81-ff05-f115-39571d94dfcd` — is used for `wixMetadata.appDefId` in the pages scope. Do not swap them.)
->
-> <!-- REVIEW (appDefId discrepancy): `1380b703-…` is labeled the `wixMetadata.appDefId` here, but `stores/INSTRUCTIONS.md` (back-in-stock split + failure-mode table) calls the same id the back-in-stock app id. One of these labels is wrong — flagged for human review; value left unchanged. -->
-
-
-### Step 0: Ensure Stores App Is Installed
-
-Before querying products, verify the Stores app is installed:
-
-1. **Probe** — `REST: POST https://www.wixapis.com/stores/v3/products/query`
-2. **If the API returns a "REQUIRED_APP_NOT_INSTALLED" error** → install the Wix Stores app:
-   ```
-   REST: POST https://www.wixapis.com/apps-installer-service/v1/app-instance/install
-   body: {
-     "tenant": { "tenantType": "SITE", "id": "<siteId>" },
-     "appInstance": { "appDefId": "215238eb-22a5-4c36-9e7b-e7c08025e04e", "enabled": true }
-   }
-   ```
-   > Translate this prose-HTTP form into the full `curl` tool-call shape — pass `body` as JSON in `-d` (NOT a stringified JSON). See `../shared/AUTHENTICATION.md` for the standard REST headers.
-
-   Then retry the probe query to confirm installation succeeded.
-3. **If the probe succeeds** → proceed to Step 1.
-
----
-
-Replace the 12 generic sample products with 3 on-brand products that match the user's business before building any code.
-
-### Step 1: Query Default Products
-
-```
-REST: POST https://www.wixapis.com/stores/v3/products/query
-body: {
-  "query": {
-    "paging": { "limit": 50 }
-  }
-}
-```
-
-Collect all product IDs from the response.
-
-### Step 2: Bulk Delete Defaults
-
-```
-REST: POST https://www.wixapis.com/stores/v3/bulk/products/delete
-body: {
-  "productIds": ["<id1>", "<id2>", ..., "<id12>"]
-}
-```
-
-### Step 3: Design 3 On-Brand Products
-
-No API call — use discovery context (business type, brand name, style, industry) to plan 3 products:
-
-- Product names, descriptions, and pricing appropriate for the business
-- Product type: `PHYSICAL`
-- Options (size, color, etc.) if appropriate for the business type
-
-**Product design guidelines by business type:**
-
-| Business Type | Product 1 | Product 2 | Product 3 |
-|--------------|-----------|-----------|-----------|
-| Skincare / beauty | Signature serum or moisturizer | Cleansing product | Gift set or bundle |
-| Clothing / fashion | Signature top or dress | Accessory item | Seasonal piece |
-| Food / bakery | Signature item (cake, bread) | Sampler or variety pack | Gift box |
-| Home / decor | Statement piece | Functional item | Set or collection |
-| Fitness / wellness | Core product (mat, equipment) | Accessory | Starter kit |
-| General retail | Best-seller item | Complementary item | Value bundle |
-
-Adapt names, descriptions, and pricing to match the brand's tone and style. Use the brand name in product descriptions where natural.
-
-### Step 4: Bulk Create Products
-
-> **V3 bulk create body format:** Each item in the `products` array is a flat product object — do NOT wrap in a `"product"` key. Only include `options` and `variantsInfo` when the product has meaningful variants (multiple sizes, colors, etc.). Simple products with no real variants should omit these fields — the API creates a default variant automatically using the product-level price.
-
-**Product with variants** (e.g., skincare with 30ml/50ml sizes):
-
-```
-REST: POST https://www.wixapis.com/stores/v3/bulk/products-with-inventory/create
-body: {
-  "products": [
-    {
-      "name": "<Product Name>",
-      "productType": "PHYSICAL",
-      "description": {
-        "nodes": [
-          {
-            "type": "PARAGRAPH",
-            "id": "<unique-id>",
-            "nodes": [
-              { "type": "TEXT", "textData": { "text": "<Product description>" } }
-            ],
-            "paragraphData": { "textStyle": { "textAlignment": "AUTO" } }
-          }
-        ],
-        "metadata": { "version": 1, "id": "<unique-id>" }
-      },
-      "visible": true,
-      "visibleInPos": true,
-      "physicalProperties": {},
-      "options": [
-        {
-          "name": "Size",
-          "optionRenderType": "TEXT_CHOICES",
-          "choicesSettings": {
-            "choices": [
-              { "choiceType": "CHOICE_TEXT", "name": "30ml" },
-              { "choiceType": "CHOICE_TEXT", "name": "50ml" }
-            ]
-          }
-        }
-      ],
-      "variantsInfo": {
-        "variants": [
-          {
-            "choices": [
-              {
-                "optionChoiceNames": {
-                  "optionName": "Size",
-                  "choiceName": "30ml",
-                  "renderType": "TEXT_CHOICES"
-                }
-              }
-            ],
-            "price": { "actualPrice": { "amount": "48.00" } },
-            "visible": true,
-            "inventoryItem": { "quantity": 50, "preorderInfo": { "enabled": false } },
-            "physicalProperties": {}
-          }
-        ]
-      }
-    }
-  ],
-  "returnEntity": true
-}
-```
-
-Add one more variant object per size in the `variants` array (one per choice combination). Use the Ricos format for descriptions (PARAGRAPH > TEXT > textData).
-
-**Simple product without real variants** (e.g., a gift set with one price and no size/color choices):
-
-Omit `options` and `variantsInfo` entirely. Set the price at the product level. The API creates a default variant automatically:
-
-```json
-{
-  "name": "Complete Gift Set",
-  "productType": "PHYSICAL",
-  "visible": true,
-  "visibleInPos": true,
-  "physicalProperties": {},
-  "priceData": { "price": 89.00 },
-  "manageVariants": false,
-  "inventoryItem": { "trackQuantity": true, "quantity": 30 }
-}
-```
-
-> **Do NOT create dummy options** (e.g., "Type: Standard") for simple products. Only add `options` and `variantsInfo` when the product genuinely has multiple variants. Phase 2's `ProductPurchase` component detects products without meaningful options and renders just the "Add to Cart" button — no unnecessary selection step for the buyer.
-
-Include all products in the same `products` array. Do not include `media` — product images are handled separately by the image agent after product creation.
-
-### Step 5: Verify
-
-```
-REST: POST https://www.wixapis.com/stores/v3/products/query
-body: {
-  "query": { "paging": { "limit": 50 } }
-}
-```
-
-Confirm exactly 3 products exist. Report the product names and prices to the user.
-
-### Step 6: Categories are NOT seeded
-
-This scope does **not** create categories. The default Wix Stores install ships one auto-managed category (`online_stores_all_products`) — leave it; the frontend filters it out by handle.
-
-If the merchant later creates visible categories in the Wix dashboard and assigns products to them, the storefront wires up automatically:
-
-- `<CategoryRail/>` renders pills above `/products` and `/category/[slug]`.
-- The `Navigation` Shop submenu lists the categories.
-- `/category/<slug>` becomes a reachable, server-side-filtered listing.
-
-This works because the frontend (`src/utils/categories.ts`, pre-copied by the orchestrator before Phase 4 and imported by the `pages-*` scopes) live-queries the Wix API at SSR time with a 5-min cache — no redeploy or regen is needed.
-
-### Step 7: Return Results
-
-Emit a structured JSON block at the end of your completion message per `../shared/RETURN_CONTRACT.md`. Do NOT write a sidecar file.
-
-```json
-{
-  "status": "complete",
-  "phase": "stores-seed",
-  "scope": "seed",
-  "summary": "Deleted {N} default products; created {N} on-brand products with variants",
-  "data": {
-    "products": [
-      {
-        "id": "<uuid>",
-        "name": "<name>",
-        "slug": "<slug>",
-        "variantId": "<uuid>",
-        "price": 48.0,
-        "inventory": 50,
-        "sku": "<sku>"
-      }
-    ],
-    "categories": [],
-    "deletedCount": 12,
-    "createdCount": 3
-  },
-  "files": [],
-  "errors": []
-}
-```
-
-`data.categories` is always `[]` — this scope does not seed categories. The field is retained for shape stability so downstream consumers don't need a new schema.
-
-The JSON block MUST be the last content in your message. Parent skill consumes `data.products[*].slug` and `data.products[*].variantId` for the Phase 4 Pages scopes.
-
-### Seed Boundary — Do Not Touch Other Site Data
-
-The seed scope is complete after Step 7. Do **not** attempt any of the following, even if they seem like reasonable polish:
-
-- Cleaning up "orphan customizations", "All Products" containers, brand records, or any other catalog metadata you didn't create.
-- Creating, renaming, or deleting any category — see Step 6 (leave the auto-managed "All Products" category in place).
-- Verifying your work via additional `query` calls beyond the Step 5 verification already performed.
-
-Phase 2+ (frontend wiring) is covered in the astro scope references (`../astro/stores/SHARED_WIRING.md`, `../astro/stores/PRODUCT_PAGES.md`, `../astro/stores/CATEGORY_PAGES.md`, `../astro/ecom/CART_PAGES.md`, `../astro/stores/HOME_AND_NAV.md`) — do not read them during `seed`.

package/skills/wix-headless/references/verticals/_schema.json

@@ -1,74 +0,0 @@
-{
-  "$schema": "https://json-schema.org/draft/2020-12/schema",
-  "title": "Wix Headless Vertical Frontmatter (Phase 1 — discovery only)",
-  "description": "Validates verticals/<name>.md frontmatter. Phase 1 scope only — later phases (setup, seed, design, pages, build) are owned by @skills/wix-manage plus this skill's own templates and INSTRUCTIONS.md files; per-pack fields (packages, cmsCollections, seed, components, componentsCss, pages, creates, contributes, include) are not part of this skill and not validated here.",
-  "type": "object",
-  "required": ["name", "description"],
-  "additionalProperties": false,
-  "properties": {
-    "name": {
-      "type": "string",
-      "pattern": "^[a-z][a-z0-9-]*$",
-      "description": "Must match filename stem (e.g., stores.md → 'stores')"
-    },
-    "description": { "type": "string" },
-    "triggers": {
-      "type": "array",
-      "items": { "type": "string" },
-      "description": "Prompt patterns that route to this vertical. Empty allowed for transitive-only packs (ecom, gift-cards, cms). The SKILL.md routing table is the actual source of truth for what gets loaded; this is human reference + a fallback signal."
-    },
-    "requires": {
-      "type": "array",
-      "items": { "type": "string" },
-      "description": "Verticals that must be co-loaded in the same read batch when this pack is loaded. Today: stores → [ecom, gift-cards]; gift-cards → [ecom]."
-    },
-    "features": {
-      "type": "array",
-      "items": {
-        "type": "object",
-        "required": ["name", "description"],
-        "additionalProperties": false,
-        "properties": {
-          "name": { "type": "string" },
-          "description": { "type": "string" }
-        }
-      },
-      "description": "Feature blurbs for DISCOVERY-create.md Step 3 Section B."
-    },
-    "apps": {
-      "type": "array",
-      "items": {
-        "type": "object",
-        "required": ["name"],
-        "additionalProperties": false,
-        "properties": {
-          "name": { "type": "string" },
-          "appDefId": { "type": "string" }
-        }
-      },
-      "description": "Zero or one entry per pack. apps[0].name fills the Source column of the Pages table."
-    },
-    "routes": {
-      "type": "array",
-      "items": {
-        "type": "object",
-        "required": ["route"],
-        "additionalProperties": false,
-        "properties": {
-          "route": {
-            "type": "string",
-            "description": "URL path (e.g. /cart) OR the literal 'Hosted by Wix' for Wix-hosted endpoints like checkout."
-          },
-          "name": {
-            "type": "string",
-            "description": "Optional user-facing page name override for DISCOVERY.md's Section C table. When omitted, the orchestrator derives the name from the path (/ → Home; /thank-you → Thank You). Set this only when path-derivation produces a poor name (e.g. /products/[slug] → 'Product Detail') or when the route has no path (e.g. ecom's Wix-hosted Checkout)."
-          }
-        }
-      }
-    },
-    "disabled": {
-      "type": "boolean",
-      "description": "If true, the pack's surfaces (pages, nav links, home blocks) are inactive by default — they ship as code but do not appear without a separate user action (today: enabling the matching Wix app from the dashboard, which the pack's runtime probe detects). DISCOVERY.md plan composition (Sections B + C) skips features and routes from disabled packs so the plan never promises a surface the user did not ask for. Today only the gift-cards pack uses disabled: true."
-    }
-  }
-}

package/skills/wix-headless/references/verticals/_schema.md

@@ -1,95 +0,0 @@
-# Vertical Schema (Phase 1 — discovery only)
-
-Each file in `references/verticals/` declares one vertical's contribution to discovery. The skill reads the user's prompt, loads the matching pack set (per SKILL.md routing table), and assembles the plan from the loaded packs' frontmatter.
-
-> **Phase 1 scope.** This schema covers only what discovery needs. Later phases (setup, seed, design system, pages, build) are owned by an upstream skill plus this skill's own templates and `INSTRUCTIONS.md` files:
-> - `@skills/wix-manage` — REST API recipes for site setup and content seeding.
->
-> Per-pack fields (`packages`, `cmsCollections`, `seed`, `components`, `componentsCss`, `pages`, `creates`, `contributes`, `include`) are not part of this schema — those concerns belong to upstream recipes and per-vertical templates, not this skill's vertical packs.
-
-## File format
-
-Markdown with YAML frontmatter. The frontmatter is the machine-readable config; the body is a short human-readable note about what the pack does and where its Phase 2+ implementation lives.
-
-## Frontmatter fields
-
-```yaml
----
-# --- Identity ---
-name: stores                          # unique vertical name, matches the filename stem
-description: "Short one-liner — what the pack provides at a glance."
-triggers:                             # prompt patterns that route the user to this vertical
-  - "sell"                            # case-insensitive substrings
-  - "ecommerce"                       # SKILL.md routing table is the source of truth for actual loading;
-                                      # this list is human reference + a fallback signal.
-
-# --- Dependencies ---
-requires: []                          # optional — verticals that must be co-loaded.
-                                      # Example: stores requires ["ecom", "gift-cards"]; gift-cards requires ["ecom"].
-                                      # If a pack with `requires:` is loaded, every name in the list MUST be in the same read batch.
-
-# --- Plan contribution ---
-features:                             # human-readable feature blurbs. Used in DISCOVERY-create.md Step 3 Section B.
-  - name: "Product catalog"
-    description: "Browse products with images, prices, and variants."
-
-# --- Plan Pages table ---
-apps:                                 # zero or one entry per pack. apps[0].name fills the Source column
-  - name: "Wix Stores"                # of DISCOVERY-create.md Step 3 Section C.
-    appDefId: "215238eb-22a5-4c36-9e7b-e7c08025e04e"
-
-routes:                               # routes the pack ships. Each entry → one row in the Pages table.
-  - route: "/products"                # `route:` value renders verbatim in the Route cell.
-  - route: "/products/[slug]"
-    name: "Product Detail"            # OPTIONAL: user-facing name override for the Page cell. When omitted,
-                                      # the orchestrator derives the name from the path (/ → "Home";
-                                      # /thank-you → "Thank You"). Override only when path-derivation
-                                      # produces a poor name (e.g. "/products/[slug]" → "Products [slug]")
-                                      # OR when the route has no path (use the literal string "Hosted by Wix").
-
-# --- Activation ---
-disabled: false                       # if true, the pack ships its code but its surfaces (pages, nav, home blocks) are inactive
-                                      # by default — they light up only when the user takes a separate action (today: enabling
-                                      # the matching Wix app from the dashboard, detected by a runtime probe). DISCOVERY.md plan
-                                      # composition (Sections B + C) skips features and routes from disabled packs so the plan
-                                      # never promises a surface the user did not opt into. Today only `gift-cards` sets
-                                      # `disabled: true`. Default false.
----
-```
-
-## Field reference
-
-| Field | Type | Required | Notes |
-|-------|------|----------|-------|
-| `name` | string | yes | Matches filename stem (`stores.md` → `name: stores`) |
-| `description` | string | yes | One-line label — what the pack provides |
-| `triggers` | string[] | yes (empty allowed for transitive-only packs) | Case-insensitive substrings. SKILL.md routing table is the actual source of truth for what gets loaded; this is human reference. |
-| `requires` | string[] | no | Verticals that must be co-loaded in the same read batch |
-| `features` | object[] | yes | `{name, description}` — used in DISCOVERY-create.md Step 3 Section B |
-| `apps` | object[] | no | Zero or one entry. `apps[0].name` fills the Source column of the Pages table; absence implies built-in (cms uses `"CMS (builtin)"` literal). |
-| `routes` | object[] | no | `{route, name?}` — one row per entry in the Pages table |
-| `disabled` | bool | no | If true, the pack's surfaces are inactive by default. DISCOVERY plan skips disabled packs from Sections B + C. Today only `gift-cards`. Default false. |
-
-## How discovery uses the pack
-
-1. The orchestrator reads the user prompt and the SKILL.md routing table to determine the resolved pack set (top-level + `requires:` chain + always-on `cms`).
-2. It reads every pack file in the resolved set in **one concurrent batch**.
-3. From each pack's frontmatter it assembles:
-   - **Section B (interactive only)** — `features[].name` + `features[].description`, skipping packs with `disabled: true`.
-   - **Section C — Pages table** — one row per entry in `routes:` from non-disabled packs. Page cell uses `name:` override if present, else derives from the `route:` path. Source cell uses `apps[0].name`; for transitive packs, walk up the `requires:` chain to the top-level puller and use ITS `apps[0].name`. For `cms`, use the literal `"CMS (builtin)"`.
-4. Discovery never reads anything else from the pack file. Phase 2+ implementation work lives in the upstream skills.
-
-## Adding a new vertical
-
-1. Create `<name>.md` in this directory with the frontmatter above.
-2. Add a row to SKILL.md's routing table with the resolved pack set (top-level + transitive `requires:` + `cms`).
-3. No other registration needed.
-
-## Validation (informal)
-
-Sanity-check at session start:
-- `name` matches filename stem.
-- Every name in `requires:` resolves to a sibling file in this directory.
-- Every `route:` is either a `/`-prefixed path OR the literal string `"Hosted by Wix"`.
-
-If validation fails, fail loud — surface the error and stop. A malformed pack breaking the whole flow is better than silently dropping it.

package/skills/wix-headless/references/verticals/blog.md

@@ -1,31 +0,0 @@
----
-name: blog
-description: "Blog — post listing, post detail with rich content, RSS feed, sitemap."
-triggers: ["blog", "publish articles", "write posts", "content site", "editorial", "journal", "newsletter"]
-
-features:
-  - name: "Blog"
-    description: "Publish posts with a listing page, individual post pages with rich content rendering, and an RSS feed."
-  - name: "RSS and sitemap"
-    description: "Auto-generated RSS feed and XML sitemap for search engine discovery."
-
-apps:
-  - name: "Wix Blog"
-    appDefId: "14bcded7-0066-7c35-14d7-466cb3f09103"
-
-routes:
-  - route: "/blog"
-  - route: "/blog/[slug]"
-    name: "Blog Post"   # path-derivation would produce "Blog [slug]" — override with the user-facing label
-  - route: "/rss.xml"
-
-disabled: false
----
-
-# Blog Pack
-
-Loaded when the user's prompt mentions blogging, publishing, or editorial content.
-
-> **Discovery contract.** Phase 1 reads only the frontmatter above. Phase 2+ implementation (post seeding, RSS, page composition, ricos rendering) lives in an upstream skill plus this skill's own `references/astro/blog/` + `references/blog/INSTRUCTIONS.md`:
->
-> - `@skills/wix-manage` ships the seeding recipe — `references/blog/how-to-create-blog-posts.md`.

package/skills/wix-headless/references/verticals/bookings.md

@@ -1,41 +0,0 @@
----
-name: bookings
-description: "Service-based booking — services catalog (with location + category filters and staff selection), availability calendar, and booking flow for appointments and classes via Wix Bookings."
-triggers: ["booking", "appointment", "schedule", "reserve", "class", "session", "consult", "therapy", "lesson", "coaching", "trainer", "tutor", "salon", "spa", "clinic"]
-requires: []
-
-features:
-  - name: "Services catalog"
-    description: "Browse bookable appointment and class services with descriptions, duration, and pricing — filterable by category and (for multi-location businesses) by location."
-  - name: "Staff selection"
-    description: "On multi-staff services, choose a specific staff member (or any) and see that staff's availability."
-  - name: "Online booking"
-    description: "Pick an available time slot on a day-grouped availability calendar, complete the service's booking form, and confirm."
-  - name: "Secure checkout"
-    description: "Free or pay-in-person bookings confirm instantly; paid services hand off to Wix's secure hosted checkout."
-
-apps:
-  - name: "Wix Bookings"
-    appDefId: "13d21c63-b5ec-5912-8397-c3a5ddb27a97"
-
-routes:
-  - route: "/services"
-  - route: "/services/[slug]"
-    name: "Service Detail"
-  - route: "/booking-confirmation"
-    name: "Booking Confirmation"
-  - route: "Hosted by Wix"
-    name: "Secure Checkout"
-
-disabled: false
----
-
-# Bookings Pack
-
-Loaded when the user's prompt implies offering appointments, classes, or sessions.
-
-> **Discovery contract.** Phase 1 reads only the frontmatter above to compose the plan's Pages table. Phase 2+ implementation (seeding, page composition, theming) lives in this skill's own `references/astro/templates/bookings/` + `references/bookings/INSTRUCTIONS.md`.
->
-> - Seed recipe: `<SKILL_ROOT>/references/bookings/SERVICES_DATA.md` (service creation via Wix Bookings REST API).
->
-> No per-pack `seed`, `components`, `componentsCss`, or `pages` blocks live in this skill anymore.

package/skills/wix-headless/references/verticals/cms.md

@@ -1,30 +0,0 @@
----
-name: cms
-description: "Content pages — Home, About, FAQ managed via Wix CMS. Always loaded."
-triggers: []   # not trigger-based — always loaded (every site needs About/FAQ)
-
-features:
-  - name: "About (CMS-based)"
-    description: "Tell your brand story with images and rich text. Editable from the Wix dashboard's Content Manager."
-  - name: "FAQ (CMS-based)"
-    description: "Common questions and answers about your products. Managed from the dashboard's Content Manager."
-
-apps: []   # CMS is built-in, no app install
-
-routes:
-  - route: "/"
-  - route: "/about"
-  - route: "/faq"
-
-disabled: false
----
-
-# CMS Pack
-
-Always loaded. Provides Home + About + FAQ content pages editable from the Wix dashboard's Content Manager.
-
-> **Discovery contract.** Phase 1 reads only the frontmatter above. Phase 2+ implementation (collection schemas, item seeding, page composition) lives in an upstream skill plus this skill's own `references/astro/cms/` + `references/cms/INSTRUCTIONS.md`:
->
-> - `@skills/wix-manage` ships the recipes — `references/cms/cms-schema-management.md`, `cms-data-items-crud.md`, `cms-references-and-relationships.md`.
->
-> Collection names like `about-content` / `faq` are an implementation detail the seeder picks at run time — they are not pre-approved by the user in the discovery plan.

package/skills/wix-headless/references/verticals/ecom.md

@@ -1,25 +0,0 @@
----
-name: ecom
-description: "Vertical-agnostic ecommerce — cart page, checkout redirect, order confirmation. Co-loaded by packs that require it."
-triggers: []   # never triggered independently — co-loaded via another pack's `requires:`
-
-features:
-  - name: "Cart & checkout"
-    description: "Add items to cart, review order, check out via Wix's secure hosted checkout. Order confirmation on thank-you page."
-
-apps: []   # no app to install — @wix/ecom works with any installed catalog app
-
-routes:
-  - route: "/cart"
-  - route: "/thank-you"
-  - route: "Hosted by Wix"   # Wix-hosted endpoint — no .astro file. Listed so the discovery plan's Section C table includes a Checkout row for the Wix-hosted endpoint. The route cell renders the literal string "Hosted by Wix".
-    name: "Checkout"
-
-disabled: false
----
-
-# Ecom Pack
-
-Vertical-agnostic ecommerce cart, checkout, and order confirmation. Co-loaded by any pack that needs cart/checkout (today: `stores`, `gift-cards`; future: `bookings`, `events`) via the `requires:` field. Never user-triggered.
-
-> **Discovery contract.** Phase 1 reads only the frontmatter above. Phase 2+ implementation (cart wiring, checkout redirect, discount codes) lives in this skill's own `references/astro/ecom/` + `references/ecom/INSTRUCTIONS.md`.

package/skills/wix-headless/references/verticals/forms.md

@@ -1,26 +0,0 @@
----
-name: forms
-description: "Forms — contact, lead capture, or newsletter signup with CRM integration."
-triggers: ["contact form", "lead form", "signup form", "waitlist", "registration", "get in touch", "inquiry", "feedback"]
-
-features:
-  - name: "Contact form"
-    description: "Dynamic form powered by @wix/forms with server-side schema discovery and client-side submission. Submissions create CRM contacts automatically."
-
-apps:
-  - name: "Wix Forms"
-    appDefId: "225dd912-7dea-4738-8688-4b8c6955ffc2"
-
-routes:
-  - route: "/contact"
-
-disabled: false
----
-
-# Forms Pack
-
-Loaded when the user's prompt mentions forms, contact pages, inquiries, or signups.
-
-> **Discovery contract.** Phase 1 reads only the frontmatter above. Phase 2+ implementation (form creation, field selection per purpose, submission triggers, page composition) lives in an upstream skill plus this skill's own `templates/forms/` + `references/forms/INSTRUCTIONS.md`:
->
-> - `@skills/wix-manage` ships the recipe — `references/forms/create-form.md`.

package/skills/wix-headless/references/verticals/gift-cards.md

@@ -1,24 +0,0 @@
----
-name: gift-cards
-description: "Conditional gift-card buy page + nav/home contributions. Detects the Wix Gift Card app at runtime; renders only when installed."
-triggers: []   # never triggered independently — co-loaded by packs that include a storefront via `requires:`
-requires: ["ecom"]   # buy flow uses currentCart.addToCurrentCart
-
-features:
-  - name: "Gift cards (when enabled in dashboard)"
-    description: "Customers buy preset-amount gift cards on a dedicated page. Wix issues redeemable codes after payment and emails the recipient. The page, nav link, and home teaser only appear once the Wix Gift Card app is enabled in the dashboard — no rebuild needed."
-
-apps: []   # do NOT auto-install; the user opts in via Catalog → Gift Cards in the dashboard
-
-routes:
-  - route: "/gift-cards"
-
-# disabled: true → the pack's surfaces are inactive by default; they light up only when the user enables the matching Wix app from the dashboard. DISCOVERY.md Section B + C plan composition skips features and routes from disabled packs so the plan never promises a surface the user did not opt into.
-disabled: true
----
-
-# Gift Cards Pack
-
-Passive vertical: code ships in every site that has a storefront, but every gift-card surface only renders if the **Wix Gift Card app** is enabled in the site's dashboard. Never user-triggered.
-
-> **Discovery contract.** Phase 1 reads only the frontmatter above. Because `disabled: true`, the discovery plan never promises any gift-card surface to the user. Phase 2+ implementation (runtime probe, buy flow, nav/home contributions) lives in this skill's own `references/astro/templates/gift-cards/` + `references/gift-cards/INSTRUCTIONS.md`; see `references/astro/templates/gift-cards/gift-cards.astro` for the working buy-page reference.

package/skills/wix-headless/references/verticals/stores.md

@@ -1,33 +0,0 @@
----
-name: stores
-description: "Ecommerce — product catalog with add-to-cart. Co-loads ecom (cart/checkout) and gift-cards (passive)."
-triggers: ["sell", "ecommerce", "store", "shop", "products", "merchandise", "catalog", "merch", "buy"]
-requires: ["ecom", "gift-cards"]
-
-features:
-  - name: "Product catalog"
-    description: "Browse products with images, prices, and variants. Click through to detailed product pages with add-to-cart."
-
-apps:
-  - name: "Wix Stores"
-    appDefId: "215238eb-22a5-4c36-9e7b-e7c08025e04e"
-
-routes:
-  - route: "/products"
-  - route: "/products/[slug]"
-    name: "Product Detail"   # path-derivation would produce "Products [slug]" — override with the user-facing label
-  - route: "/category/[slug]"
-    name: "Category"
-
-disabled: false
----
-
-# Stores Pack
-
-Loaded when the user's prompt implies selling products.
-
-> **Discovery contract.** Phase 1 reads only the frontmatter above to compose the plan's Pages table. Phase 2+ implementation (seeding, page composition, theming) lives in an upstream skill plus this skill's own `references/astro/templates/stores/` + `references/stores/INSTRUCTIONS.md`:
->
-> - `@skills/wix-manage` ships the seeding recipes — `references/stores/setup-online-store-catalog-v3.md`, `bulk-create-products-with-options.md`, `create-product-from-image.md`.
->
-> No per-pack `seed`, `components`, `componentsCss`, or `pages` blocks live in this skill anymore.