@salesforce/afv-skills 1.41.0 → 1.43.0

package/skills/experience-cms-content-type-generate/references/schema-rules.md

@@ -0,0 +1,51 @@
+# Schema rules (validator truth)
+
+The CMS deploy validator is the source of truth — not the per-type metaschemas.
+
+## Bundle root (`schema.json`)
+
+- **MUST include**: `"title"`, `"description"`, `"lightning:type": "lightning__objectType"`, `"lightning:mixinTypes": { "sfdc_cms:metadataContent": {} }`, `"properties"`, `"required"`, `"unevaluatedProperties": false` (root only — do NOT set `unevaluatedProperties` on individual field entries inside `properties`).
+- **MUST NOT include**: `"$schema"` at root.
+
+## Per-field rules
+
+**Allowed top-level keys per field**: `title`, `description`, `lightning:type`, `lightning:uiOptions`, plus the type-specific keys in the table below. **Nothing else.**
+
+**Forbidden top-level keys on any field** (validator rejects under `unevaluatedProperties: false`):
+- `type` (the JSON Schema `"type": "string"` etc — never write it; `lightning:type` is the only type marker)
+- `format` (e.g. `"format": "date"` on a date field)
+- `default`
+- Any other JSON Schema keyword not in this skill
+
+**`lightning:uiOptions` rules (sharp edge — caused multi-attempt auto-fix loops):**
+- If you write `lightning:uiOptions`, it **MUST** contain a non-empty `placeholderText` string. Empty `{}` fails validation with `placeholderText: is missing but it is required`.
+- The default-minimal rule means: **omit `lightning:uiOptions` entirely** unless the user asked for placeholders. Do NOT write `"lightning:uiOptions": {}`.
+- All-or-nothing: include `lightning:uiOptions` with a real `placeholderText`, or omit the key completely.
+
+`lightning:uiOptions` (with a real `placeholderText`) is accepted on **every** type. The columns below are the *additional* type-specific keys allowed alongside `lightning:type`.
+
+| `lightning:type` | Accepted keys |
+|---|---|
+| `lightning__textType` | `minLength`, `maxLength`, `lightning:textIndexed`, `lightning:localizable`, `enum`, `const` |
+| `lightning__multilineTextType` | `minLength`, `maxLength`, `lightning:textIndexed`, `lightning:localizable` |
+| `lightning__richTextType` | `minLength`, `maxLength`, `lightning:textIndexed`, `lightning:localizable` |
+| `lightning__urlType` | `lightning:allowedUrlSchemes` (required), `lightning:localizable`, `readOnly` |
+| `lightning__dateType` | `lightning:localizable` |
+| `lightning__dateTimeType` | `lightning:localizable` |
+| `lightning__booleanType` | (none) |
+| `lightning__integerType` | `minimum`, `maximum`, `const` |
+| `lightning__numberType` | `minimum`, `maximum`, `const` |
+| `lightning__imageType` | (none — do NOT add `type`, `format`, or any other key) |
+
+Default-minimal: only set type-specific keys when the user explicitly asks. The columns above are validator-accepted; they are not defaults to apply automatically.
+
+## Validator quirks
+
+- `lightning:mixinTypes` accepts ONLY `sfdc_cms:metadataContent`. Any other mixin fails.
+- `enum` is only valid for `lightning__textType`.
+- `required` referencing a missing property is not deploy-enforced — but keep it consistent.
+- No `default` values anywhere — validator rejects them.
+
+## Default-minimal rule (step 3a)
+
+Do NOT add `lightning:textIndexed`, `lightning:localizable`, length/range bounds, `enum`, `const`, or `placeholderText` unless the user asked. Match the request, nothing more. The user can request additions in step 3b.

package/skills/experience-cms-content-type-generate/references/schema-summary-format.md

