@salesforce/afv-skills 1.1.0 → 1.3.0

package/skills/generating-experience-lwr-site/docs/configure-content-route.md

@@ -0,0 +1,232 @@
+# Content Type: sfdc_cms__route
+
+**Use when** user explicitly requests creating a new page. Not for editing existing routes.
+
+## Table of Contents
+
+- Generation Guidelines
+- Core Principles
+- Directory Structure (All Routes)
+- _meta.json Structure
+- Part A: CUSTOM PAGES
+- Part B: OBJECT PAGES
+
+## Generation Guidelines
+
+**PAGE TYPES**: These guidelines supports two types of pages:
+
+1. **Custom Pages** - Single route pages for custom content (e.g., About Us). **Note**: Standard pages (e.g., Home, Login) come pre-built with the site and cannot be created.
+2. **Object Pages** - Requires 3 routes: Detail, List, and Related List (e.g., Account, custom objects)
+
+## Core Principles
+
+1. **Purpose**: Generate new routes under the `sfdc_cms__route` directory.
+2. **View Association**: Each route must reference a corresponding view in the `sfdc_cms__view` directory.
+3. **CRITICAL**: The `routeType` in the route's `content.json` MUST exactly match the `viewType` in the corresponding view's `content.json`. This is a required validation rule.
+
+## Directory Structure (All Routes)
+
+1. **Location**: `digitalExperiences/site/[SITE_NAME]/sfdc_cms__route/[ROUTE_NAME]/`
+2. **Required Files**:
+  - `_meta.json` - Metadata file defining the API name and type
+  - `content.json` - Content file defining the configuration and layout
+3. **Naming Convention**: Underscore-separated names with "__c" suffix (About_Us__c, Account_Detail__c)
+
+## _meta.json Structure (All Routes)
+
+The `_meta.json` file must contain:
+
+```json
+{
+  "apiName": "[ROUTE_NAME]",
+  "type": "sfdc_cms__route",
+  "path": "routes"
+}
+```
+
+**Rules**:
+
+- `apiName`: Must match the route directory name exactly
+- `type`: Always `"sfdc_cms__route"`
+- `path`: Always `"routes"`
+
+## Part A: CUSTOM PAGES
+
+Use this section when creating single-route custom content pages.
+
+### A.1. content.json Structure
+
+The `content.json` file must contain:
+
+```json
+{
+  "type": "sfdc_cms__route",
+  "title": "[DISPLAY_TITLE]",
+  "contentBody": {},
+  "urlName": "[URL_NAME]"
+}
+```
+
+**Field Definitions**:
+
+- `type`: Always `"sfdc_cms__route"`
+- `title`: Human-readable display title (e.g., About Us)
+- `contentBody`: Include all `required` properties from `schemaDefinition`. Use `examplesOfContentType` for reference.
+- `urlName`: URL identifier (lowercase with hyphens, e.g., `about-us`)
+
+### A.2. Naming Conventions
+
+For a page named "About Us":
+
+| Field | Format | Example |
+|-------|--------|--------|
+| Directory Name | Underscore-separated + "__c" | `About_Us__c` |
+| apiName | Same as directory | `About_Us__c` |
+| title | Human-readable | `About Us` |
+| contentBody.activeViewId | Underscore-separated (no __c) | `About_Us` |
+| contentBody.routeType | "custom-" + lowercase hyphens | `custom-about-us` |
+| contentBody.urlPrefix | Lowercase hyphens | `about-us` |
+| urlName | Lowercase hyphens | `about-us` |
+
+**CRITICAL**: `routeType` MUST exactly match `viewType` in the corresponding view's `content.json`.
+
+### A.3. View Dependency
+
+- Before creating a route, ensure the corresponding view exists in `sfdc_cms__view/[view_name]/`
+- If the view doesn't exist, create it first following the view creation guidelines
+
+### A.4. Generation Checklist
+
+- [ ] Route directory and files created (see Directory Structure)
+- [ ] `_meta.json` follows structure (see _meta.json Structure)
+- [ ] `content.json` follows structure (see A.1)
+- [ ] All naming conventions applied (see A.2)
+- [ ] Corresponding view exists (see A.3)
+
+## Part B: OBJECT PAGES
+
+Use this section when creating object pages that require Detail, List, and Related List routes.
+
+### B.1. Overview
+
+Object pages require **three routes** to be created together:
+
+1. **Detail Route** - Displays a single record
+2. **List Route** - Displays a list of records
+3. **Related List Route** - Displays related records for a parent record
+
+**OBJECT TYPES**: Two types of Salesforce objects use different `routeType` formats:
+
+| Object Type | routeType Format | Example |
+|-------------|------------------|----------|
+| **Standard** (Account, Contact) | `[type]-[keyPrefix]` | `detail-001`, `list-001`, `relatedlist-001` |
+| **Custom** (Test_Object__c) | `[type]-[ObjectApiName]` | `detail-Test_Object__c`, `list-Test_Object__c` |
+
+- **keyPrefix**: 3-character identifier unique to each standard object (Account=001, Contact=003)
+- **ObjectApiName**: Custom object API name including the "__c" suffix
+
+Obtain object information from the `objectList` MCP output:
+
+```json
+[
+  ["Label", "ApiName", "KeyPrefix", "IsCustom"]
+]
+```
+
+### B.2. Required Routes
+
+Create three directories under `sfdc_cms__route/`:
+
+- `[OBJECT_NAME]_Detail__c/`
+- `[OBJECT_NAME]_List__c/`
+- `[OBJECT_NAME]_Related_List__c/`
+
+### B.3. content.json Structure
+
+Each route's `content.json` file must contain:
+
+```json
+{
+  "type": "sfdc_cms__route",
+  "title": "[OBJECT_NAME] [TYPE]",
+  "contentBody": {},
+  "urlName": "[object_name_lowercase]-[type]"
+}
+```
+
+**Field Definitions**:
+
+- `type`: Always `"sfdc_cms__route"`
+- `title`: Human-readable title (Account Detail, Account List)
+- `contentBody`: Include all `required` properties from `schemaDefinition`. Use `examplesOfContentType` for reference.
+- `contentBody.urlPrefix`: **CRITICAL**: Must be identical across all three object page views (Detail, List, and Related List) for the same object.
+- `urlName`: Lowercase with hyphens (account-detail, account-list)
+
+### B.4. Object Page Examples
+
+Use `[ObjectName]` as the object name (Account, Test_Object) and `[IDENTIFIER]` as:
+
+- **Standard objects**: keyPrefix (001 for Account, 003 for Contact)
+- **Custom objects**: ObjectApiName (Test_Object__c)
+
+#### content.json Template
+
+```json
+{
+  "type": "sfdc_cms__route",
+  "title": "[ObjectName] [Detail|List|Related List]",
+  "contentBody": {
+    "activeViewId": "[ObjectName]_[Detail|List|Related_List]",
+    "configurationTags": [],
+    "pageAccess": "UseParent",
+    "routeType": "[detail|list|relatedlist]-[IDENTIFIER]",
+    "urlPrefix": "[object-name-lowercase]"
+  },
+  "urlName": "[object-name-lowercase]-[detail|list|related-list]"
+}
+```
+
+**Rules**:
+
+- Before any actions, *always* call `execute_metadata_action` to get the full schema and examples per the skill document.
+
+#### routeType Examples
+
+| Route Type | Standard (Account) | Custom (Test_Object__c) |
+|------------|-------------------|------------------------|
+| Detail | `detail-001` | `detail-Test_Object__c` |
+| List | `list-001` | `list-Test_Object__c` |
+| Related List | `relatedlist-001` | `relatedlist-Test_Object__c` |
+
+### B.5. Naming Conventions
+
+For an object named "Account":
+
+| Field | Detail | List | Related List |
+|-------|--------|------|---------------|
+| Directory Name | `Account_Detail__c` | `Account_List__c` | `Account_Related_List__c` |
+| apiName | `Account_Detail__c` | `Account_List__c` | `Account_Related_List__c` |
+| title | `Account Detail` | `Account List` | `Account Related List` |
+| activeViewId | `Account_Detail` | `Account_List` | `Account_Related_List` |
+| routeType (Standard) | `detail-[keyPrefix]` | `list-[keyPrefix]` | `relatedlist-[keyPrefix]` |
+| routeType (Custom) | `detail-[ObjectApiName]` | `list-[ObjectApiName]` | `relatedlist-[ObjectApiName]` |
+| urlPrefix | `account` | `account` | `account` |
+| urlName | `account-detail` | `account-list` | `account-related-list` |
+
+**CRITICAL**: `routeType` MUST exactly match `viewType` in the corresponding view's `content.json`.
+
+### B.6. View Dependency
+
+- Before creating routes, ensure corresponding views exist in `sfdc_cms__view/`:
+  - `[ObjectName]_Detail/`, `[ObjectName]_List/`, `[ObjectName]_Related_List/`
+- `activeViewId` must match the view directory name exactly
+- `routeType` must exactly match `viewType` in the corresponding view
+- If views don't exist, create them first following the view creation guidelines
+
+### B.7. Generation Checklist
+
+- [ ] Object type determined (Standard or Custom) and identifier obtained (keyPrefix or ObjectApiName)
+- [ ] All three routes created: **Detail**, **List**, and **Related List**, each with `_meta.json` and `content.json`
+- [ ] All naming conventions applied (see B.5)
+- [ ] Corresponding views exist (see B.6)
+- [ ] `routeType` matches `viewType` for all three routes

package/skills/generating-experience-lwr-site/docs/configure-content-themeLayout.md

@@ -0,0 +1,141 @@
+# Content Type: sfdc_cms__themeLayout
+
+**Use when** user explicitly requests creating a new layout.
+
+## Table of Contents
+
+- Directory Structure
+- Purpose A: Generate new theme layouts under the `sfdc_cms__themeLayout` directory.
+
+  - _meta.json Structure
+  - content.json Structure
+  - Naming Conventions
+  - Theme Sync After Creation
+  - Generation Checklist
+- Purpose B: Editing existing theme layouts under the `sfdc_cms__themeLayout` directory.
+
+## Directory Structure
+
+1. **Location**: `digitalExperiences/site/[SITE_NAME]/sfdc_cms__themeLayout/[THEME_LAYOUT_NAME]/`
+2. **Required Files**:
+
+- `_meta.json` - Metadata file defining the API name and type
+- `content.json` - Content file defining the configuration and layout
+
+## Purpose A: Generate New Theme Layouts
+
+**IMPORTANT**: These guidelines should ONLY be applied when the user explicitly requests creating a new layout for their site. Do not apply these guidelines automatically for other tasks or when editing existing layouts.
+
+### _meta.json Structure
+
+The `_meta.json` file must contain:
+
+```json
+{
+  "apiName": "[THEME_LAYOUT_NAME]",
+  "type": "sfdc_cms__themeLayout",
+  "path": "themeLayouts"
+}
+```
+
+**Rules**:
+
+- `apiName`: Must match the themeLayout directory name exactly
+- `type`: Always `"sfdc_cms__themeLayout"`
+- `path`: Always `"themeLayouts"`
+
+### content.json Structure
+
+The `content.json` file must contain:
+
+```json
+{
+  "type": "sfdc_cms__themeLayout",
+  "title": "[DISPLAY_TITLE]",
+  "contentBody": {
+    "component": {
+        "attributes": { },
+        "children": [ "[regions in the layout]" ],
+        "definition": "[FQN of root layout component]",
+        "id": "[root component id]",
+        "type": "component"
+    }
+  },
+  "urlName": "[url name]"
+}
+```
+
+**Field Definitions**:
+
+- `type`: Always `"sfdc_cms__themeLayout"`
+- `title`: Human-readable display title, words separated by spaces (e.g. "Scoped Header and Footer")
+- `contentBody`: Include all `required` properties from `schemaDefinition`. Use `examplesOfContentType` for reference.
+- Do not add additional fields.
+- `urlName`: URL identifier (lowercase, words separated by dashes e.g., "scoped-header-and-footer")
+
+**Rules**:
+
+- Before any actions, *always* call `execute_metadata_action` to get the full schema and examples per the skill document.
+
+### Naming Conventions
+
+1. **Directory Name**: Should be in camelCase
+2. **apiName**: Must exactly match the directory name
+3. **title**: Human-readable title with spaces (e.g., "Service Not Available Theme Layout")
+4. **urlName**: Lowercase with hyphens for URL-friendly format (e.g., "new-layout")
+
+### Theme Sync After Creation
+
+After creating a new `sfdc_cms__themeLayout`, you MUST update:
+
+```
+digitalExperiences/site/[SITE_NAME]/sfdc_cms__theme/[THEME_API_NAME]/content.json
+```
+
+**Lookup**: To find the theme content.json for the current site:
+
+1. Navigate up from the current theme layout directory to the site directory.
+2. Look in sfdc_cms__theme/ (sibling directory to sfdc_cms__themeLayout/).
+3. Find the theme directory (typically one per site).
+4. Read the file: content.json.
+
+**Action (append-only)**:
+
+- ALWAYS append a new entry to `contentBody.layouts`.
+- Do NOT replace or remove existing `layouts` entries.
+- `layoutId` MUST exactly match the new theme layout `apiName`.
+- `layoutType` MUST be chosen based on intended view usage.
+  - **Default**: Generate a random 30-character alphanumeric string (e.g., `xEGgPxY5j5TForZe3J7SBguOfQicEy`) for the `layoutType`. Ensure this string is unique and does not match any existing `layoutType` in the list.
+
+**Example**:
+
+```json
+{
+  "contentBody": {
+    "layouts": [
+      { "layoutId": "existingLayoutA", "layoutType": "Inner" },
+      { "layoutId": "existingLayoutB", "layoutType": "ServiceNotAvailable" },
+      { "layoutId": "[NEW_THEME_LAYOUT_API_NAME]", "layoutType": "[30_CHAR_RANDOM_STRING]" }
+    ]
+  }
+}
+```
+
+### Generation Checklist
+
+When generating a new theme layout, ensure:
+
+- [ ] `_meta.json` created with correct `apiName`, `type`, and `path` (III)
+- [ ] `content.json` created with all required fields (IV)
+- [ ] `urlName` uses lowercase with hyphens (V)
+- [ ] `title` is human-readable (V)
+- [ ] `sfdc_cms__theme/[THEME_API_NAME]/content.json` updated by appending a new `contentBody.layouts` mapping (VI)
+- [ ] **CRITICAL**: Complete all the UUID generation steps. See `docs/handle-component-and-region-ids.md`
+
+## Purpose B: Editing Existing Theme Layouts
+
+### Component Modifications
+
+When adding, removing, or configuring components in existing theme layouts, **always** refer to [handle-ui-components.md](docs/handle-ui-components.md) for placement hierarchy, component structure, column layout, and property configuration.
+
+**Note**: Theme layouts often define the overall structure (header/footer) surrounding the main content region. Ensure components are added to the correct region (e.g., `header`, `footer`).

