@wix/agent-skills 1.6.0 → 1.8.0

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

@@ -1,10 +1,15 @@
-# Vertical Schema
+# Vertical Schema (Phase 1 — discovery only)
 
-Each file in `references/verticals/` declares one vertical's contribution to the build flow. The skill reads the user's prompt, loads matching verticals, and assembles the phase-based flow from them.
+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 markdown body is human-readable docs (what the vertical does, gotchas, examples).
+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
 
@@ -12,118 +17,43 @@ Markdown with YAML frontmatter. The frontmatter is the machine-readable config.
 ---
 # --- 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"
-  - "ecommerce"
-  - "store"
-  - "shop"
-description: "Full ecommerce: products, cart, checkout, thank-you"
+  - "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 list of vertical names that must be co-loaded
-                                      # e.g. stores requires ["ecom"] for cart/checkout
+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 for the plan
+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."
-  - name: "Cart & checkout"
-    description: "Add to cart, review, check out via Wix's hosted checkout."
 
-# --- Infrastructure ---
-apps:                                 # MCP app installs (0 or more per pack)
-  - name: "Wix Stores"
+# --- 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"
-packages:                             # npm packages to install
-  - "@wix/stores"
-  - "@wix/ecom"
-  - "@wix/redirects"
-  - "@wix/site"
-
-# --- Routes this vertical contributes (for plan assembly) ---
-# Agent dispatch for rewriting page files lives under the 'pages:' phase entry further down.
-routes:
-  - route: "/products"
+
+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 DISCOVERY's Section C table. 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] would derive to "Products [slug]") OR when the route has no path (ecom's Wix-hosted Checkout uses route: "Hosted by Wix" + name: "Checkout").
-
-# --- CMS collections this vertical declares (if any) ---
-cmsCollections: []                    # stores adds none; the cms vertical adds About + FAQ
-
-# --- Seed phase: data seeding (MCP-only, no design-token dependency) ---
-seed:
-  agentLocation: "references/stores/"
-  scope: "seed"
-  description: "Delete default sample products, create on-brand products"
-  references: ["references/stores/PRODUCT_CATALOG_DATA.md"]
-
-# --- Components phase: shared React/Astro components (runs after Design System, parallel with other verticals' components) ---
-components:
-  agentLocation: "references/stores/"
-  scope: "components"
-  description: "SDK-wiring code and reusable islands (reads design tokens + site.d.ts)"
-  references: ["references/stores/SHARED_WIRING.md"]
-  files:
-    - "src/utils/wix-image.ts"
-    - "src/utils/analytics.ts"
-    - "src/components/SeoTags.astro"
-    - "src/components/AddToCartButton.tsx"
-    - "src/components/CartBadge.tsx"
-    - "src/components/ProductPurchase.tsx"
-    - "src/components/CartView.tsx"
-
-# --- Pages phase: route files (written ONCE with both visual design and data queries) ---
-pages:
-  - name: "product-pages"
-    agentLocation: "references/stores/"
-    scope: "pages-products"
-    references: ["references/stores/PRODUCT_PAGES.md"]
-    files:
-      - "src/pages/products/index.astro"
-      - "src/pages/products/[slug].astro"
-      - "src/components/ProductCard.astro"
-  - name: "cart-checkout"
-    agentLocation: "references/stores/"
-    scope: "pages-cart-checkout"
-    references: ["references/ecom/CART_PAGES.md"]
-    files:
-      - "src/pages/cart.astro"
-      - "src/pages/thank-you.astro"
-  - name: "home-and-nav"
-    agentLocation: "references/stores/"
-    scope: "pages-home-and-nav"
-    references: ["references/stores/HOME_AND_NAV.md"]
-    files:
-      - "src/pages/index.astro (patch)"
-      - "src/components/Navigation.astro (patch)"
-
-# --- File ownership declarations ---
-# `creates:` lists files this vertical is the sole author of. Schema validator
-#   enforces single-owner (two verticals claiming the same file → fail at session start)
-#   and unresolved-import check (if ANY loaded reference imports ../utils/X, some
-#   vertical must declare it in `creates:` OR it must be a plugin shared utility).
-# `contributes:` lists files this vertical co-edits via named markers. The Design
-#   System phase scaffolds shell files (Navigation.astro, index.astro) with markers;
-#   each vertical inserts at its marker. Replaces the old `homeSection:` concept —
-#   contributes[].description is surfaced in the plan shown to the user.
-# Skill-level shared utilities (wix-image.ts, analytics.ts, ricos.ts) are NEVER listed here —
-#   they ship via <SKILL_ROOT>/shared-utilities/ and are copied into projects by
-#   <SKILL_ROOT>/scripts/seed-utilities.sh during Setup.
-creates:
-  - { file: src/components/AddToCartButton.tsx, phase: components }
-  - { file: src/pages/products/index.astro,     phase: pages }
-
-contributes:
-  - file: src/pages/index.astro
-    marker: "<!-- home:stores -->"
-    description: "Featured products grid (3–6 items from productsV3.queryProducts)"
-  - file: src/components/Navigation.astro
-    marker: "<!-- nav:links -->"
-    description: "Shop menu link → /products"
-
-# --- Loading + activation (orthogonal pack-level flags) ---
-include: false                        # if true, the pack loads in every site regardless of triggers/requires (today: only `cms` sets include:true). Default false → loads on trigger match or via another pack's requires.
-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 ask for. Today only `gift-cards` sets disabled:true. Default false.
+    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.
 ---
 ```
 
@@ -131,55 +61,35 @@ disabled: false                       # if true, the pack ships its code but its
 
 | Field | Type | Required | Notes |
 |-------|------|----------|-------|
-| `name` | string | yes | Matches filename stem (e.g., `stores.md` → `name: stores`) |
-| `triggers` | string[] | yes unless `include: true` | Case-insensitive substrings matched against user prompt |
-| `description` | string | yes | Short label for the plan |
-| `features` | object[] | yes | Feature blurbs for the plan's "Features" section |
-| `apps` | object[] | no | MCP app installs; `{name, appDefId}` pairs |
-| `packages` | string[] | yes | npm packages |
-| `routes` | object[] | no | `{route, name?}` — routes the pack ships. Optional `name` overrides the path-derived page name in DISCOVERY's Section C. |
-| `cmsCollections` | object[] | no | Collections this vertical adds |
-| `seed` | object | no | Seed-phase agent config; omit if the vertical has no seeding |
-| `components` | object | no | Components-phase agent config; omit if none |
-| `pages` | object[] | no | Pages-phase agent dispatch (one entry per page-rewrite sub-scope) |
-| `creates` | object[] | no | `{file, phase}` — files this vertical is sole author of. Schema validator enforces single-owner + unresolved-import check. |
-| `contributes` | object[] | no | `{file, marker, description}` — files this vertical co-edits via named markers. |
-| `include` | bool | no | If true, the pack loads in every site regardless of triggers/requires (today: only `cms`). Controls **loading**. |
-| `disabled` | bool | no | If true, the pack ships its code but its surfaces are inactive by default — they light up only via a separate user action (today: enabling the matching Wix app from the dashboard; the pack's runtime probe detects it). DISCOVERY plan composition skips disabled packs from Sections B + C. Today only `gift-cards`. Controls **activation**. |
-
-### `include` vs `disabled` — orthogonal axes
-
-The two flags answer different questions. Don't conflate them:
-
-- **`include`** — *Is this pack in the loaded set?* Default: load when triggers match or another pack pulls it in via `requires:`. `include: true` overrides that and forces the pack to load in every site. Used by `cms` (every site needs About/FAQ).
-- **`disabled`** — *Do this pack's surfaces appear without further user action?* Default: yes — the moment the pack is loaded, its routes and contributions are live. `disabled: true` says no — the code ships, but a separate runtime check (today: a dashboard-app probe) decides whether to render. Used by `gift-cards` (the surface only appears once the user enables the Wix Gift Card app from the dashboard).
-
-A pack can be `include: true, disabled: true` (always loaded but never auto-active) or any other combination — they don't conflict.
-
-## How the skill uses the vertical
-
-1. **Discovery step**: scan loaded verticals for `features`, `routes`, `cmsCollections` → assemble plan markdown.
-2. **Setup phase**: collect `apps`, `packages` → one MCP call per app, one `npm install` with merged package list.
-3. **Seed phase**: for each vertical with a `seed` block, dispatch `seed.agent + scope`.
-4. **Design System phase**: Design System agent writes global styling — `@theme` token contract + a small set of always-required global semantic classes (compound patterns, interactive states, JS targets). Layout/spacing/typography flows through tokens-as-utilities at call sites; see `references/shared/STYLING.md`.
-5. **Components phase**: for each vertical with a `components` block, dispatch `components.agent + scope` (parallel).
-6. **Pages phase**: for each vertical, launch one agent per `pages[*]` entry (parallel).
+| `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 frontmatter per the schema above.
-2. Create `references/<name>/` with `INSTRUCTIONS.md` and `references/`.
-3. No changes needed to `SKILL.md` or other verticals.
-
-The skill discovers verticals by listing this directory. No registration step.
+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)
 