@@ -0,0 +1,60 @@
+# Step 7.5 — schema summary format
+
+Runs whenever `{fqn, schema}` has been resolved, regardless of source (local, grounding, retrieve, or new-and-deployed) or of `suppressCreateContentPrompt`. The user always sees what the type contains before the workflow ends or hands off. Callers that suppress the trailing prompt (step 8) still get the summary — the summary is informational, not a turn.
+
+## When to run
+
+- Step 1e returned `{fqn, schema}` (existing type reconciled — from local, from grounding, or from `sf project retrieve`).
+- Step 7e succeeded (new type created and deployed — the schema is the one just written).
+- Step 1e's drift-prompt "Deploy local to org" branch reached 7e.
+- **Step 1e's "local only" branch** — BEFORE the `Deploy it? Yes / Cancel` prompt, print the summary of the LOCAL schema so the user sees what they'd be deploying (a local-only bundle is the most likely case to be stale or hand-edited). Header: `Local schema for "<fqn>" (not yet in the org):`.
+
+## When NOT to run
+
+- User picked `Cancel` at any point.
+- Step 7b (user answered "No — I'll deploy later") — no resolved schema in the org, nothing to summarize.
+- Any error path exited without a resolved `{fqn, schema}`.
+
+## Format — one line + one markdown table
+
+Printed as chat text (NOT inside an `ask_user_tool`):
+
+```text
+Content type "<fqn>" is ready. Schema:
+
+| # | API name | Type | Required | Constraints | Title |
+|---|---|---|---|---|---|
+| 1 | `title` | `lightning__textType` | yes | maxLength: 200 | Title |
+| 2 | `body`  | `lightning__richTextType` | yes | — | Body |
+| 3 | `publishDate` | `lightning__dateType` | no | — | Publish Date |
+| 4 | `ctaUrl` | `lightning__urlType` | no | allowedUrlSchemes: ["https"] | Call to Action |
+| 5 | `heroImage` | `lightning__imageType` | no | — | Hero Image |
+```
+
+## Column rules
+
+- **`#`** — 1-indexed order from `schema.properties` (JSON key order).
+- **`API name`** — the property key, backticked.
+- **`Type`** — the `lightning:type` value, backticked.
+- **`Required`** — `yes` if the key is in `schema.required`, else `no`.
+- **`Constraints`** — a compact, comma-separated summary of the property's declared constraints:
+  - Include `minLength`, `maxLength`, `minimum`, `maximum`, `enum` (as `enum: [a, b, c]`, truncated to 3 with `…` if longer), `pattern` (as `pattern: <regex>`), `format`, `lightning:allowedUrlSchemes`, `readOnly`, `lightning:localizable`, `lightning:textIndexed`, `const`.
+  - If a field has no declared constraints, emit `—` (em-dash), NOT an empty cell.
+  - Do NOT include `lightning:type` here — it's already in the `Type` column.
+  - Do NOT include `lightning:uiOptions.placeholderText` — it's not a constraint.
+- **`Title`** — the property's `title` value, or the API name humanized if `title` is missing.
+
+## Sort / truncation
+
+- Preserve `schema.properties` insertion order.
+- If the schema has more than 20 properties, print the first 20 and add a final row `| … | (N more properties) | | | | |` where N = total − 20.
+
+## Do NOT print
+
+- The raw JSON schema.
+- Root-level metadata (`title`, `description`, `lightning:type`, `lightning:mixinTypes`).
+- `unevaluatedProperties`.
+
+Those are agent-internal details — the user cares about the field list, not the JSON.
+
+After printing the table, continue immediately to step 8 (no separate turn, no user prompt between 7.5 and 8).

package/skills/experience-lds-graphql-generate/SKILL.md

@@ -2,6 +2,10 @@
 name: experience-lds-graphql-generate
 description: "Use ALWAYS when a prompt mentions GraphQL, lightning/uiGraphQLApi, @wire(graphql, ...), or gql template tags in an LWC context — even if the surface ask is \"build an LWC\". Owns the ENTIRE flow: introspect the org's LDS GraphQL schema, identify entities/fields, construct the schema-validated gql query or mutation, wire it into the LWC via lightning/uiGraphQLApi, verify against a connected org. REQUIRED whenever a prompt asks to render, list, or edit Salesforce records (Account, Contact, Case, custom objects) via GraphQL — the .html and .js scaffolding IS in scope. DO NOT delegate to experience-lwc-generate: that skill has NO GraphQL schema introspection, NO create_lds_graphql_read_query binding, and defaults to getRecord/getRelatedListRecords wire adapters which will not satisfy a GraphQL prompt. DO NOT TRIGGER only if the prompt forbids GraphQL, chooses UIAPI/Apex (use experience-lds-best-practices-apply), or asks for data requirements (use experience-lds-data-requirements-generate)."
 metadata:
