/experience-ui-bundle-site-generate

name: experience-ui-bundle-site-generate
description: "MUST activate when the project contains a uiBundles/*/src/ directory and the task involves creating or configuring site infrastructure. Use this skill when creating or configuring a Salesforce Digital Experience Site for hosting a UI bundle. Activate when files matching digitalExperiences/, networks/, customSite/, or DigitalExperienceBundle exist and need modification, or when the user wants to publish, host, or configure guest access for their app. Also use this skill to add multi-language, multi-locale, internationalization, or translation support to such a site by declaring a default locale and additional supported languages via the sfdc_cms__languageSettings content type. DO NOT TRIGGER for LWR (non-React) sites; use experience-lwr-site-generate instead."
metadata:
  version: "1.3"
  domains: ["Experience"]
  minApiVersion: "65.0"
  relatedSkills:
    - experience-lwr-site-generate
  cliTools:
    - tool: ["awk"]
      semver: ">=1.0"
    - tool: ["jq"]
      semver: ">=1.6.0"
    - tool: ["sf"]
      semver: ">=2.0.0"

Digital Experience Site for React UI Bundles

Create and configure Digital Experience Sites that host React UI bundles on Salesforce. This skill generates the minimum necessary site infrastructure — Network, CustomSite, DigitalExperienceConfig, DigitalExperienceBundle, and the `sfdc_cms__site` content type — so a React app can be served from Salesforce.

React sites differ from standard LWR sites: they don't need routes, views, theme layouts, or branding sets. The site acts as a thin container (`appContainer: true`) that delegates rendering to the React UI bundle referenced by `appSpace`.

Required Properties

Resolve all five properties before generating any metadata. Each has a fallback chain — work through each option in order until a value is found.

| Property | Format | How to Resolve | |----------|--------|----------------| | **siteName** | `UpperCamelCase` (e.g., `MyCommunity`) | Ask user or derive from context | | **siteUrlPathPrefix** | `All lowercase` (e.g., `mycommunity`) | User-provided, or convert siteName to all lowercase with alphanumeric characters only | | **appNamespace** | String | `namespace` in `sfdx-project.json` → `sf data query -q "SELECT NamespacePrefix FROM Organization" --target-org ${usernameOrAlias}` → default `c` | | **appDevName** | String | `UIBundle` metadata in the project → `sf data query -q "SELECT DeveloperName FROM UIBundle" --target-org ${usernameOrAlias}` → default to siteName | | **enableGuestAccess** | Boolean | Ask user whether unauthenticated guest users can access site APIs → default `false` |

The `appNamespace` and `appDevName` properties record the intended UIBundle binding for a **future follow-up update**; they are **not** substituted into `appSpace` at initial site creation. `appSpace` in the `sfdc_cms__site` `content.json` is always `""` at initial creation — see [configure-metadata-digital-experience.md](references/configure-metadata-digital-experience.md) for the reason and the follow-up flow.

Language Properties

The skill always emits `sfdc_cms__languageSettings` alongside `sfdc_cms__site`. Resolve `defaultLocale` for every site (defaults to `en_US`); resolve `languages` only when the user requests additional languages beyond the default.

| Property | Format | How to Resolve | |----------|--------|----------------| | **defaultLocale** | `xx` or `xx_YY` (e.g., `en`, `en_US`) | Ask user → default `en_US` | | **languages** | List of `{label, locale}` | Only when the user asks for multiple languages, locales, internationalization, or translation support: ask for the additional languages the site supports. When not requested, the languageSettings content declares only the resolved `defaultLocale` as a single-language entry. |

The content-item folder name (`languages`), `title` (`LanguageContent`), and `urlName` (`languagecontent`) are fixed Experience Builder auto-defaults — they are **not** user-authored. See [configure-metadata-language-settings.md](references/configure-metadata-language-settings.md).

Pre-flight: Target Org Release (Multi-Language Only)

The `sfdc_cms__languageSettings` content type accepts multi-language declarations only on Salesforce Release 264 (API **v68.0** or higher). Sites reduced to a single-locale `en_US` declaration work on any org and do not need this check.

When the user requests multiple languages, verify the target org's maximum supported API version **before writing any metadata**. `sf api request rest` hits `/services/data/` on the instance directly and handles authentication at the transport layer, so the org's true ceiling is returned without any access token entering this script's context.

MAX_API=$(sf api request rest "/services/data/" --target-org "${usernameOrAlias}" \
          | jq -r '[.[].version | tonumber] | max')

awk -v v="$MAX_API" 'BEGIN{ exit !(v+0 >= 68.0) }' \
  || { echo "ERROR: multi-language site containers require Salesforce Release 264 (API v68.0+). Target org's maximum supported API version is v${MAX_API}. Retarget to a Release 264+ org, or reduce the site to a single-locale (en_US) declaration." >&2; exit 1; }

If the check fails, do not write metadata. Report the version mismatch to the user and stop.

Generation Workflow

Step 1: Resolve All Required Properties

Determine values for all five required properties and the `defaultLocale` language property before constructing anything. Use the resolution strategies in the tables above, falling through each option until a value is found. Resolve the `languages` property only when the user has requested multiple languages — and when they do, run the [Pre-flight](#pre-flight-target-org-release-multi-language-only) check above before continuing to Step 2.

Step 2: Create the Project Structure

Use available Salesforce metadata schema and field context for `Network`, `CustomSite`, `DigitalExperienceConfig`, and `Digit