Existing Site

A site with a Code Store repository (one released through the upload tool, in this session or an earlier one): the project is there, and it is continued, not rebuilt. Its repository is the managed project whose id is the site’s app id: the appId in wix.config.json when the folder has one, else POST https://manage.wix.com/_api/companion-apps/v1/companion-apps/get-or-create with body {}, whose companionApp.id it is. Both calls go through ExecuteWixAPI in site scope (siteId set); an account-scoped token is refused (403).

Keep revision.id: it is the release’s expectedHeadRevisionId. The download has no .env.local; setup writes it, installs when node_modules is missing, and scaffolds, deploys and seeds nothing. Then edit, npx astro build, and upload as SKILL.md step 5 says, with that revision. A 404 (NOT_FOUND, GIT_BRANCH_NOT_FOUND) means the site has no project yet: a dropped site has none, its pages live only in the drop. On the plugin route that is the create flow against this site: get-or-create above gives the appId, then in an empty folder node <SKILL_ROOT>/install/setup.mjs --vertical <vertical> --site <siteId> --app <appId>, build, and release through UploadHeadlessWebsiteFiles with the headRevisionId the prepare returns (the drop’s import commit, or none); the release replaces the dropped pages at the same URL and stores the project. The site owns its content: read it first, and seed only what the brief supplies or asks to add. On the CLI route the sections below apply, and the first release creates the repository.

Read the site, then run attach. First, one call tells you what the site is — its name, currency, and the Wix apps installed on it:

The installed apps name the verticals (Wix Stores → storefront, Wix Bookings → bookings, and so on per the Verticals table); the brief picks among them. Then one deterministic call, same shape as setup (SKILL.md step 3):

The same call takes a folder that already holds the site’s config and the CLI’s blank Astro starter with no work of its own (context.mjs says blank-starter: a Wix Dev Machine for a never-released site, or a bare wix create): --site comes from the config, the vertical’s composed template takes the starter’s place, its lockfile with it, and the install and the seed run detached as below. Do not install by hand there; the brand layer is yours while they run.

init/wix create always create a site, so they are not used here. attach does what they do after creating one — the site’s OAuth app, Wix hosting, wix.config.json — against the site given, copies the first vertical’s composed template, deploys the rest, and starts the install detached. With --plan the first vertical’s seed runs with it, detached like setup’s (sync on .seed-exit before release; preexisting[] in the result names what the site already held — nothing is deleted or overwritten). --plan also carries the plan’s capabilities into the deploy. Without it nothing seeds and nothing on the site changes: the content is the site’s own, read live through the deployed data layer. A vertical whose seed only installs an app (members: the Members Area, the profile layer) still needs that seed; attach says so in a note. attached also says whether a frontend is already serving at the site’s address (frontend.serving, with the release date). When it is, a wix release from this project replaces it — the old deployment keeps its own address and production can be pointed back, but the user’s site changes. Tell the user before you release, with the address and the date; if the brief did not ask for a new frontend, ask first and wait. Say it again when you close.

Get the measure of the site before you design. Enough to know what you are building for: what the chosen verticals will render, roughly how much of it, and what it is like — six items in three groups design differently from six hundred. Run the vertical’s reader:

It prints one JSON: whether the vertical’s app is installed, counts, one page of each entity with the fields the pages render, and calls, the requests it made with their documentation URLs. The lists are one page; the counts are the site.

When the brief needs a read the script does not make, it is a build-time call with the site’s token, sent raw as the Authorization header (the account token from the call above does not scope to a site), minted inline in each command — -H "Authorization: $(npx -y @wix/cli@latest token --site <siteId>)" — and never written to a file, not in the project and not in /tmp. The rule above applies in full: not one of these calls comes from memory. Read the request where it is written, then call. Where to read, in this order:

• The reader, templates/<vertical>/seed/read-site.mjs — the reads the pages make, as literal calls with their documentation URLs.
• wix-manage, at .agents/skills/wix-manage/ — REST recipes for managing a site’s business solutions: exact endpoint, method and payload per operation, curl included. Its SKILL.md is the index, by solution; open the recipe for the vertical’s solution.
• wix-docs, at .agents/skills/wix-docs/ — the Wix API reference, reached by search, not by browsing files: the skill folder holds the how-to, not the pages. Open its SKILL.md; it gives one curl to semantic search (POST /mcp-docs-search/v1/docs/search/markdown, natural-language search_term) that returns condensed method docs — endpoint, request example, response shape — and the rule that any dev.wix.com/docs/… URL plus .md is the full page. Progressive: search first, read the full document only when the hit lacks what you need. If what you opened does not have the call, go to the next; do not try a variant, and do not build one from a call you did find: the path and body you send are copied from the output you read or they are not sent.

In a folder that already holds a project (a package.json or index.html, no wix.config.json), attach writes the config into it and deploys for --stack instead of scaffolding; pass the stack resolved in SKILL.md step 1. A frontend that will be hosted elsewhere (Vercel, your own server) runs attach with --hosting self --origin <url>[,<url>]: no Wix hosting is created, and the origins go on the OAuth app’s allow-list so checkout can return to them; add the public origin when it goes live. Then SKILL.md steps 4 and 5 as for any run, with the install marker the only one to wait on.