+  relatedSkills:
+    - "experience-lds-best-practices-apply"
+    - "experience-lds-data-requirements-generate"
+    - "experience-lwc-generate"
   version: "1.0"
   domains: ["Experience", "Platform"]
   cliTools:

package/skills/experience-lwc-accessibility-jest-run/SKILL.md

@@ -0,0 +1,79 @@
+---
+name: experience-lwc-accessibility-jest-run
+description: "Use ALWAYS when running Sa11y accessibility Jest tests for a Lightning Web Component — locally before pushing, producing the exact command(s), running one file vs a whole suite, selecting tests by naming convention, saving Sa11y-rendered HTML, or reproducing a Sa11y / A11yBug failure. Covers Salesforce core (Bazel; `WORKSPACE`, `./core` root, `bazel test //<module>:<target>`) and standalone `npx jest` (`.accessibility.test.js`, `@sa11y/jest`). REQUIRED when a prompt asks for a `run-plan.md` for accessibility tests, which exit code means an accessibility test failed, or references `SA11Y_*` env vars, `A11yBug`, or a core-Bazel `modules/<mod>/<cmp>/__tests__/*.test.js` path. Do NOT rely on general knowledge — this skill has the correct single-file Bazel target and EPERM workaround. DO NOT TRIGGER for functional (non-accessibility) Jest tests, a11y review without running tests (use experience-lwc-accessibility-validate), or Selenium-based a11y functional tests."
+metadata:
+  version: "1.0"
+  domains: ["Experience"]
+  cliTools:
+    - tool: ["npm"]
+      semver: ">=8.0"
+---
+<!-- adk-managed-skill -->
+
+# Running LWC Accessibility Jest Tests
+
+Run Sa11y accessibility unit tests on Lightning Web Components in either:
+
+- **Core (Bazel)** — when a `WORKSPACE` file is present.
+- **Standalone (Jest)** — when there's no `WORKSPACE`.
+
+Selenium-level reproductions, GUS A11yBug ingestion, and other internal
+Salesforce-only flows are out of scope for this skill. For source-code-level
+WCAG review without running tests, see `experience-lwc-accessibility-validate`.
+
+## When to Use This Skill
+
+- User wants to run accessibility unit tests (Sa11y Jest) locally before
+  pushing a fix.
+- User has a known failing test file path (e.g. from an A11yBug's
+  `Test_Names__c`) and wants to target it directly.
+- User is iterating on an accessibility fix and needs the fastest
+  pass/fail signal.
+
+## Prerequisites
+
+- For Bazel Jest tests: a Salesforce core build environment (a `WORKSPACE`
+  file is present).
+- For standalone Jest tests: `@sa11y/jest` installed and configured.
+
+
+## Workflow
+
+Follow [running-sa11y-jest-tests.md](references/running-sa11y-jest-tests.md).
+Pick the correct mode:
+
+- **Core (Bazel)** — use when `WORKSPACE` is present. Prefer single-file
+  targets (`//{moduleName}:{relativePath}`) over module targets when the
+  failing test file path is already known (`.test.js` extension dropped).
+  Bazel commands must pass `--test_env=SA11Y_AUTO=1
+  --test_env=SA11Y_ENABLE_DOM_MUTATION_OBSERVER=1`; when debugging, add
+  `SA11Y_ENABLE_RENDERED_DOM_SAVE=1` with the documented save path to avoid
+  EPERM issues.
+- **Standalone (Jest)** — use when there's no `WORKSPACE`. Run
+  `npm test -- --testMatch="**/*.accessibility.test.js"` for the whole suite,
+  or `npm test -- <file>` targeting the file by the name/path given in the
+  prompt (a **bare filename** when it is "in this directory"). Do **not**
+  prepend `SA11Y_*` env vars in standalone mode — Sa11y runs automatically
+  because `@sa11y/jest` is wired into the project's Jest setup; no extra
+  environment variables are needed.
+
+**Answer only what is asked.** Emit just the command(s) the prompt requests plus
+the exit-code meaning. Do not pad the plan with unrequested variants (watch,
+coverage, verbose), snapshot-update steps, or HTML-save sections unless the user
+explicitly asks for them.
+
+
+## Verification Checklist
+
+- [ ] Sa11y Jest run completed with a clear pass/fail signal (exit 0 or 3
+      for Bazel; exit 0 or 1 for Jest).
+- [ ] If snapshots were intentionally updated, the new snapshots are
+      committed alongside the fix.
+
+
+## Troubleshooting
+
+- **Bazel test "not found"** — the target path is off. Remember to drop the
+  `.test.js` extension in `{relativePath}`.
+- **HTML saving fails with EPERM** — use the prescribed save path
+  `sfdc-test/unit/javascript/htdocs/sa11y/jest`.

package/skills/experience-lwc-accessibility-jest-run/references/running-sa11y-jest-tests.md

@@ -0,0 +1,205 @@
+# Sa11y Accessibility Test Instructions
+
+## Environment Detection
+
+Choose the approach based on your environment:
+
+- **Core Build Environment** — contains a `WORKSPACE` file, uses Bazel build system.
+- **Standalone Environment** — no `WORKSPACE` file, uses npm/yarn scripts.
+
+If this is not a Salesforce core build environment, do not mention anything about the core build environment.
+
+---
+
+## Core Build Environment (Bazel)
+
+When working within a Salesforce core build environment, use Bazel commands.
+
+### Base Command Structure
+
+```bash
+{coreRootPath}/tools/bazel test [TARGET] --test_output=streamed --test_env=SA11Y_AUTO=1 --test_env=SA11Y_ENABLE_DOM_MUTATION_OBSERVER=1
+```
+
+**Replacements:**
+
+- `{coreRootPath}` — your actual core root directory path
+- `{moduleName}` — module name (e.g. `ui-content-authoring-components`)
+- `{relativePath}` — test file path **without** `.test.js` extension
+
+### Testing Approaches
+
+#### 1. Single File Testing
+
+```bash
+{coreRootPath}/tools/bazel test //{moduleName}:{relativePath} --test_output=streamed --test_env=SA11Y_AUTO=1 --test_env=SA11Y_ENABLE_DOM_MUTATION_OBSERVER=1
+```
+
+Example:
+
+```bash
+./core/tools/bazel test //ui-content-authoring-components:modules/es_block_builder/blockBuilder/__tests__/blockBuilder --test_output=streamed --test_env=SA11Y_AUTO=1 --test_env=SA11Y_ENABLE_DOM_MUTATION_OBSERVER=1
+```
+
+**Use when:** testing a specific component with a known test file path.
+
+#### 2. Module Testing
+
+```bash
+{coreRootPath}/tools/bazel test //{moduleName}:sa11y_jest_test --test_output=streamed --test_env=SA11Y_AUTO=1 --test_env=SA11Y_ENABLE_DOM_MUTATION_OBSERVER=1
+```
+
+Example:
+
+```bash
+./core/tools/bazel test //ui-content-authoring-components:sa11y_jest_test --test_output=streamed --test_env=SA11Y_AUTO=1 --test_env=SA11Y_ENABLE_DOM_MUTATION_OBSERVER=1
+```
+
+**Use when:** testing an entire module or when unsure which specific component to target.
+
+#### 3. Multiple Modules
+
+```bash
+{coreRootPath}/tools/bazel test //{module1}:sa11y_jest_test //{module2}:sa11y_jest_test --test_output=streamed --test_env=SA11Y_AUTO=1 --test_env=SA11Y_ENABLE_DOM_MUTATION_OBSERVER=1
+```
+
+**Use when:** integration testing across module boundaries.
+
+#### 4. Wildcard Testing
+
+```bash
+{coreRootPath}/tools/bazel test //{moduleName}:sa11y_jest_test --test_arg=--testMatch="**/{modulePath}/**" --test_output=streamed --test_env=SA11Y_AUTO=1 --test_env=SA11Y_ENABLE_DOM_MUTATION_OBSERVER=1
+```
+
+**Use when:** filtering multiple components within a module by pattern.
+
+---
+
+## Standalone Environment (Direct Jest)
+
+No `SA11Y_*` environment variables are needed here — `@sa11y/jest` is wired into
+the project's Jest setup, so the accessibility assertions run automatically.
+
+```bash
+# Run all accessibility tests (match by the *.accessibility.test.js convention)
+npm test -- --testMatch="**/*.accessibility.test.js"
+
+# Re-run a single test file — use the filename/path as given in the prompt
+# (a bare filename when the file is "in this directory")
+npm test -- myComponent.accessibility.test.js
+```
+
+### Jest Configuration
+
+Ensure Jest includes Sa11y setup:
+
+```javascript
+// jest.config.js
+module.exports = {
+  setupFilesAfterEnv: ['<rootDir>/test/setup/sa11y-setup.js'],
+  testEnvironment: 'jsdom',
+};
+```
+
+### Sa11y Setup File
+
+```javascript
+// test/setup/sa11y-setup.js
+import { configure } from '@sa11y/jest';
+
+configure({
+  rules: ['wcag2a', 'wcag2aa', 'wcag2aaa'],
+});
+```
+
+---
+
+## Path Discovery (Core Build Environment)
+
+```bash
+# Find all test files in a module
+find {coreRootPath}/ui-content-authoring-components -name "*.test.js" -type f
+
+# Explore module structure
+ls {coreRootPath}/ui-content-authoring-components/modules/
+
+# Use Bazel to list test targets
+{coreRootPath}/tools/bazel query "tests(//ui-content-authoring-components:*)"
+```
+
+### Path Construction
+
+- **Module Name** — use directly (e.g. `ui-content-authoring-components`)
+- **Component Path** — `modules/{componentDir}/{componentName}/__tests__/`
+- **Test File** — remove `.test.js` extension
+
+---
+
+## Optional Arguments
+
+### Bazel Options
+
+| Option           | Command                                                                                                                           | Purpose                    |
+| ---------------- | --------------------------------------------------------------------------------------------------------------------------------- | -------------------------- |
+| Update Snapshots | `--test_arg="--updateSnapshot"`                                                                                                   | Update test snapshots      |
+| Disable Cache    | `--cache_test_results=no`                                                                                                         | Disable Bazel test caching |
+| Save HTML Files  | `--test_env=SA11Y_ENABLE_RENDERED_DOM_SAVE=1 --test_env=SA11Y_RENDERED_DOM_SAVE_PATH=sfdc-test/unit/javascript/htdocs/sa11y/jest` | Save HTML for analysis     |
+
+**Note:** Use `sfdc-test/unit/javascript/htdocs/sa11y/jest` as the save path to avoid EPERM permission issues.
+
+**Complete example with HTML saving:**
+
+```bash
+./core/tools/bazel test //ui-content-authoring-components:modules/es_block_builder/blockBuilder/__tests__/blockBuilder \
+  --test_output=streamed \
+  --test_env=SA11Y_AUTO=1 \
+  --test_env=SA11Y_ENABLE_DOM_MUTATION_OBSERVER=1 \
+  --test_env=SA11Y_ENABLE_RENDERED_DOM_SAVE=1 \
+  --test_env=SA11Y_RENDERED_DOM_SAVE_PATH=sfdc-test/unit/javascript/htdocs/sa11y/jest
+```
+
+### Jest Options
+
+```bash
+# Update snapshots
+npm test -- --testMatch="**/*.accessibility.test.js" --updateSnapshot
+
+# Run in watch mode
+npm test -- --testMatch="**/*.accessibility.test.js" --watch
+
+# Run with verbose output
+npm test -- --testMatch="**/*.accessibility.test.js" --verbose
+```
+
+---
+
+## Expected Exit Codes
+
+### Bazel
+
+- **0** — all tests passed
+- **3** — build succeeded, some tests failed
+- **1** — build or command failed
+
+### Jest
+
+- **0** — all tests passed
+- **1** — some tests failed or error occurred
+
+---
+
+## Troubleshooting
+
+### Bazel
+
+- Verify `WORKSPACE` file exists
+- Check Bazel version compatibility
+- Ensure test targets are properly defined
+- Verify repository-specific Bazel binary path
+
+### Jest
+
+- Verify Jest configuration
+- Check test file naming conventions
+- Ensure Sa11y dependencies are installed
+- Verify jsdom environment setup

package/skills/experience-lwc-design-generate/SKILL.md

@@ -15,7 +15,8 @@ metadata:
     - design-systems-slds-apply
     - experience-lds-best-practices-apply
     - experience-lds-data-requirements-generate
-    - experience-lwc-accessibility-validate
+    - experience-lwc-accessibility-jest-run
+    - experience-accessibility-validate
     - experience-lwc-base-components-integrate
     - experience-lwc-generate
     - experience-lwc-rtl-validate
@@ -101,7 +102,7 @@ Do NOT use this skill for:
    - Audit event handlers and lifecycle hook usage (`renderedCallback` guards).
    - Consider lazy loading for heavy children.
 2. Hand off to `experience-lwc-generate` for the LWC best-practices review pass (anti-patterns, reactivity, composition).
-3. Hand off to the compliance suite for the pre-ship review — `experience-lwc-accessibility-validate` (a11y), `experience-lwc-security-validate` (LWS + Product Security), and `experience-lwc-rtl-validate` (RTL i18n). Run them together for the full quality pass.
+3. Hand off to the compliance suite for the pre-ship review — `experience-accessibility-validate` (a11y), `experience-lwc-security-validate` (LWS + Product Security), and `experience-lwc-rtl-validate` (RTL i18n). Run them together for the full quality pass.
 4. If the component touches data, hand off to `experience-lds-best-practices-apply` for cache/consistency and referential-integrity checks.
 5. Apply every accepted finding. Keep the PRD as the source of truth — do not add scope under the guise of optimization.
 