package/skills/generating-experience-lwr-site/docs/configure-content-view.md

@@ -0,0 +1,233 @@
+# Content Type: sfdc_cms__view
+
+**Use when** user explicitly requests creating a new page or editing an existing page.
+
+## Table of Contents
+
+- Purpose A: Generate New Views
+- Purpose B: Editing Existing Views
+
+## Purpose A: Generate New Views
+
+### Generation Guidelines
+
+**PAGE TYPES**: These guidelines supports two types of pages:
+
+1. **Custom Pages** - Single view pages for custom content (e.g., About Us). **Note**: Standard pages (e.g., Home, Login) come pre-built with the site and cannot be created.
+2. **Object Pages** - Requires 3 views: Detail, List, and Related List (e.g., Account, custom objects)
+
+### Core Principles
+
+1. **Route Association**: Views are referenced by routes via the `activeViewId` field.
+2. **CRITICAL**: The `viewType` MUST exactly match the `routeType` in the corresponding route.
+
+### Directory Structure (All Views)
+
+1. **Location**: Views must be created under: `digitalExperiences/site/[SITE_NAME]/sfdc_cms__view/[VIEW_NAME]/`
+2. **Required Files**:
+  - `_meta.json` - Metadata file defining the API name and type
+  - `content.json` - Content file defining the configuration and layout
+3. **Naming Convention**: Underscore-separated names, no "__c" suffix (About_Us, Account_Detail)
+
+### _meta.json Structure (All Views)
+
+The `_meta.json` file must contain:
+
+```json
+{
+  "apiName": "[VIEW_NAME]",
+  "type": "sfdc_cms__view",
+  "path": "views"
+}
+```
+
+**Rules**:
+
+- `apiName`: Must match directory name exactly. **No "__c" suffix**.
+- `type`: Always `"sfdc_cms__view"`
+- `path`: Always `"views"`
+
+### Theme Layout Type (All Views)
+
+The `contentBody.themeLayoutType` field specifies which theme layout to use for the view.
+
+- **Default**: `"Inner"` - Use this default if the user does not specify a layout OR if the lookup fails to find a matching layoutType
+- **Lookup**: To find valid values:
+    1. Navigate up from the current view directory to the site directory
+    2. Look in `sfdc_cms__theme/` (sibling directory to `sfdc_cms__view/`)
+    3. Find the theme directory (typically one per site)
+    4. Check `content.json` → `contentBody.layouts[]` for the layouts array
+
+- **Layout Name/ID Resolution**: If the user provides only a layout name or ID (e.g., "scopedHeaderAndFooter"), you must look up the corresponding `layoutType`:
+    1. Find the theme's `content.json` as described above
+    2. Locate the `contentBody.layouts` array containing `layoutId`/`layoutType` pairs
+    3. Match the user-provided name/ID against `layoutId` values
+    4. Use the corresponding `layoutType` value for `contentBody.themeLayoutType`
+    5. **Use ONLY the `layoutType` value** for `contentBody.themeLayoutType` - do NOT use the layoutId or user's provided name
+    6. **If no match is found, use the default `"Inner"`**
+
+### PART A: CUSTOM PAGES
+
+Use this section when creating single-view custom content pages.
+
+#### A.1. content.json Structure
+
+The `content.json` file must contain:
+
+```json
+{
+  "type": "sfdc_cms__view",
+  "title": "[DISPLAY_TITLE]",
+  "contentBody": {},
+  "urlName": "[URL_NAME]"
+}
+```
+
+**Field Definitions**:
+
+- `type`: Always `"sfdc_cms__view"`
+- `title`: Human-readable display title (e.g., About Us)
+- `contentBody`: Include all `required` properties from `schemaDefinition`. Use `examplesOfContentType` for reference.
+- `urlName`: Lowercase with hyphens (e.g., `about-us`)
+
+#### A.2. Component Structure
+
+**MUST** use `community_layout:sldsFlexibleLayout` as the root with exactly 2 regions (`content` and `sfdcHiddenRegion`), even if no components exist:
+
+```
+community_layout:sldsFlexibleLayout (root)
+├── content (region) — main page content
+└── sfdcHiddenRegion (region) — hidden region for SEO and metadata
+```
+
+**CRITICAL REQUIREMENTS**:
+
+- **Region names are fixed**: The region `name` field MUST be exactly `content` or `sfdcHiddenRegion`. Do NOT invent custom region names.
+- **sfdcHiddenRegion MUST contain seoAssistant**: The `sfdcHiddenRegion` region MUST ALWAYS include a `community_builder:seoAssistant` component in its `children` array.
+- **Components live in children**: All components are placed inside the `children` array of a region. Use an empty `children: []` array for `content` if no components exist.
+
+Each region requires: `id` (unique UUID), `name`, `title`, `type: "region"`, `children`. Do not add any other fields.
+
+#### A.3. Naming Conventions Summary
+
+| Field | Format | Example |
+|-|-|-|
+| Directory/apiName | Underscore-separated, no "__c" | `About_Us` |
+| title | Human-readable | `About Us` |
+| viewType | `custom-` + lowercase-hyphens | `custom-about-us` |
+| urlName | Lowercase-hyphens | `about-us` |
+
+#### A.4. Route Dependency
+
+The route's `activeViewId` must match the view's directory name exactly.
+
+#### A.5. Generation Checklist
+
+- [ ] Directory and `_meta.json` follow structure (see Directory Structure, _meta.json Structure)
+- [ ] `content.json` has all required fields (A.1)
+- [ ] Component structure correct with both regions (A.1)
+- [ ] **CRITICAL**: Complete all the UUID generation steps. see `docs/handle-component-and-region-ids.md`
+- [ ] `viewType` matches route's `routeType` (CRITICAL)
+
+### PART B: OBJECT PAGES
+
+Use this section when creating object pages that require Detail, List, and Related List views.
+
+#### B.1. Overview
+
+Object pages require **three views**: Detail, List, and Related List. All share the same object name.
+
+**Object Types & viewType Format**:
+
+| Object Type | Identifier | viewType Example |
+|-|-|-|
+| Standard (Account, Contact) | `keyPrefix` (3-char) | `detail-001`, `list-001`, `relatedlist-001` |
+| Custom (Test_Object__c) | API name with `__c` | `detail-Test_Object__c`, `list-Test_Object__c` |
+
+Obtain object information from the `objectList` MCP output from `sfdc_cms__route`:
+
+```json
+[
+   ["Label", "ApiName", "KeyPrefix", "IsCustom"]
+]
+```
+
+#### B.2. Required Views
+
+Create three directories under `sfdc_cms__view/`:
+
+- `[OBJECT_NAME]_Detail/`
+- `[OBJECT_NAME]_List/`
+- `[OBJECT_NAME]_Related_List/`
+
+#### B.3. content.json Structure
+
+```json
+{
+  "type": "sfdc_cms__view",
+  "title": "[OBJECT_NAME] [TYPE]",
+  "contentBody": {
+    "component": {},
+    "dataProviders": [],
+    "themeLayoutType": "[THEME_LAYOUT_TYPE]",
+    "viewType": "[PREFIX]-[IDENTIFIER]"
+  },
+  "urlName": "[OBJECT_NAME_LOWERCASE]-[TYPE]"
+}
+```
+
+**Field Definitions**:
+
+- `type`: Always `"sfdc_cms__view"`
+- `title`: Human-readable (e.g., "Account Detail")
+- `contentBody`: Include all `required` properties from `schemaDefinition`. Use `examplesOfContentType` for reference.
+- `contentBody.viewType`: **CRITICAL**: Must exactly match route's `routeType`
+- `urlName`: Lowercase with hyphens (e.g., `account-detail`)
+
+**Rules**:
+
+- Before any actions, *always* call `execute_metadata_action` to get the full schema and examples per the skill document.
+
+#### B.4. Component Structure
+
+Uses same structure as Part A.1 (Component Structure) with these SEO assistant differences:
+
+- **Detail View**: `pageTitle: "{!Record._Object}: {!Record._Title}"`
+- **List/Related List Views**: `recordId: "{!recordId}"` (no pageTitle)
+
+Default template includes one section with one empty column. `seedComponents` must be `[]` (not `null`).
+
+#### B.5. Naming Conventions Summary
+
+| Field | Detail | List | Related List |
+|-|-|-|-|
+| Directory/apiName | `[Object]_Detail` | `[Object]_List` | `[Object]_Related_List` |
+| title | `[Object] Detail` | `[Object] List` | `[Object] Related List` |
+| viewType (Standard) | `detail-[keyPrefix]` | `list-[keyPrefix]` | `relatedlist-[keyPrefix]` |
+| viewType (Custom) | `detail-[ApiName__c]` | `list-[ApiName__c]` | `relatedlist-[ApiName__c]` |
+| urlName | `[object]-detail` | `[object]-list` | `[object]-related-list` |
+
+#### B.6. Route Dependency
+
+The route's `activeViewId` must match the view's directory name exactly. The `viewType` must exactly match the route's `routeType`.
+
+#### B.7. Generation Checklist
+
+- [ ] Object type determined; identifier obtained (`keyPrefix` or API name with `__c`)
+- [ ] All three views created: **Detail**, **List**, and **Related List**, each with `_meta.json` and `content.json`
+- [ ] `viewType` matches route's `routeType` for all three views (CRITICAL)
+- [ ] Component structure correct with both regions (see A.1)
+- [ ] SEO assistant configured correctly per view type (B.4)
+- [ ] **CRITICAL**: Complete both UUID generation steps. see `docs/handle-component-and-region-ids.md`
+
+## Purpose B: Editing Existing Views
+
+Use this section when modifying existing views under the `sfdc_cms__view` directory.
+
+### Component Modifications
+
+When adding, removing, or configuring components in existing views, **always** refer to [handle-ui-components.md](docs/handle-ui-components.md) for placement hierarchy, component structure, column layout, and property configuration.
+
+### Theme Layout Type
+
+To change a view's theme layout, update `contentBody.themeLayoutType` in the view's `content.json`. See **Theme Layout Type (All Views)** for default and lookup details

package/skills/generating-experience-lwr-site/docs/configure-guest-sharing-rules.md

@@ -0,0 +1,42 @@
+# Guest User Sharing Rules (Public Sites Only)
+
+**Use when** the user explicitly wants to make the site **public** (accessible to unauthenticated visitors). If the site is private/login-required, guest sharing rules are not needed.
+If sharingRules metadata is not available locally in force-app/main/default/sharingRules, retrieve it from the org before creating new rules.
+
+## Retrieve Full SharingRules Schema
+
+Use the metadata MCP tool with metadataType "SharingRules" to retrieve schema.
+
+## XML Example
+
+```xml
+<?xml version="1.0" encoding="UTF-8"?>
+<SharingRules xmlns="http://soap.sforce.com/2006/04/metadata">
+  <sharingGuestRules>
+    <fullName>ShareAccountsWithSiteGuest</fullName>
+    <accessLevel>Read</accessLevel>
+    <includeHVUOwnedRecords>false</includeHVUOwnedRecords>
+    <label>Share Accounts With Site Guest</label>
+    <sharedTo>
+      <guestUser>[site Guest User's CommunityNickanme]</guestUser>
+    </sharedTo>
+    <criteriaItems>
+      <field>Name</field>
+      <operation>notEqual</operation>
+      <value>null</value>
+    </criteriaItems>
+  </sharingGuestRules>
+</SharingRules>
+```
+
+## Critical Requirements
+
+1. **SharedTo Element**: Must use `<guestUser>{site Guest User's CommunityNickanme}</guestUser>` (not URL path prefix).
+2. **includeHVUOwnedRecords**: Required field. Set to `false` unless records owned by high-volume site users should be included.
+3. **One XML file per object**: Put all rules for a given object in one file. Do not create additional.
+
+## Common Mistakes
+
+- Using `<role>` or `<group>` instead of `<guestUser>` in sharedTo
+- Omitting the required `includeHVUOwnedRecords` field
+- Using `includeRecordsOwnedByAll` (that's for `sharingCriteriaRules`, not guest rules)

package/skills/generating-experience-lwr-site/docs/handle-component-and-region-ids.md

@@ -0,0 +1,27 @@
+# UUID Generation
+
+**Use when** handling IDs for components and regions of views. All component and region IDs in Experience Site content must be unique UUIDs.
+
+## Requirements
+
+1. **Format**: Lowercase UUID v4 (e.g., `5d56a22f-c1e8-40d3-92ec-6e10e71e36de`)
+2. **Uniqueness**: Must be unique across ALL `content.json` files in site (under `digitalExperiences/site/<SITE_NAME>/`)
+
+## For New content.json Files Only
+
+**Multistep Process (REQUIRED)**:
+
+- **CRITICAL**: Each step must be performed separately - do NOT combine steps into a single automated command or script
+- **Step 1**: Create files with descriptive placeholders for UUIDs (e.g., `UUID_CONTENT_REGION`, `UUID_HIDDEN_REGION`, `UUID_SEO_COMPONENT`)
+- **Step 2**: Count the total number of UUID placeholder occurrences in the generated file, then generate exactly that many UUIDs using:
+  - `node -e "console.log(Array.from({length: N}, () => require('crypto').randomUUID()).join('\n'))"` where N is the total count of placeholder occurrences. Present this command to the user for execution.
+- **Step 3**: Replace each placeholder occurrence sequentially with the generated UUIDs from the list, ensuring each occurrence gets a unique UUID from the list. Perform replacements one at a time or in small batches - do NOT automate this with scripts.
+- **Step 4**: Validate that all placeholders have been replaced - read the file and search for any remaining placeholder patterns (e.g., `UUID_`). The file is NOT valid until all placeholders are replaced with actual UUIDs.
+- **CRITICAL**: Every single placeholder occurrence must be replaced with a DIFFERENT UUID from the generated list, even if the placeholder name is repeated. For example, if you have 5 total placeholder occurrences, generate 5 UUIDs and replace each occurrence with the next UUID from the list.
+- **NEVER** write UUIDs inline during file creation - always use the multistep placeholder approach
+
+## For Editing Existing content.json Files
+
+- **CRITICAL**: Read file first and preserve all existing UUIDs exactly as-is
+- NEVER replace existing UUIDs with placeholders
+- For newly added components/regions only, follow the multistep placeholder process from step 3