-The skill should sanity-check vertical frontmatter at load time:
-- `name` matches filename stem
-- `packages` non-empty (empty would mean nothing to install)
-- If `seed` is declared, `seed.agentLocation` exists on disk
-- If `components` or `pages` declared, their agent locations exist on disk
-- All declared `apps`, `routes`, `creates`, `contributes` paths are valid and don't collide with another loaded vertical's owned paths
+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 to the user. A malformed vertical breaking the whole flow is better than silently dropping it.
+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,7 +1,7 @@
 ---
 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"]
-description: "Blog — post listing, post detail with rich content, RSS feed, sitemap"
 
 features:
   - name: "Blog"
@@ -13,113 +13,19 @@ apps:
   - name: "Wix Blog"
     appDefId: "14bcded7-0066-7c35-14d7-466cb3f09103"
 
-packages:
-  - "@wix/blog"
-  - "@wix/ricos"
-  - "@astrojs/rss"
-  - "@astrojs/sitemap"
-
 routes:
   - route: "/blog"
   - route: "/blog/[slug]"
     name: "Blog Post"   # path-derivation would produce "Blog [slug]" — override with the user-facing label
   - route: "/rss.xml"
 
-cmsCollections: []
-
-seed:
-  agentLocation: "references/blog/"
-  scope: "seed"
-  description: "Ensure Blog app is installed, seed 3 on-brand blog posts via MCP with rich Ricos content"
-  references: ["references/blog/BLOG_CONTENT.md"]
-
-components:
-  agentLocation: "references/blog/"
-  scope: "components"
-  description: "Blog service module (queryBlogPosts, getPostBySlug), RicosViewer React wrapper, site constants, astro.config sitemap integration"
-  references: ["references/blog/BLOG_SETUP.md"]
-  files:
-    - "src/lib/blog.ts"
-    - "src/components/RicosViewer.tsx"
-    - "src/consts.ts"
-    - "astro.config.mjs (patch — add site property and sitemap integration)"
-
-pages:
-  - name: "blog-pages"
-    agentLocation: "references/blog/"
-    scope: "pages"
-    description: "Wire blog listing + post detail pages to @wix/blog SDK, add RSS feed endpoint, BlogPost layout, SEO head, date formatting, patch home page latest-posts section"
-    references: ["references/blog/BLOG_PAGES.md"]
-    files:
-      - "src/pages/blog/index.astro"
-      - "src/pages/blog/[...slug].astro"
-      - "src/pages/rss.xml.js"
-      - "src/layouts/BlogPost.astro"
-      - "src/components/BaseHead.astro"
-      - "src/components/FormattedDate.astro"
-      - "src/pages/index.astro (patch — latest-posts section only)"
-
-creates:
-  - { file: src/lib/blog.ts,                  phase: components }
-  - { file: src/components/RicosViewer.tsx,   phase: components }
-  - { file: src/consts.ts,                    phase: components }
-  - { file: src/pages/blog/index.astro,       phase: pages }
-  - { file: src/pages/blog/[...slug].astro,   phase: pages }
-  - { file: src/pages/rss.xml.js,             phase: pages }
-  - { file: src/layouts/BlogPost.astro,       phase: pages }
-  - { file: src/components/BaseHead.astro,    phase: pages }
-  - { file: src/components/FormattedDate.astro, phase: pages }
-
-contributes:
-  - file: astro.config.mjs
-    marker: "<!-- config:sitemap -->"
-    description: "site property + @astrojs/sitemap integration"
-  - file: src/pages/index.astro
-    marker: "<!-- home:blog -->"
-    description: "Latest 3 posts grid (cover images, titles, dates, excerpts) from queryBlogPosts(3)"
-  - file: src/components/Navigation.astro
-    marker: "<!-- nav:links -->"
-    description: "Blog menu link → /blog"
-
-include: false
 disabled: false
 ---
 
 # Blog Pack
 