@@ -153,7 +154,7 @@ A new component built from this workflow is "done" only when **every** item belo
 
 5. `.js-meta.xml` AI metadata passes the audit in `experience-lwc-generate` (component-wide `<ai><description>` set, plus an `<ai><property name="…" aiDescription="…"/></ai>` entry for every `@api` member exposed through `<targetConfig>`; no marketing language).
 6. SLDS styling passes `design-systems-slds-apply` verification — no raw hex / px values, only styling hooks and SLDS utility classes.
-7. Accessibility pass complete: `experience-lwc-accessibility-validate` for source review + `experience-lwc-accessibility-jest-run` for automated tests, both green.
+7. Accessibility pass complete: `experience-accessibility-validate` for source review + `experience-lwc-accessibility-jest-run` for automated tests, both green.
 8. Security + RTL pass complete: `experience-lwc-security-validate` + `experience-lwc-rtl-validate`, both green.
 
 **Data + tests:**
@@ -169,7 +170,7 @@ A new component built from this workflow is "done" only when **every** item belo
   - `design-systems-slds-apply`, `experience-lwc-base-components-integrate` — Phase 2 styling decisions.
   - `experience-lwc-generate` — Phase 2 authoring baseline + Phase 3 best-practices review + Phase 5 AI-metadata audit.
   - `experience-lds-best-practices-apply` — Phase 2/3 data-layer adapter selection and consistency review.
-  - `experience-lwc-accessibility-validate`, `experience-lwc-security-validate`, `experience-lwc-rtl-validate` — Phase 3 a11y/security/RTL review.
+  - `experience-accessibility-validate`, `experience-lwc-security-validate`, `experience-lwc-rtl-validate` — Phase 3 a11y/security/RTL review.
   - `experience-lwc-accessibility-jest-run` — Phase 5 automated a11y test generation.
   - Optional: add o11y instrumentation as a separate pass once the component stabilizes.
   - `experience-lwc-typescript-migrate` — optional once JS is green.

package/skills/experience-lwc-generate/SKILL.md

@@ -2,6 +2,16 @@
 name: experience-lwc-generate
 description: "Lightning Web Components with PICKLES methodology and 165-point scoring. Use this skill when the user creates or edits LWC components, builds wire service patterns, or writes Jest tests for LWC. TRIGGER when: user creates/edits LWC components, touches lwc/**/*.js, .html, .css, .js-meta.xml files, or asks about wire service, SLDS, or Jest LWC tests. DO NOT TRIGGER when: Apex classes (use platform-apex-generate), Aura components, or Visualforce."
 metadata:
