Skip to content

🦞 igor-claw: guard wix-headless create against orphaning an existing project - #943

Open
ayal wants to merge 1 commit into
mainfrom
igor-claw/wix-headless-existing-project-guard
Open

🦞 igor-claw: guard wix-headless create against orphaning an existing project#943
ayal wants to merge 1 commit into
mainfrom
igor-claw/wix-headless-existing-project-guard

Conversation

@ayal

@ayal ayal commented Aug 10, 2026

Copy link
Copy Markdown
Contributor

Summary

Opened automatically by an AI agent acting on behalf of Ayal (ayalg@wix.com), researching feedback reported here: https://wix.slack.com/archives/C0BDXM5LLE7/p1786351421451019

Root cause: a user following Wix's self-managed "sign up → get a siteId/clientId" quick start, then handing those IDs to an AI agent to "build with an agent," has no supported way to actually use them. wix-headless/SKILL.md's operation resolution (§ "Resolving the operation") only branches on on-disk signals (wix.config.json present → iterate; a brought-in design → connect; otherwise → create) and never inspects the prompt for a pre-existing Wix project id. On an empty directory it always falls to create, which runs npm create @wix/new@latest -- headless — this always provisions a brand-new site, silently ignoring any siteId/clientId the user already has (confirmed: neither init, link, nor bare headless exposes a flag to attach to an existing site — npm create @wix/new@latest -- headless init --help / link --help).

Neither side raises an error — the new project is fully valid on its own — so the user ends up with two disconnected, fully-functional Wix projects and no signal that anything went wrong. It's only diagnosable by comparing wix.config.json / dashboard artifacts between the project they expected and the one the agent actually created.

Fix: add a check before the create fallback in skills/wix-headless/SKILL.md. If the prompt names an existing project (siteId, clientId, a manage.wix.com/dashboard/<id> or Headless Settings URL, or explicit "use my existing site/client ID" language), stop and ask instead of silently provisioning a second project — since there's currently no CLI/skill path to attach to it either way.

This is a skill-behavior fix (not a CLI feature), scoped to preventing the silent-duplicate-project outcome; adding an actual "attach to existing site" capability to npm create @wix/new is a separate, larger product decision left out of scope here.

Test plan

  • Manually walk an agent through a prompt that includes a siteId/clientId on an empty directory and confirm it now stops/asks instead of running CREATE.md
  • Confirm normal create/connect/iterate routing is unaffected when no existing-project id is present in the prompt

…existing project

If a prompt names an existing Wix project (siteId/clientId/dashboard URL)
but CWD is empty, operation resolution fell straight to `create`, which
always provisions a brand-new site via `npm create @wix/new` — there is
no CLI/skill path to attach a local scaffold to a project provisioned
elsewhere (e.g. the self-managed "sign up" quick start, or a
dashboard-created headless client). Neither side raises an error, so the
user ends up with two disconnected, fully-functional projects and no
signal anything went wrong.

Add a check before the create fallback: when the prompt supplies an
existing project id, stop and ask instead of silently provisioning a
second project.
@ayal
ayal requested a review from adamfri August 10, 2026 08:50
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant