wix-headless-fast

Wix Headless Fast

統合を自分で作成するのではなく、出荷済みの検証済みコードを使って Wix Headless サイトを構築できます。 各バーティカルには、型付きデータレイヤー、フック、コンポーネント、ページ、シードスクリプトで構成された統合が組み込まれており、そのまま正しく動作します。実行可能なスタック（Wix 管理の Astro、任意の React プロジェクト）では、コードをデプロイし、エージェントの作業はブランド、レイアウト、コピー、接続に絞られます。実行できないスタック（バンドラーのない静的サイト、別の言語でサーバーサイドレンダリングを行うアプリ）では、同じコードがリファレンスになります。REST 版をブラウザー側にデプロイし、コードに組み込まれたルールをエージェントが移植します。どちらの場合も、決定事項はコードに反映されています。改めて検討し直す必要はありません。

対象範囲。 Wix 管理の Astro に最適化されており、各バーティカルにはソリューションの形が 1 つだけ用意されています。依頼内容と矛盾しない場合は、そのまま使用してください。その形では表現できないことを依頼された場合、またはサイトが完成し、管理や拡張に取り組む段階になった場合は、ここで回避策を探すのではなく、wix-docs と wix-manage を使用してください。

モデル

• リリース済みコードが実装の基準です。 各バーティカルは、スキルのフォルダー内ではなく、スキルのリポジトリにある templates/<vertical>/ に格納されます。node <SKILL_ROOT>/install/templates.mjs を実行すると、すべてのテンプレートが一度に <SKILL_ROOT>/templates/ に取得され（数秒で完了）、パスが表示されます。以下の各スクリプトは、フォルダーがない場合に自動で取得します。フォルダーはプロジェクトとともに残ります（合成済みの project/ スキャフォールドだけはリポジトリから除外されます）。そのため、後のセッションではプロジェクトの構築に使われたバージョンを参照できます。各バーティカルには次のものが含まれます。
  • app/ — フレームワークに依存しないコア（TypeScript）です。シリアライズ可能なプレーン DTO（画像は HTTPS URL に解決され、価格はあらかじめフォーマットされています）を返すデータレイヤー、React フック、ルーティングを持たないヘッドレスコンポーネントを備えています。Astro islands、Vite SPA、Next で動作します。
  • app-astro/ — 薄い Astro オーバーレイです。コア経由でデータを取得して DTO を islands に渡す SSR ページと、オーナーが編集できる商品ページの SEO 設定があらかじめ組み込まれています。
  • seed/ — ビルド時に実行する REST シードスクリプト（プレーンデータのプランを受け取り、作成したコンテンツを返します）と、その仕様を定めた SEED.md です。
  • INSTRUCTIONS.md — バーティカルごとのプレイブックです。ファイル一覧、構築するもの、厳守事項が記載されています。
  • project/ — バーティカルを Wix CLI の空の Astro スキャフォールドに組み込み、ロックファイルを含めたものです。新しいサイト用に wix create がコピーする内容であり、最初のバーティカルは依存関係を解決せずにインストールできます。
• 認証の接点は一つです。 リリース済みコードはすべて src/wix/sdk.ts 経由で Wix を呼び出します。Wix 管理下の Astro では認証情報が暗黙的に利用されるため、クライアントも ID も不要です。それ以外の React 環境では、同じファイルが src/wix/config.ts の公開クライアント ID を使って手動のビジタークライアントを実行します。デプロイ手順で設定されるため、手動での接続設定は不要です。
• データはそのまま使い、表示は自由に作成します。 データレイヤー、フック、カートの UI は接続済みの状態で使います。内部を作り直したり、API ルート経由に変更したり、リクエストの形式を再導出したりしてはいけません。要件に必要な機能が既存の仕組みで表現できない場合は、該当箇所を担当するリリース済みファイルを読み、wix-docs で仕様を確認してください。生成された SDK 型、パッケージファイル、node_modules から仕様を推測してはいけません。通常の呼び出し元権限で実行できる操作は、新しいデータレイヤー関数に追加します。特権を必要とする操作は、検証済みのサーバーエンドポイントに追加します。templates/shared/CUSTOM_OPERATIONS.md を参照してください。表示部分はリリースされていません。バーティカルの INSTRUCTIONS には、リリース済みのフックを使って自分で設計・実装する画面が記載されています。スケルトンには、各画面の仕様が含まれています（ストアフロントの場合は、islands を備えたショップページと PDP ページ、およびホームページです）。
• Wix API について、トレーニングデータや記憶をもとに作業してはいけません。 URL、パス、バージョン、ヘッダー、フィールド名、フィルターキー、ボディのいずれも例外ではありません。フロントエンド、シード、サイトのビルド時読み取りを問わず、作成または実行するすべての Wix 呼び出しは、ここにインストールされた公式 Wix スキル、それらが最初にデプロイしたコード、またはそれらで呼び出しが扱われていない場合は wix-docs を通じた公式 Wix ドキュメントに基づいていなければなりません。まずそこで調べてから呼び出しを作成してください。リクエストごとに、実行前に確認すること： パスとボディが、今回のセッションで実行したファイル読み取りまたはドキュメント検索の出力にそのまま表示されており、その出力からコピーしていること。これ以外はすべて記憶頼りです。呼び出しの前に出力が途切れているファイル、以前読んだと記憶しているソース、確認できた呼び出しの一部を変更して作った呼び出しも該当します。推測した呼び出しが 400 エラーや空の結果を返すのは、答えに近づくための手順ではありません。このルールが防ごうとしている失敗です。次の候補を試すのも、やはり推測です。確認条件を満たさずに失敗した呼び出しが空またはエラーを返しても、わかるのは呼び出しについてのことだけであり、サイトについては何もわかりません。呼び出しが確認できるまでは、エラーを見える状態にしてください。2>/dev/null や | echo を使ってはいけません。リリース済みコードは実際のサイトでテストされています。見た目が似たボディでは何も返らず、API が理由を示すこともほとんどありません。
• モックは禁止です。エラーは明示し、Wix 経由で購入します。 実データを使うか、正直な空状態を表示します。エラーを握りつぶさず、ユーザーに表示します。チェックアウトと購入は、必ず Wix のリダイレクトセッションを通じて行います。
• オプション機能はプランからデプロイします。 バーティカルでは、機密性の高いコードをコピーせずに、共有機能を利用できます。通常のファイルアップロードには、プランに名前付きの capabilities.mediaUpload.policies エントリーを追加します。Fast は、クライアントヘルパー、Astro エンドポイント、依存関係、生成されるポリシーモジュールを一度に提供します。選択する前に templates/shared/CUSTOM_OPERATIONS.md を読んでください。エージェントはヘルパーを商品 UI に接続します。エンドポイントを作成したり、適用範囲を広げたりすることはありません。サイト全体の検索（ヘッダーの候補付き検索ボックスや、デプロイ済みバーティカルの商品、サービス、投稿、イベントを検索する /search?q= ページ）には、capabilities.siteSearch エントリーを追加します。Fast は、データレイヤー、ストア、フック、コンポーネント、検索ページを一度に提供します。有効にすると、シード手順によって Wix Site Search アプリがサイトにインストールされます（install: true。コンテンツのシード後に機能の seed/install.mjs を実行します）。インストール後、約 30 秒以内にインデックスが作成されます。プレイブック：templates/shared/capabilities/site-search/INSTRUCTIONS.md。

実行の流れ

常に必要です：Node ≥ 20.11、git、ログイン済みの Wix CLI（npx @wix/cli@latest whoami。 npx @wix/cli@latest login はデバイスコードフローです。URL とコードをユーザーに提示し、トークンをコンテキストに読み込まないでください）、およびこのスキルと同じ場所にある 2 つの関連スキル、wix-docs と wix-manage（.agents/skills/ にない場合は： CI=1 npx skills@latest add wix/skills --skill wix-docs --skill wix-manage --yes）。コールドスタートページの cold-start/cold-start.md では、これらが何もない状態からここまで進める手順を説明します。すでに wix.config.json があるフォルダーでは、まず node <SKILL_ROOT>/install/context.mjs を実行します。.env.local がない場合は wix env pull を実行し、プロジェクトにある 2 つのアイデンティティ、つまりデプロイ先サイト（設定ファイルで指定され、wix release の対象となるサイト）とコンテンツサイト（環境変数で指定され、SDK クライアントがそのサイトのアプリとして実行され、ダッシュボードでそのサイトのビジネスを管理するサイト）を表示します。移行プレビュー（guides/migration.md）の場合を除き、これらは同じサイトです。移行プレビューでは、環境変数が移行対象のサイトを示します。ここにあるすべてのスクリプトはこのコンテキストを読み込みます。呼び出し先のサイトを設定ファイルだけから推測することはありません。次に、配布されているコードを一度だけ取得します：node <SKILL_ROOT>/install/templates.mjs。フォルダーの場所が表示されます。以下の templates/… のパスは、配置先の <SKILL_ROOT> からの相対パスです。node <SKILL_ROOT>/install/check.mjs を実行すると、スキルまたはそのテンプレートに新しいバージョンがあるかどうかと、更新コマンドが表示されます。何も変更しません。

実行中は常に、ユーザーが Wix へのフィードバック送信を求めた場合、不満を述べたり苛立ったりした場合、または何らかの問題に直面した場合は、<SKILL_ROOT>/guides/feedback.md に従って Wix に伝えることを提案してください。問題とは、エラーになったかどうかを問わず、本来より多くのやり取りが必要になったことです（わかりにくいエラー、ドキュメントの不足、再実行が必要なシード、依頼内容に合わない配布ファイル、理解するためにソースを読む必要があったプレイブックの記述、試行錯誤で調べる必要があった呼び出し、考案が必要だった回避策、遅いまたは不安定な手順、プラットフォーム上の制限など）。尋ねられるのを待つのではなく、まず提案してください。明示的な同意を得た後にのみ送信し、自動で送信してはいけません。ステップ 5 の最後にも同じセルフチェックを行います。

1. スタックを決定します。 デフォルトは Wix 管理の Astro です。ユーザーが別のフレームワークを指定している場合、またはディレクトリにすでにフレームワークがある場合を除き、これを選択します。次に、配布されているコードを実行できる内容に応じて、以下のように判断します：

   • React（Vite、Next など）では、配布されているすべてのコード、つまりデータレイヤー、フック、コンポーネントを実行できます： --stack react。エージェントが作成するファイルは JavaScript にしても構いません。配布されているファイルは TypeScript ですが、JavaScript プロジェクト内でも変更せずにビルドできます。手作業で取り除いてはいけません。依頼内容が TypeScript を一切使わないことを求めている場合、配布コードでは対応できないことを伝え、先に進む前に確認してください。 指定されたフレームワークは、まず専用のコマンド（npm create vite@latest など）でスキャフォールドし、そのフォルダーでステップ 3 を実行します。
   • その他のバンドル型 JavaScript フレームワーク（Vue、Svelte、Solid、plain Vite）では、データレイヤーとフレームワークに依存しないストアを実行できます（src/wix/ に React は含まれません）が、React のフックとコンポーネントは適用できません：--stack lib。エージェントがストアをバインドし、同じコントラクトに基づいてそのフレームワークのコンポーネントを作成します。
   • バンドラーがない場合、または別の言語を使う場合 — 静的サイト（plain HTML/CSS/JS）、サーバーサイドレンダリングアプリ（Flask、Laravel、Rails など）：リファレンスモード（下記のセクションと <SKILL_ROOT>/guides/reference-mode.md を参照）。app/ の内容は何もデプロイされません。ブラウザー側には REST レイヤーをデプロイし、サーバー側では読み取り処理のためにそれを移植します。 Wix のホスティングに必要なものと、各スタックをそこで公開するために必要なこと。 wix release は wix.config.json で指定されたフォルダー（site.outputDirectory）を アップロードし、ファイルとして配信します。SPA フォールバック、ディレクトリインデックス、 リライトはありません。/ と実在するファイルは解決されますが、クライアント側のクリーンな ルートを直接読み込んだり共有したりすると 404 になります。サーバーコードは outputDirectory: { client, server } として宣言された Cloudflare Workers ビルドとしてのみ 実行されます。
   • Managed Astro は Wix CLI がスキャフォールディングするスタックです。Wix Astro 統合 （@wix/astro、アンビエント認証）、ホスティングアダプター（@wix/astro-wix-hosting-adapter、 Workers ビルド）、同梱コンポーネント用の React 18 と @astrojs/react を使用し、 astro.config.mjs では integrations: [wix(), react()]、adapter: wixHostingAdapter()、 output: "server"、security: { checkOrigin: false }、static.wixstatic.com を含む image.domains を設定します。CLI を使わずに作成した Astro プロジェクトには、これらが 何もありません。デプロイ前に追加すれば、サイトのすべてのルートが配信されます。この統合は Astro 5 に対応しています。別のメジャーバージョンを使っているプロジェクトは、まず 5 に 固定するか、React ホストとして接続します。
   • React やその他のバンドラーでは、独自のビルドをファイルとして公開します。そのため、 ルートはハッシュルートにするか、ファイル名でリンクされたルートごとの HTML ファイルを 出力します。これは最初のルートを書く前に決めてください。Wix にリターン先として渡す URL は、 ホストが配信するものにする必要があります。/ から移動して確認するのではなく、 ディープ URL を直接読み込んで確認してください。
   • ビルドがサーバーになるフレームワーク（Next、Nuxt、Remix、SvelteKit など）は、 静的エクスポート（ファイル。上記のルールが適用されます）か、 outputDirectory: { client, server } を通じた Workers ビルドとしてのみ公開します。 それ以外の場合はセルフホストとし、チェックアウトから戻れるように、OAuth アプリの許可 ドメインにそのドメインを追加します。
   • 静的サイト（ビルドなし）の場合は、ページのあるフォルダーを outputDirectory に指定します。 ルートは、ページとクエリ文字列のスラッグ（リファレンスモード）で構成されます。

2. シード計画。 ブリーフに何らかの形式でコンテンツが含まれている場合（CSV、JSON、 スプレッドシート、プロンプト内のリスト、PDF の価格表、写真フォルダーとテキストファイル、 現在のカタログへのリンク、その他コンテンツを特定できるもの）は、それが計画です。 templates/shared/SUPPLIED-CONTENT.md と縦割りの SEED.md（「Supplied content」）に 従って plan.json にマッピングします。すべてのエントリ、名前、価格を原文どおりに使い、 画像は指定されたものだけを使います。何も提供されていない場合に限り、ブリーフだけをもとに 計画を作成します（この作業では縦割りの SEED.md のみを読みます。ブリーフだけで判断できる ためです。INSTRUCTIONS.md は、必要になるステップ 4 まで参照しないでください）。 既存サイトには計画がありません。ブリーフにサイトの ID が記載されている場合、サイトには すでにコンテンツがあるため、シードは行わず、フロントエンドから既存のコンテンツを読み込みます （ステップ 3 の接続パス）。

3. プロジェクトをそのフォルダー内に設定する — 空のフォルダーでも、すでにディスク上に プロジェクトがある場合でも同じ、決定論的な 1 回の呼び出しです。何を行うかはフォルダーで 決まります。

   node <SKILL_ROOT>/install/setup.mjs --vertical <vertical>[,<vertical>…] [--plan plan.json] [--business-name "<Brand>"]
   

   この 1 回の呼び出しで、ブリーフに必要な縦割りをすべて指定してください（会員アカウント付きの ストアは storefront,members です）。最初の縦割りのテンプレートでプロジェクトを スキャフォールディングし、そのシードを --plan から実行します。残りの縦割りも同じ呼び出しで デプロイされるため、インストールは 1 回で済みます。インストール開始後に縦割りを追加すると、 2 回目のインストールが必要になります。ブリーフにコンテンツが含まれている場合は、残りの縦割りの シードをその後、それぞれ専用の計画で実行します（members のシードは Members Area アプリを インストールするもので、計画は不要です）。

   • 空（または CSV や概要書など、ばらばらのファイルのみ）→ 作成：この分野の構成済みテンプレートを使って wix create を実行します。--business-name でサイト名を指定します。
   • wix.config.json がないプロジェクト（package.json、またはルートに index.html があるプロジェクト。Astro、Vite、Next、プレーンな HTML など）→ 接続：既存のフォルダーで init を実行すると、新しいサイトにフォルダーがリンクされます（サイト名はフォルダー名になります）。その後、同梱のコードがプロジェクトにそのままデプロイされます。手順 1 で特定したスタックを --stack で渡し、呼び出しの前または直後に、Wix ホスティングでそのスタックに必要な状態にプロジェクトを整えてください。--stack static の場合、セットアップにより site/ が wix release のアップロード先となり、REST レイヤーが site/js/wix/ にデプロイされます。ページ、スタイル、アセットは自分で移動してください（guides/reference-mode.md）。
   • プロジェクトと wix.config.json がある → 拒否されます。このフォルダーは、CLI が作成したもの、手書きしたもの、このスキルが構築したものを問わず、すでにフロントエンドを含む Wix プロジェクトです。プロジェクトのルートから 3 つのコマンドを実行すれば、セットアップで行うすべての作業を完了できます。deploy.mjs <vertical…> --stack <stack> でこのスキルのコードまたはソリューションを追加します（クライアント ID は .env.local から取得し、そこにない場合は設定を使います）。次に npm install を 1 回実行し、コンテンツを作成する場合はシードモジュールを実行します。このスキルが構築したプロジェクトで新しいソリューションを追加する場合は、最初のコマンドだけで十分です。構築済みの内容を変更する場合は、ファイルを編集してリリースします。
   • wix.config.json があり、プロジェクトがなく、.env.local に移行が宣言されている（ヘッドレス化のために Wix からダウンロードしたプロジェクト。設定にはデプロイ先となるサイト、環境変数には移行対象のサイトが指定されています）→ 移行：セットアップは、設定の周囲にこの分野の構成済みテンプレートをコピーし、移行対象サイトのアプリをクライアントとしてデプロイして、インストールを開始します。シードは行いません。ready_for_brand_layer は mode: "migrate"、親サイトを siteId、子サイトを deploySiteId として示します。ルールについては guides/migration.md を参照してください。
   • wix.config.json があり、プロジェクトがなく、移行でもない（空のフォルダーで init を実行したときの状態）→ サイトは存在しますが、まだフロントエンドがありません。以下の attach.mjs を使います。設定からサイトを取得し、そのホスティングを再利用して、プロジェクトのひな形を作成してデプロイします。シードは行いません。コンテンツはサイトが管理します。
   • 概要書にサイト ID が記載されている → このコマンドは使いません。<SKILL_ROOT>/guides/existing-site.md を読み、その手順に従ってください（サイトを読み取ってから attach.mjs を実行します。指定されたサイトに対してセットアップと同じ処理を行います。セルフホスティングと、すでにディスク上にあるプロジェクトについても説明しています）。

   --vertical は必須で、デプロイする同梱コードと実行するシードの両方を選択します。Verticals の表から特定した分野を使ってください。シードを行うかどうかは --plan で決まります。プランがある場合は手順 2 のプランを渡してください。すでにコンテンツがあるサイトにはシードを行いません。シードは追加のみで、サイトにあるコンテンツを削除したり上書きしたりすることはありません。クリーンアップが必要と思われる場合は、確認してください。ready_for_brand_layer イベントは mode（create または connect）、スタック、そのスタックに対応するリリース方法を含む next を示します。

   セットアップは --skip-git を指定してプロジェクトのひな形を作成します。独自の手順を組み立て、バージョン管理はユーザーまたは親リポジトリに委ねるため、通常のひな形作成で行われる Git リポジトリと初回コミットの作成は行いません（プロジェクトがリポジトリ内に作成された場合、これらがネストしたリポジトリの gitlink になってしまうためです）。

   プロジェクトは現在のディレクトリ、つまり作業場所としてエントリから指定された、インストール済みのスキルがすでに置かれているフォルダーに作成されます。そのため、プロジェクトは自己完結型となり、後でそのフォルダーを開いたセッションから必要なものをすべて利用できます。ひな形が書き込むファイルがすでにフォルダーにある場合は、作成を拒否します。現在のフォルダーをそのままにする必要がある場合は、--subfolder を指定すると、代わりにビジネス名の新しいフォルダーに作成できます。その場合、スキルはプロジェクトの 1 つ上の階層に置かれます。 1 行につき 1 つの JSON イベントを出力し、約 35 秒で戻ります。縦型の合成テンプレートからプロジェクトをスキャフォールドします（wix create がコピーするため、コードとロックファイルはスキャフォールドに含まれます）。フォルダーにまだないものをデプロイします（コードがインポートするすべての依存関係を package.json に追加します）。その後、切り離されたバックグラウンドジョブを 2 つ開始します。依存関係のインストール（npm ci --ignore-scripts || npm install --ignore-scripts）とシードです。ログと完了マーカーはイベントに含まれます。最後の ready_for_brand_layer イベントには、プロジェクトディレクトリ、siteId、用意済みのダッシュボードリンク、両方のマーカーが含まれます。重要なイベントを中継してください。error イベントが発生した場合は、以下の手動手順でそのステップだけを復旧してから続行してください。

   **1 つのステップを復旧する場合、または後からソリューションを追加する場合：**各処理はプロジェクトのルートから個別に実行できます。node <SKILL_ROOT>/install/deploy.mjs <vertical…> --stack <stack>（クライアント ID は wix.config.json から読み取られます）、依存関係のインストールを 1 回だけ実行します（npm ci --ignore-scripts || npm install --ignore-scripts。npm install を同時に 2 回実行しないでください。1 つの node_modules 内で 2 つの npm が競合し、互いの作業をやり直します。セットアップですでに 1 つが開始されているため、そのマーカーを待ってください）。縦型のシードモジュールについては、その seed/SEED.md に従ってください。 既存プロジェクトのコード変更は、リリース（ステップ 5）され、ライブ URL に反映された時点で完了です。開発サーバーやローカルビルドに表示された時点ではありません。管理上の変更（サイトに対するレシピ）はリリース不要です。フロントエンドがライブで読み込みます。

4. インストールが完了するまでの間に、プレゼンテーションを設計して構築します — ready_for_brand_layer イベントで指定されたプロジェクトディレクトリで、該当する業種の INSTRUCTIONS.md に従って作業します。@theme トークンを設定し、クロームにブランドを反映して、提供されたフックを使い、業種固有のクリエイティブなサーフェスを自分で実装します（ストアフロントの場合は、商品カードとグリッド、ショップサーフェス、PDP サーフェス、ホームページ）。参考コンポーネントをコピーするのではなく、ブリーフに合うデザインにしてください。INSTRUCTIONS と共通の基準文書 — templates/shared/DESIGN.md と templates/shared/CONTENT.md — を今（それ以前ではなく）読んでください。これらの仕様が重要になるのは、この段階からです。フックと DTO の仕様はそこにインラインで記載されているため、提供されたファイル自体は開かないでください。サーフェスの作成に使うメッセージは、できるだけ少なくしてください — 1つのメッセージで複数の Write 呼び出しをまとめてください（コンポーネントはそれぞれ独立したファイルです）。ファイルごとに往復する必要はありません。 ブリーフに、提供されたコードでは対応できないコア操作が必要な場合は、実装する前に templates/shared/CUSTOM_OPERATIONS.md を読んでください。文書化された方法を1つ選んで実装し、SDK の内部をリバースエンジニアリングしないでください。

5. 2つのバックグラウンドジョブが両方とも完了したら — インストールのマーカー（node_modules/.package-lock.json）とシードのマーカー（.seed-exit）が両方存在する状態になったら、シードが成功したことを確認してください（.seed-exit の内容が 0 であることを確認し、seed-result.json に記載された作成件数をサマリーに使います。0以外の場合は seed.log を読み、シードモジュールを手動で再実行してください）。この2つのシードファイルは、セットアップでシードを開始した場合にのみ存在します（attach ではシードは実行されず、待つのはインストールのマーカーのみです）。seed-store.mjs を自分で実行した場合（connect／iterate 実行、reference モード）は、待つべきマーカーはありません。プロセスの終了コードが結果で、標準出力が JSON です。ファイルではなくプロセスを待ってください（フォアグラウンドで実行するか、PID に対して wait を実行します）。次に、（managed では）一度だけビルドしてリリースしてください。スタックに応じた手順は ready_for_brand_layer イベントの next に記載されています。Astro の場合は npx @wix/cli@latest build の後に npx @wix/cli@latest release を実行します。React または別のバンドラーの場合は、プロジェクト独自のビルドを実行した後、wix.config.json に記載されたビルドフォルダーを npx @wix/cli@latest release でリリースします（ディープ URL が直接 200 を返す必要があります。手順1を参照）。静的サイトの場合は release のみを実行します。インストールに失敗した場合は、もう一度実行してからビルドしてください。途中でビルドとリリースを行わないでください。バックエンドのコンテンツは実行時に取得されるため、再リリースしてもシード済みデータが「更新」されることはありません。サイトがリリースされた時点でのみ、実行は完了です。最後にライブ URL とダッシュボードへのリンク https://manage.wix.com/dashboard/<siteId> を伝えてください（<siteId> は ready_for_brand_layer イベントの siteId です。移行プレビューの場合、ダッシュボードは移行先サイトのもので、リリース URL はプレビューの URL です。元のサイトは変更されず、ユーザーが承認した後に Wix CLI で移行を完了することが次の手順になります。この3点すべてを伝えてください）。ライブ URL は wix release の出力からそのままコピーしてください。記憶を頼りに打ち直してはいけません（サブドメインを間違えると、ユーザーに 404 を渡すことになります）。完了を伝える前に、セッション全体を対象にフィードバックのセルフチェックを行ってください（guides/feedback.md）。想定以上にやり取りが増えたことや、表面化せずに解決したことも含め、問題が起きた箇所はすべて改善の手がかりです。該当するものがあれば、リンクを渡す際に報告してよいか尋ね、明示的な承諾を得てから送信してください。

リファレンスモード — 静的サイト、または別の言語によるサーバーレンダリングアプリ

提供されているデータレイヤーは、app/ を実行できないスタック向けに、fetch を介したREST レイヤーとしても用意されています。対象となるのは、バンドラーのない静的サイトや、別の言語（Flask、Laravel、Rails）によるサーバーレンダリングアプリです。REST レイヤーはブラウザー側にデプロイし、サーバー側では読み取り処理を移植します。ステップ 1 でこれらのスタックを選んだ場合は、ステップ 3 の前に <SKILL_ROOT>/guides/reference-mode.md を読んでください。ここには、その仕組み（site/ の構成とセットアップの役割、ブラウザーとサーバーのどちらで何が実行されるか、セルフホスト環境のオリジンに対する OAuth の許可リスト、事前レンダリング済みの出力）と、この方法での作業を締めくくる方法が記載されています。公開サイトには、引き続きマネージド Astro を使うほうが適しています。締めくくる際にそのように伝えてください。

業種

候補一覧です。依頼内容を最初の列と照合してください。Wix 製品やここに記載のない機能が挙げられている場合、当てはまる行が複数ある場合、またはこのスキルが提供していないもの（ミーティング、ギフトカード、ロイヤルティ、グループ）に関する依頼に思える場合は、<SKILL_ROOT>/guides/capabilities.md を確認してください。Wix 製品ごとの内容、対応範囲、ここにあるどの業種が提供するか、提供していないものがすべて記載されています。

ユーザーの要望…	業種	プレイブック
オンラインストア：商品、カテゴリー、バリエーション、カート、チェックアウト	storefront	templates/storefront/INSTRUCTIONS.md
予約／クラス：サービス、時間枠、スタッフ、予約、チェックアウト	bookings	templates/bookings/INSTRUCTIONS.md
レンタル：時間単位または日単位で貸し出す部屋、車両、機材、顧客が選択する利用期間、チェックアウト	rentals	templates/rentals/INSTRUCTIONS.md
ブログ：投稿フィード、カテゴリー／タグ、リッチコンテンツの投稿ページ	blog	templates/blog/INSTRUCTIONS.md
構造化コンテンツコレクション（ディレクトリ、レシピ、掲載情報）と、スキーマに応じて設計されたページ	cms	templates/cms/INSTRUCTIONS.md
訪問者が入力できるあらゆるフォーム：問い合わせ、登録、申請、アンケート — 公開中のスキーマからレンダリング	forms	templates/forms/INSTRUCTIONS.md
イベント：一覧、イベントページ、無料の参加登録、ホスト型チェックアウトによるチケット販売	events	templates/events/INSTRUCTIONS.md
メンバーアカウント：アプリ内のカスタムログイン／新規登録、アクセス制限付きページ、アカウントページ	members	templates/members/INSTRUCTIONS.md
ポートフォリオ／ショーケース：プロジェクトのコレクション、メディアギャラリー付きのプロジェクトページ	portfolio	templates/portfolio/INSTRUCTIONS.md
メンバーシップ／サブスクリプションプラン：料金ページ、プラン詳細、ホスト型の購入	pricing-plans	templates/pricing-plans/INSTRUCTIONS.md
レストラン：写真付きメニュー、オンライン注文、テーブル予約	restaurants	templates/restaurants/INSTRUCTIONS.md
FAQ：カテゴリー別の質問、検索、展開可能な回答、各質問へのリンク	faq	templates/faq/INSTRUCTIONS.md
寄付：キャンペーンページ、目標の進捗表示、ホスト型チェックアウトによる単発および継続的な寄付	donations	templates/donations/INSTRUCTIONS.md

業種は組み合わせられます。複数の業種にまたがる依頼（ブログを併設したレストラン、メンバーアカウント付きのストアなど）では、セットアップ呼び出しでそれらすべてを指定します（--vertical restaurants,blog）。そうすることで、1 回のインストールですべてに対応できます。各業種のシードは、それぞれのプランに従って実行されます。すでに構築済みのプロジェクトでは、プロジェクトのルートから node <SKILL_ROOT>/install/deploy.mjs <vertical…> を実行して業種を追加し、その後 npm install を 1 回実行してから、その業種のシードを実行します。提供されている業種に該当しない依頼には、提供コードがありません。その旨を 1 行で伝えたうえで、wix-docs を使って Wix API リファレンスから構築します（検索してからメソッドページを確認）。他のすべての呼び出しと同じルールに従い、同じプロジェクトとスタック上で、該当する提供済み業種がある場合はそれを出発点にしてください（どの業種かは guides/capabilities.md に記載されています）。