-Blog vertical for content-driven sites. Loaded when the user's prompt mentions blogging, publishing, or editorial content.
-
-## Phase decomposition
-
-| Scope | Phase | Files | Depends on |
-|-------|-------|-------|------------|
-| `seed` | Phase 1 — Step 3 (bg) | None (MCP only) | MCP connection |
-| `components` | Phase 3 — Step 4.5 (bg) | blog.ts, RicosViewer.tsx, consts.ts, astro.config.mjs | Styling contract |
-| `blog-pages` | Phase 4 — Step 7 (bg) | blog/index.astro, blog/[...slug].astro, rss.xml.js, BlogPost.astro, BaseHead.astro, FormattedDate.astro, index.astro (patch) | Phase 2 Design System + Phase 1 Seed post data |
-
-Phase 3 Components runs in the background from Step 4.5 through Phase 4. Phase 4 blog-pages dispatches in Step 7 after Phase 3 + Phase 1 Seed complete — it needs the React islands written by Phase 3 and the seeded post slugs from Phase 1.
-
-RSS feed generation (`rss.xml.js`) is included in the blog-pages scope rather than a separate scope — it's ~15 lines, has no design dependency, and doesn't justify its own agent dispatch.
-
-## Known failure modes (propagate to agent prompts)
-
-| Wrong | Right |
-|-------|-------|
-| `import { items } from "@wix/data"` for blog queries | `import { posts } from "@wix/blog"` — use the Blog SDK |
-| `<article set:html={post.content} />` | `<RicosViewer client:only="react" content={post.richContent} />` — content is Ricos format |
-| Skip `wixMetadata` export on `[...slug].astro` | Required for Wix page routing and SEO |
-| `media.wixMedia.image` as raw URL | `media.getImageUrl(item.media.wixMedia.image).url` — must resolve |
-| Query posts without `RICH_CONTENT` fieldset | Always request `RICH_CONTENT` or `post.richContent` is undefined |
-| `const { tag } = await tags.getTag(id)` | `const tag = await tags.getTag(id)` — returns directly (unlike `getCategory()`) |
-| Scoped `<style>` for RicosViewer overrides | `<style is:global>` — React islands don't inherit scoped Astro styles |
-| Skip `.ricos-content` color overrides | Ricos CSS hardcodes `color: rgb(0, 0, 0)` — invisible on dark themes without overrides |
-
-## Images
-
-Cover images for blog posts are generated by the shared image agent (`image-phase-2-entity` scope), not by blog agents. The image agent PATCHes cover images onto post records after Phase 1 Seed creates them. Phase 4 agents query posts and render `post.media` — the image URL flows through the post record.
-
-## References
+Loaded when the user's prompt mentions blogging, publishing, or editorial content.
 
-- `references/blog/BLOG_CONTENT.md` — Phase 1: MCP post seeding
-- `references/blog/BLOG_SETUP.md` — Phase 3 Components: service module, RicosViewer, config
-- `references/blog/BLOG_PAGES.md` — Phase 2 blog-pages: listing, detail, RSS, layout, SEO
+> **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

@@ -0,0 +1,41 @@
+---
+name: bookings
+description: "Service-based booking — services catalog, availability calendar, and booking flow 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 services (appointments or group classes) with descriptions, duration, pricing, and instructor info."
+  - name: "Online booking"
+    description: "Pick an available time slot, complete a booking form, and receive confirmation — all without leaving your site."
+  - name: "Group classes"
+    description: "Capacity-aware class sign-up with party size, the leading instructor per session, and a waitlist when a session is full."
+  - name: "Manage booking"
+    description: "View and cancel a booking from the confirmation page or a shared manage link, no account login required."
+
+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: "/manage-booking"
+    name: "Manage Booking"
+
+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,7 +1,7 @@
 ---
 name: cms
-triggers: []                          # not trigger-based — always loaded
-description: "Content pages — About + FAQ managed via Wix 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)"
@@ -9,113 +9,22 @@ features:
   - 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
-
-packages:
-  - "@wix/data"
-  - "@wix/wix-data-items-sdk"   # provides the `items` namespace (query/insert/etc.). @wix/data 1.0.448 stopped re-exporting it; pages import from here directly. See references/cms/CMS_FOUNDATIONS.md.
-  - "@wix/essentials"
+apps: []   # CMS is built-in, no app install
 
 routes:
   - route: "/"
   - route: "/about"
   - route: "/faq"
 