+  version: "1.1"
+  domains: ["Experience"]
+  minApiVersion: "66.0"
+  relatedSkills:
+    - "agentforce-generate"
+    - "automation-flow-generate"
+    - "integration-connectivity-generate"
+    - "platform-apex-generate"
+    - "platform-apex-test-run"
+    - "platform-metadata-deploy"
   cliTools:
     - tool: ["node"]
       semver: ">=18.0.0"
@@ -13,15 +23,6 @@ metadata:
       semver: ">=3.9.0"
     - tool: ["sf"]
       semver: ">=2.0.0"
-  relatedSkills:
-    - "agentforce-generate"
-    - "automation-flow-generate"
-    - "integration-connectivity-generate"
-    - "platform-apex-generate"
-    - "platform-apex-test-run"
-    - "platform-metadata-deploy"
-  version: "1.1"
-  domains: ["Experience"]
 ---
 
 # experience-lwc-generate: Lightning Web Components Development

package/skills/experience-ui-bundle-deploy/references/dev-preview.md

@@ -34,6 +34,27 @@ Run it from the **project root** (the `npm` script `cd`s into the bundle itself)
 6. `npm run dev` — launch the Vite dev server. **Blocking** — it runs until the
    user stops it with Ctrl+C.
 
+## Local preview limitations
+
+`npm run dev:preview` runs the app in the Vite dev server with `sdk.fetch` proxied
+to the org **outside the Experience site's guest/community context**. Some auth
+surfaces therefore **cannot be exercised locally** — this is expected, not a
+misconfiguration:
+
+- **Social Login buttons do not render.** The built-in Social Login component calls
+  `/auth/social-login-config`, which returns no providers because `Site.getBaseUrl()`
+  is blank outside the site context — even when providers are correctly linked
+  (SKILL.md step 6b). The Social Login section simply renders nothing.
+- **Password / MFA login does not complete.** `Site.login()` cannot establish the
+  site session, so login returns *"Your login attempt has failed…"* and any MFA
+  challenge never renders.
+
+Test social login and MFA on the **published** site login page
+(`https://<domain>.site.com/<site-path>/login`), not on `localhost`.
+
+`npm run dev:preview` prints this same warning to the CLI just before it launches
+the dev server, so the limitation is visible even without reading this reference.
+
 ## When to use it vs. the setup GraphQL step
 
 - **Setup step 8** (`references/graphql.md`) refreshes schema/types and then

package/skills/experience-ui-bundle-deploy/references/social-login.md

@@ -177,3 +177,4 @@ sf data create record --target-org <org> --sobject PermissionSetAssignment \
 | SSO user: `NO_ACCESS: User was not authorized for the community` | `communityMemberProfile` not in `NetworkMemberGroup` | Ensure sub-step 3 ran (profile added to member groups) |
 | SSO user insert fails with `FIELD_INTEGRITY_EXCEPTION` | "Allow standard external profiles" org setting off | Ensure sub-step 1 ran (`enableExternalProfiles`) |
 | `getCurrentUser()` / `/chatter/users/me` fails for SSO users | Community profile lacks `ApiEnabled` | Set `communityUserPermset` so sub-step 4 assigns API access |
+| No social-login buttons in local dev preview (`npm run dev:preview`) even when providers are correctly linked | Local preview runs outside the Experience site guest context, so `/auth/social-login-config` returns no providers (`Site.getBaseUrl()` is blank) | Expected — not a misconfig. Verify on the **published** site login page, not `localhost`. |

package/skills/experience-ui-bundle-file-upload-generate/SKILL.md

@@ -396,9 +396,9 @@ The package includes a reference implementation in `src/features/fileupload/` wi
 
 ## DO NOT do these things
 
-- ❌ Build XHR/fetch upload logic from scratch — use the `upload()` API
-- ❌ Try to import `<FileUpload />` component — it's not exported
-- ❌ Try to import `useFileUpload` hook — it's not exported
-- ❌ Use third-party file upload libraries when this feature exists
-- ❌ Skip progress tracking — always provide user feedback
-- ❌ Ignore errors — always handle and display error messages
+- Build XHR/fetch upload logic from scratch — use the `upload()` API
+- Try to import `<FileUpload />` component — it's not exported
+- Try to import `useFileUpload` hook — it's not exported
+- Use third-party file upload libraries when this feature exists
+- Skip progress tracking — always provide user feedback
+- Ignore errors — always handle and display error messages