-cmsCollections:
-  - name: "about-content"
-    fields:
-      - { name: "heading", type: "string", required: true }
-      - { name: "body", type: "rich-text", required: true }
-      - { name: "image", type: "image", required: false }
-  - name: "faq"
-    fields:
-      - { name: "question", type: "string", required: true }
-      - { name: "answer", type: "rich-text", required: true }
-      - { name: "sortOrder", type: "number", required: true }
-
-seed:
-  agentLocation: "references/cms/"
-  scope: "seed"
-  description: "Create about-content + faq collections, seed 1 about-content item and 4–6 contextual FAQ items based on the business type"
-  references: ["references/cms/CMS_FOUNDATIONS.md"]
-
-# CMS has no "components" — page designers write CMS-reading pages directly using
-# @wix/data queries inline. So the only post-design work is the pages scope below.
-components: null
-
-pages:
-  - name: "cms-pages"
-    agentLocation: "references/cms/"
-    scope: "pages"
-    description: "Swap placeholder copy in About + FAQ pages for live @wix/data queries"
-    references: ["references/cms/CMS_FOUNDATIONS.md"]
-    files:
-      - "src/pages/about.astro"
-      - "src/pages/faq.astro"
-
-creates:
-  - { file: src/pages/about.astro, phase: pages }
-  - { file: src/pages/faq.astro,   phase: pages }
-
-# CMS does NOT contribute to the home page. The designer owns the brand-story
-# section directly (writes its own placeholder heading/paragraph). Historically
-# this pack declared a home:cms marker but no phase patched it, so the
-# designer's placeholder copy shipped as-is to preview. Dropping the marker
-# makes that behavior explicit.
-contributes: []
-
-include: true   # always loaded — every site gets About + FAQ content pages
 disabled: false
 ---
 
 # CMS Pack
 
-Always loaded. Provides content pages (Home, About, FAQ) editable from the Wix dashboard's Content Manager.
-
-## Why always-include
-
-Every site needs About and FAQ content. The CMS collections give the user a dashboard-editable surface, so non-technical owners can update copy without touching code.
-
-## Pages
-
-- **Home** (`/`) — designed by `designer-home`. The designer writes the brand-story section directly (no CMS-driven home contribution; see `contributes: []` in frontmatter above for why).
-- **About** (`/about`) — content from `about-content` CMS collection
-- **FAQ** (`/faq`) — content from `faq` CMS collection
-
-## Phase 1
-
-One agent creates both collections and seeds them:
-- `about-content` — one item (heading, body, optional image) with placeholder copy based on business context
-- `faq` — 4–6 items tailored to the business type (e.g., shipping, returns, sizing, care instructions)
-
-The agent tailors FAQ content to the vertical. For stores: shipping/returns/sizing. For future verticals: different sets.
-
-## Phase 2 pattern
-
-About and FAQ pages read their CMS content inline via `@wix/data`:
-
-```astro
----
-import * as items from "@wix/wix-data-items-sdk";
-const faqs = await items
-  .query("faq")
-  .ascending("sortOrder")
-  .find()
-  .then(r => r.items);
----
-```
-
-> **Why not `import { items } from "@wix/data"`?** That's the documented Wix headless pattern but `@wix/data` 1.0.448 dropped the `items` re-export — only sub-namespaces (`backups`, `collections`, `permissions`, …) remain, and the documented form fails the build with `'items' is not exported by '@wix/data'`. The actual `items` API lives in `@wix/wix-data-items-sdk` (which `@wix/data` depends on transitively). Importing from there directly works on every current `@wix/data` version.
-
-No React islands required for static content pages — they SSR from data.
-
-## Contract
-
-This pack contributes contract keys for content-page class names. Other packs do not typically overlap with these keys.
-
-The home page's `heroSection` and `brandStory` keys are consumed by `designer-home`, which composes the home page from every loaded pack's `homeSection` snippet.
-
-## References
+Always loaded. Provides Home + About + FAQ content pages editable from the Wix dashboard's Content Manager.
 
-- `references/cms/CMS_FOUNDATIONS.md` — existing CMS reference (data seeding + page wiring)
-- `references/cms/FAQ_KNOWLEDGE_BASE.md` — FAQ patterns
+> **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.