@salesforce/afv-skills 1.55.0 → 1.57.0

package/skills/experience-lwc-legacy-migrate/scripts/convert-lo-names.py

@@ -0,0 +1,94 @@
+#!/usr/bin/env python3
+"""Deterministic Lightning Out Beta -> LO 2.0 name/URL transforms.
+
+The Beta -> LO 2.0 migration includes a few *purely mechanical* string
+conversions that must be applied identically every time (Workflow B, Step B3):
+
+  * Aura component id ``c:myComponent`` -> LWC custom-element tag ``c-my-component``
+  * camelCase attribute names -> kebab-case HTML attribute names
+  * the org My Domain -> the versioned LO 2.0 library ``<script>`` URL
+
+This script performs those conversions so the workflow never has to hand-derive
+them. It does NOT make any judgement calls (target DOM location, whether an LO
+2.0 App id is needed, placeholder values) -- those stay in the skill body.
+
+Usage:
+  python3 scripts/convert-lo-names.py \
+      --component c:myComponent \
+      --attributes recordId,ownerId,showRevenue \
+      --my-domain https://acme.my.salesforce.com
+
+Any of the flags may be omitted; only the requested conversions are printed.
+Exit code is 0 on success, 2 on a malformed argument.
+"""
+import argparse
+import re
+import sys
+
+LO2_LIBRARY_PATH = "/lightning/lightning.out.latest/index.iife.prod.js"
+
+
+def camel_to_kebab(name: str) -> str:
+    """myComponent / MyComponent / my_component -> my-component."""
+    name = name.strip().replace("_", "-")
+    # split camelCase / PascalCase boundaries
+    name = re.sub(r"([a-z0-9])([A-Z])", r"\1-\2", name)
+    name = re.sub(r"([A-Z]+)([A-Z][a-z])", r"\1-\2", name)
+    return name.lower()
+
+
+def component_tag(aura_id: str) -> str:
+    """c:myComponent -> c-my-component (namespace preserved)."""
+    aura_id = aura_id.strip()
+    if ":" in aura_id:
+        ns, name = aura_id.split(":", 1)
+    else:
+        ns, name = "c", aura_id
+    return f"{ns.strip().lower()}-{camel_to_kebab(name)}"
+
+
+def library_url(my_domain: str) -> str:
+    """Normalize a My Domain to the versioned LO 2.0 library URL."""
+    d = my_domain.strip().rstrip("/")
+    if not d.startswith("http"):
+        d = "https://" + d
+    # Beta hosts on *.lightning.force.com; LO 2.0 must load from *.my.salesforce.com
+    d = d.replace(".lightning.force.com", ".my.salesforce.com")
+    # strip any path the caller pasted, keep scheme://host
+    m = re.match(r"(https?://[^/]+)", d)
+    host = m.group(1) if m else d
+    return f"{host}{LO2_LIBRARY_PATH}"
+
+
+def main(argv=None) -> int:
+    p = argparse.ArgumentParser(description=__doc__,
+                                formatter_class=argparse.RawDescriptionHelpFormatter)
+    p.add_argument("--component", help="Beta component id, e.g. c:myComponent")
+    p.add_argument("--attributes",
+                   help="comma/space separated camelCase attribute names")
+    p.add_argument("--my-domain",
+                   help="org My Domain or Beta host URL")
+    args = p.parse_args(argv)
+
+    if not (args.component or args.attributes or args.my_domain):
+        p.print_help()
+        return 2
+
+    if args.component:
+        print(f"component-tag: <{component_tag(args.component)}>")
+
+    if args.attributes:
+        raw = [a for a in re.split(r"[,\s]+", args.attributes) if a]
+        pairs = [(a, camel_to_kebab(a)) for a in raw]
+        print("attributes:")
+        for src, dst in pairs:
+            print(f"  {src} -> {dst}")
+
+    if args.my_domain:
+        print(f"library-url: {library_url(args.my_domain)}  (add the `async` attribute)")
+
+    return 0
+
+
+if __name__ == "__main__":
+    sys.exit(main())

package/skills/experience-lwc-legacy-migrate/scripts/validate-lo20-page.py

@@ -0,0 +1,133 @@
+#!/usr/bin/env python3
+"""Mechanically validate a migrated Lightning Out 2.0 host page.
+
+The six non-negotiable LO 2.0 rules (Workflow B, Step B4) plus the core
+library/component checklist items are all *deterministic code-structure*
+checks. This script runs them against a migrated HTML host page so the
+workflow gates on a repeatable pass/fail instead of prose interpretation.
+
+Usage:
+  python3 scripts/validate-lo20-page.py <path-to-migrated.html>
+
+Prints one PASS/FAIL line per rule. Exits 0 only when every rule passes;
+exits 1 if any rule fails, 2 on a usage/IO error.
+"""
+import re
+import sys
+
+
+def check(src: str):
+    """Return a list of (ok: bool, label: str, detail: str)."""
+    results = []
+
+    def add(ok, label, detail=""):
+        results.append((ok, label, detail))
+
+    # --- Library / Beta removal -------------------------------------------
+    # Locate the versioned library path, then scan back to the opening
+    # <script to check for `async`. We do NOT isolate the tag with [^>]*
+    # because placeholder URLs like https://<DOMAIN>.my.salesforce.com
+    # legitimately contain a '>' inside the attribute value.
+    lib_path = "lightning.out.latest/index.iife.prod.js"
+    idx = src.find(lib_path)
+    has_lo2_lib = idx != -1
+    lib_async = False
+    if has_lo2_lib:
+        start = src.rfind("<script", 0, idx)
+        if start != -1:
+            lib_async = bool(re.search(r"\basync\b", src[start:idx]))
+    add(has_lo2_lib and lib_async, "LO 2.0 library script tag",
+        "must load .../lightning.out.latest/index.iife.prod.js with `async`")
+
+    beta_lib = bool(re.search(r"lightning\.force\.com/[^\"']*lightning\.out\.js", src))
+    beta_calls = bool(re.search(r"\$Lightning\.(use|createComponent)", src))
+    add(not beta_lib and not beta_calls, "No Lightning Out Beta remnants",
+        "no lightning.out.js / $Lightning.use / $Lightning.createComponent")
+
+    # --- Rule 1: customElements.whenDefined must use a literal string ------
+    wd = re.findall(r"customElements\.whenDefined\(\s*([^)]*?)\s*\)", src)
+    if not wd:
+        add(False, "Rule 1: whenDefined literal string",
+            "no customElements.whenDefined(...) call found")
+    else:
+        # Require the ENTIRE trimmed argument to be a single quoted string
+        # literal. A prefix-only check (starts with a quote) would let
+        # expressions like `'c-' + componentTag` slip through.
+        all_literal = all(
+            re.fullmatch(r"""(['"]).*?\1""", arg.strip()) for arg in wd)
+        add(all_literal, "Rule 1: whenDefined literal string",
+            "argument must be a quoted string, not the `components` variable")
+
+    # --- Rule 2: mountLo20 declared with two parameters -------------------
+    decl = re.search(r"function\s+mountLo20\s*\(([^)]*)\)", src)
+    if not decl:
+        add(False, "Rule 2: mountLo20(frontdoorUrl, orgUrl)",
+            "no `function mountLo20(...)` declaration found")
+    else:
+        params = [p for p in decl.group(1).split(",") if p.strip()]
+        add(len(params) == 2, "Rule 2: mountLo20(frontdoorUrl, orgUrl)",
+            f"declaration has {len(params)} parameter(s), expected 2")
+
+    # --- Rule 3: clearCachedResult present (called before mounting) -------
+    add(bool(re.search(r"clearCachedResult\s*\(", src)),
+        "Rule 3: clearCachedResult() before mount",
+        "clearCachedResult() must run before every mountLo20() call")
+
+    # --- Rule 4: every mountLo20 call passes two arguments ----------------
+    calls = re.findall(r"(?<!function\s)\bmountLo20\s*\(([^)]*)\)", src)
+    # Count args for EVERY call site (the declaration is excluded by the
+    # lookbehind). Do NOT skip empty argument lists: a zero-arg
+    # `mountLo20()` has an arg count of 0, which is != 2 and must fail.
+    bad_calls = [c for c in calls
+                 if len([a for a in c.split(",") if a.strip()]) != 2]
+    add(len(bad_calls) == 0, "Rule 4: mountLo20 calls pass two args",
+        f"{len(bad_calls)} call(s) do not pass exactly two arguments")
+
+    # --- Rule 5: boot() wrapper defined and invoked -----------------------
+    boot_def = bool(re.search(r"function\s+boot\s*\(", src))
+    boot_call = bool(re.search(r"(?<!function\s)\bboot\s*\(\s*\)", src))
+    add(boot_def and boot_call, "Rule 5: boot() wrapper",
+        "define function boot() and call boot() once at the end")
+
+    # --- Rule 6: component tag has no inline display style ----------------
+    comp_tags = re.findall(r"<c-[a-z0-9-]+[^>]*>", src)
+    add(len(comp_tags) > 0, "Component tag present",
+        "expected a <c-...> custom element in the HTML")
+    inline_hidden = any(re.search(r"style\s*=\s*['\"][^'\"]*display\s*:\s*none",
+                                  t) for t in comp_tags)
+    add(not inline_hidden, "Rule 6: no inline display:none on component tag",
+        "control visibility via the loading indicator, not the component tag")
+
+    return results
+
+
+def main(argv=None) -> int:
+    argv = argv if argv is not None else sys.argv[1:]
+    if len(argv) != 1:
+        print("usage: validate-lo20-page.py <path-to-migrated.html>",
+              file=sys.stderr)
+        return 2
+    try:
+        with open(argv[0], "r", encoding="utf-8") as fh:
+            src = fh.read()
+    except OSError as e:
+        print(f"error: cannot read {argv[0]}: {e}", file=sys.stderr)
+        return 2
+
+    results = check(src)
+    failed = 0
+    for ok, label, detail in results:
+        mark = "PASS" if ok else "FAIL"
+        line = f"[{mark}] {label}"
+        if not ok and detail:
+            line += f" -- {detail}"
+        print(line)
+        if not ok:
+            failed += 1
+
+    print(f"\n{len(results) - failed}/{len(results)} checks passed")
+    return 0 if failed == 0 else 1
+
+
+if __name__ == "__main__":
+    sys.exit(main())

package/skills/experience-ui-bundle-app-coordinate/SKILL.md

@@ -163,16 +163,16 @@ Search project code (src/) for existing implementations
     v
 Install dependencies (npm install)
     v
-Search, describe, and install features (auth, shadcn, search, navigation, GraphQL)
+Search, describe, and adopt features (auth, shadcn, search, navigation, GraphQL)
     v
 Resolve conflicts (two-pass: --on-conflict error, then --conflict-resolution)
     v
 Integrate __examples__ files into target files (verify build succeeds), then delete them
 ```
 
-Installs pre-built, tested feature packages. See "Prompt Classification Keywords" above for the full trigger keyword list and negative-phrasing handling — these features provide the foundation that UI components build on top of.
+Loads the feature skill to install pre-built packages, or adopt ones the template already shipped — never build your own version of a catalog feature. See "Prompt Classification Keywords" for triggers and negative-phrasing handling.
 
-Only skip this phase if the app is truly a minimal "hello world" with no interactive features (no trigger keywords present at all).
+Skip only for a minimal "hello world" with no interactive features; pre-shipped features still require this phase.
 
 ### Phase 2.5: Custom Objects (Required if the prompt requires a new custom Salesforce object the org doesn't have)
 
@@ -378,14 +378,14 @@ Execute each phase sequentially following the standard pattern in `references/ph
 ---
 
 **Phase 0 -- Template Offer & Bootstrap**
-- Load `experience-ui-bundle-project-generate`, offer templates. If chosen: skip Phase 1, continue at Phase 4. If declined: run `scripts/check-sfdx-project.sh`, create project if missing.
+- Load `experience-ui-bundle-project-generate`, offer templates. If chosen: skip Phase 1, continue at Phase 2. If declined: run `scripts/check-sfdx-project.sh`, create project if missing.
 
 **Phase 1 -- Scaffolding** (skip if template used in Phase 0)
 - **Precondition**: `scripts/check-sfdx-project.sh` passes
 - Load `experience-ui-bundle-metadata-generate`. Determine hosting target FIRST. Run `sf template generate ui-bundle --template reactbasic`, configure meta XML with `<target>`.
 - **Post-verification**: `scripts/check-phase-1-complete.sh` passes
 
-**Phase 2 -- Features** (skip if no feature keywords present — see "Prompt Classification Keywords")
+**Phase 2 -- Features** (run on any feature keyword, even if pre-installed — see "Prompt Classification Keywords")
 - Load `experience-ui-bundle-features-generate`. Install features, integrate examples. Verify with `npm run build`.
 
 **Phase 2.5 -- Custom Objects** (skip if org has all needed objects)

package/skills/experience-ui-bundle-features-generate/SKILL.md

@@ -1,8 +1,8 @@
 ---
 name: experience-ui-bundle-features-generate
-description: "MUST activate when the project contains a uiBundles/*/src/ directory and the user wants to add a pre-built feature — such as authentication (login, logout, protected routes, session management) or search (global search across pages and content) — instead of building it from scratch. Always run list first to see the current feature catalog, since it can include more than authentication and search. Always use this skill for installing pre-built features rather than hand-building them. DO NOT TRIGGER for Agentforce conversational client or file-upload features — use experience-ui-bundle-agentforce-client-generate and experience-ui-bundle-file-upload-generate respectively."
+description: "MUST activate when the project contains a uiBundles/*/src/ directory (React or Angular) and the user wants to add a pre-built feature — such as authentication (login, logout, protected routes, session management) or search (global search across pages and content) — instead of building it from scratch. Always run list first to see the current feature catalog, since it can include more than authentication and search. Always use this skill for installing pre-built features rather than hand-building them. DO NOT TRIGGER for Agentforce conversational client or file-upload features — use experience-ui-bundle-agentforce-client-generate and experience-ui-bundle-file-upload-generate respectively."
 metadata:
-  version: "1.1"
+  version: "1.2"
   domains: ["Experience"]
   relatedSkills: ["experience-ui-bundle-agentforce-client-generate", "experience-ui-bundle-file-upload-generate"]
   cliTools:
@@ -19,41 +19,79 @@ metadata:
 
 # UI Bundle Features
 
-## Installing Pre-built Features
+Install pre-built, tested feature packages into a Salesforce UI bundle with the
+`@salesforce/ui-bundle-features` CLI instead of hand-building them. This file is the
+**framework-neutral workflow spine**; the framework-specific detail — example file
+extensions, the files features rewrite, how a feature's entry component is mounted, and the
+build command — lives in a per-framework reference under `<SKILL_DIR>/references/<framework>/`.
 
-Always check for an existing feature before building something from scratch. The features CLI installs pre-built, tested packages into Salesforce UI bundles — from foundational UI libraries (shadcn/ui) to full-stack capabilities. Authentication and search are the most commonly used features today; run `list --verbose` for the full current catalog, since it can grow over time.
+Always check for an existing feature before building something from scratch. The CLI is
+framework-agnostic: it installs the framework-appropriate variant of each feature into the
+detected bundle. Authentication and search are the most commonly used today; run
+`list --verbose` for the full current catalog, since it can grow over time.
 
 > **Ownership note:** Agentforce AI conversation clients and file-upload are owned by separate skills (`experience-ui-bundle-agentforce-client-generate`, `experience-ui-bundle-file-upload-generate`). If the catalog also lists an Agentforce or file-upload entry, do not install it from both places — confirm with the user which delivery path they want, and never install the same capability twice in one bundle.
 
 > **Package name:** `@salesforce/ui-bundle-features` is the canonical package name. Some older templates/samples still reference the deprecated `@salesforce/ui-bundle-features-experimental` name — never use the `-experimental` suffix. If a command fails to resolve, confirm the published version with `npm view @salesforce/ui-bundle-features version` before assuming the package name is wrong.
 
-### Workflow
+## Step 0: Determine the framework
 
-0. **Confirm this is a React UI bundle** — this CLI copies into `src/features/` and expects `npm run build` to work. Non-React bundles are not supported and will fail late in the install.
+`<SKILL_DIR>` = the absolute path to **this skill's own directory** (the folder holding this
+`SKILL.md`); resolve it from the skill path in context.
 
-   Run `scripts/verify-react-bundle.sh`. If it exits non-zero, stop — the bundle is not React-based and this skill cannot proceed.
+The framework is normally already decided by the calling context — passed down by the
+coordinator skill that invoked this one, or stated in the user's request. Use that.
+
+The frameworks this skill supports are exactly the reference folders under
+`<SKILL_DIR>/references/`, each containing a `features.md` (so `react` →
+`<SKILL_DIR>/references/react/features.md`). This is the single source of truth — adding a
+framework means adding a reference folder, nothing here changes.
+
+- **If the framework is known** — open `<SKILL_DIR>/references/<framework>/features.md` and
+  keep it alongside this spine. It supplies the example extensions, the integration targets,
+  the mount example, and the build command.
+- **If it is unknown** (a standalone run where nobody said which) — run the deterministic
+  detector on the UI bundle root before asking anyone:
+
+  ```bash
+  bash "<SKILL_DIR>/scripts/detect-framework.sh" "<path-to-uiBundles/<name>/ dir>"
+  ```
+
+  Branch on the exit code (do not parse prose):
+  - `react` or `angular` (exit 0) → use that framework. **Do not ask the user** — detection is
+    deterministic. Open `<SKILL_DIR>/references/<framework>/features.md`.
+  - `ambiguous` (exit 2) → both frameworks present. List `<SKILL_DIR>/references/` and ask the
+    user which bundle to install into. If they name a framework with no matching reference
+    folder, it is not supported here — stop.
+  - `unknown` (exit 3) → **no supported framework detected. Terminate.** Report that neither
+    React nor Angular signals were found in the bundle, so features cannot be installed, and
+    stop. Do not guess.
+
+Throughout the steps below, `<framework>` means the folder chosen here.
+
+## Workflow
 
 1. **Search project code first** — check `src/` for existing implementations before installing anything. Scope searches to `src/` to avoid matching `node_modules/` or `dist/`.
 
 2. **Search available features** — use `npx @salesforce/ui-bundle-features list` with `--search <query>` to filter by keyword. Use `--verbose` for full descriptions.
 
-3. **Describe a feature — MANDATORY before wiring.** Run `npx @salesforce/ui-bundle-features describe <feature>` and read the feature's README via `npm view <package> readme` (using the `Package:` name from that output) before wiring it. The README is the contract: it tells you how the feature is meant to be wired — including any drop-in entry component and the file each integration example belongs in. Cross-check against the copied-in source under `describe`'s `Copy Operations` destination — that source (and its JSDoc) is the version-matched truth for what's actually installed. Do not wire from assumptions about file names or component APIs. Skipping this is the most common reason a feature installs successfully but never actually runs.
+3. **Describe a feature — MANDATORY before wiring.** Run `npx @salesforce/ui-bundle-features describe <feature>` and read the feature's README via `npm view <package> readme` (using the `Package:` name from that output) before wiring it. The README is the contract: it tells you how the feature is meant to be wired — including any drop-in entry component and the file each integration example belongs in. Cross-check against the copied-in source under `describe`'s `Copy Operations` destination — that source (and its JSDoc/comments) is the version-matched truth for what's actually installed, in the detected framework's file types. Do not wire from assumptions about file names or component APIs. Skipping this is the most common reason a feature installs successfully but never actually runs.
 
 4. **Install** — use `npx @salesforce/ui-bundle-features install <feature> --ui-bundle-dir <name>`. Key options:
    - `--dry-run` to preview changes
    - `--yes` for non-interactive mode (skips conflicts)
    - `--on-conflict error` to detect conflicts, then `--conflict-resolution <file>` to resolve them
 
-   Install features **before** doing custom frontend/layout work in this bundle — features may rewrite `appLayout.tsx`/`routes.tsx`, and installing after hand-built layout changes risks collisions.
+   Install features **before** doing custom frontend/layout work in this bundle — features may rewrite the app layout and routing files (see the framework reference for their names), and installing after hand-built layout changes risks collisions.
 
 If no matching feature is found, ask the user before building a custom implementation — a relevant feature may exist under a different name.
 
-### Conflict Handling
+## Conflict Handling
 
 In non-interactive environments, use the two-pass approach:
 
 1. Run install with `--on-conflict error` to detect conflicts without applying them.
-2. Before writing the resolution file, read `references/conflict-resolution-schema.json` for the allowed keys and enum values.
+2. Before writing the resolution file, read `references/common/conflict-resolution-schema.json` for the allowed keys and enum values.
 3. Write a resolution file at `<ui-bundle-dir>/conflict-resolution.json` (path is relative to the UI bundle directory being installed into, not the repo root). Key it by the exact paths the CLI printed as conflicts in pass 1, verbatim:
    ```json
    {
@@ -61,59 +99,52 @@ In non-interactive environments, use the two-pass approach:
      "src/routes.tsx": "skip"
    }
    ```
-   Any conflicting path *not* listed in this file defaults to `skip` — the CLI will not overwrite a file you didn't explicitly mark `overwrite`.
+   (The conflict paths are whatever the CLI printed for the detected framework — the keys above are illustrative.) Any conflicting path *not* listed defaults to `skip` — the CLI will not overwrite a file you didn't explicitly mark `overwrite`.
 4. Re-run install with `--conflict-resolution <path-to-that-file>`.
 
-### Post-install: Integrating Example Files
+## Post-install: Integrating Example Files
 
-Features may include example files under an `__examples__/` directory (plural) showing integration patterns. These are often full, working pages with concrete names (e.g. `AccountSearch.tsx`), not bare placeholder templates. For each:
+Features may include example files under an `__examples__/` directory (plural) showing integration patterns. These are often full, working pages with concrete names, not bare placeholder templates — in the detected framework's file types (see the framework reference). For each:
 
 1. Read the example file to understand the pattern — treat it as a working reference implementation, not necessarily a stub.
 2. Read the target file (shown in `describe` output).
 3. Apply the pattern from the example into the target.
 4. **CRITICAL — verify before deleting:**
    ```bash
-   # Verify the build passes with the integrated pattern
+   # Verify the build passes with the integrated pattern (build command per framework reference)
    npm run build || {
      echo "ERROR: Build failed after integration - do NOT delete __examples__/"
      exit 1
    }
-   
-   # Verify the pattern from the example is actually present in the target
-   # (adjust grep pattern to match a key symbol/import/component from the example)
-   # Example: for SearchInput pattern integrated into AccountSearch.tsx
-   grep -q "SearchInput\|useSearch" src/pages/*.tsx src/components/*.tsx 2>/dev/null || {
-     echo "ERROR: Pattern from example not found in target files - integration incomplete"
-     echo "Do NOT delete __examples__/ until the pattern is confirmed present"
-     exit 1
-   }
-   
-   # Only delete after both checks pass
-   rm -rf __examples__/
+
+   # Verify the pattern from the example is actually present in the target.
+   # Adjust the grep to a key symbol/import/component from the example, over the
+   # detected framework's source files (see the framework reference for a worked pattern).
    ```
+   Only delete `__examples__/` after **both** the build passes and the pattern is confirmed present in the target.
 
 If either check fails, **do NOT delete `__examples__/`** — the integration is incomplete. Fix the integration first, then re-run the verification.
 
-### Post-install: Mount the OOTB component, don't hand-roll a parallel one
+## Post-install: Mount the OOTB component, don't hand-roll a parallel one
 
-When a feature ships an integration point, the UI **must** use it rather than a parallel hand-rolled version. For features that ship an entry component, mount it — e.g. for search, mount the feature's `<Search>` on the search-results page; do **not** author a bespoke results page that queries data directly (a custom `SearchResults.tsx` against seed data or a raw GraphQL call bypasses the installed, tested feature, so the deployed sObject/CMS search never runs). The only exception is when the user **explicitly** opts out and asks for a custom one — confirm that intent, don't infer it.
+When a feature ships an integration point, the UI **must** use it rather than a parallel hand-rolled version. For features that ship an entry component, mount it (the framework reference shows the mount idiom); do **not** author a bespoke page that queries data directly. A custom results page against seed data or a raw GraphQL call bypasses the installed, tested feature, so the deployed sObject/CMS logic never runs. The only exception is when the user **explicitly** opts out and asks for a custom one — confirm that intent, don't infer it.
 
-### Hint Placeholders
+## Hint Placeholders
 
 Some copy paths use `<descriptive-name>` placeholders (e.g., `<desired-page-with-search-input>`) that the CLI does not resolve. After installation, rename or relocate these files to the intended target, or integrate their patterns into an existing file. This is separate from the `__examples__/` convention above — a single copy path can use either mechanism.
 
-### Auth Feature: Org-Side Prerequisites
+## Auth Feature: Org-Side Prerequisites
 
-Installing the authentication feature only copies files — it does not configure the org. Before telling the user auth is done, flag that these org-side steps still need to happen (outside this skill's scope, but required for the feature to actually work):
+Installing the authentication feature only copies files — it does not configure the org. This is framework-agnostic (pure org/metadata config). Before telling the user auth is done, flag that these org-side steps still need to happen (outside this skill's scope, but required for the feature to actually work):
 
 - Digital Experiences (Experience Cloud) must be enabled, with Customer Community / Customer Community Plus licenses assigned to the relevant users, and Salesforce Sites enabled.
 - The community and guest profiles need explicit Apex class access granted for the auth utility, login/registration, and password-reset classes — the CLI does not grant this automatically.
 - Guest-profile sharing rules / org-wide defaults for any objects the auth flow touches.
 - **Known limitation:** logout has a documented CSRF-handling gap (tracked as W-21253864) — call this out to the user rather than presenting logout as fully solved.
 
-### CRITICAL: Resolve `<sfdxRoot>` After Every Install
+## CRITICAL: Resolve `<sfdxRoot>` After Every Install
 
-The CLI may copy files under a literal `<sfdxRoot>` folder — an unresolved placeholder for this project's Salesforce DX metadata root (from `sfdx-project.json`'s `packageDirectories[].path`, e.g. `force-app/main/default`). Files left there are undeployable.
+The CLI may copy files under a literal `<sfdxRoot>` folder — an unresolved placeholder for this project's Salesforce DX metadata root (from `sfdx-project.json`'s `packageDirectories[].path`, e.g. `force-app/main/default`). Files left there are undeployable. This is framework-agnostic.
 
 **After every install:**
 ```bash
@@ -123,5 +154,3 @@ If found, move each file to `<metadata-root>/<same-relative-subpath>` (keep `-me
 
 **Verification:**
 - [ ] Re-run `find uiBundles/<AppName> -type d -regex '.*/<[^/]+>$'` — output must be empty before proceeding.
-
-

package/skills/experience-ui-bundle-features-generate/references/angular/features.md

@@ -0,0 +1,74 @@
+# Angular UI Bundle Features
+
+Framework reference for the **Angular** path of `experience-ui-bundle-features-generate`. Read
+this alongside the workflow spine in `SKILL.md`. The `@salesforce/ui-bundle-features` CLI
+installs the Angular variant of each feature into an Angular UI bundle (an `angular.json` at/
+above the bundle, `@angular/core` in `package.json`, standalone components as `.ts` + `.html`
+pairs under `src/app/`).
+
+## Example files
+
+Features ship integration examples under `__examples__/` as Angular sources — a standalone
+component is a **`.ts`** class + its **`.html`** template (e.g. `account-search.ts` +
+`account-search.html`), often full working pages, not bare stubs. Integrate the pattern into
+the target named in `describe` output, then verify before deleting the `__examples__/` dir.
+
+> Do not assume file names or a `.component` infix — Angular UI bundle starters name
+> components without it (`home.ts`, not `home.component.ts`). The `describe` `Copy Operations`
+> destination and the copied-in source are the version-matched truth for what was installed.
+
+## Files features may rewrite
+
+Angular features commonly touch app wiring:
+
+- `src/app/app.routes.ts` — route registration (route-based features add routes here)
+- `src/app/app.ts` + `src/app/app.html` — root component and its template
+- the app-layout component under `src/app/components/layout/` — the shell some features mount into
+
+These are the paths to expect as conflicts in the two-pass conflict flow; resolve them per
+`SKILL.md` → *Conflict Handling* (the exact paths are whatever the CLI prints).
+
+## Mount the feature's entry component
+
+Mount the OOTB component the feature ships rather than hand-rolling a parallel one. Angular
+mounts by **selector** (in a template) or by **route** (lazy-loaded standalone component) —
+use whichever `describe`/README specifies. For search mounted on a results page template:
+
+```html
+<!-- search-results.html — use the feature's selector; do NOT hand-roll a results page -->
+<sf-search />
+```
+
+Or as a route in `src/app/app.routes.ts`:
+
+```ts
+export const routes: Routes = [
+  { path: "search", loadComponent: () =>
+      import("./features/search/search").then((m) => m.Search) },  // path per describe output
+];
+```
+
+Import the feature's standalone component into whichever component's `imports:` array hosts it.
+
+## Build & verify
+
+Build command (run from the UI bundle dir):
+
+```bash
+npm run build
+```
+
+Worked grep for the *verify-before-delete* check — Angular splits usage across `.ts` (selector
+registration, service imports, route entry) and `.html` (the mounted selector). Adjust the
+symbol to one from the example you integrated:
+
+```bash
+grep -rq "sf-search\|SearchService" src/app --include='*.ts' --include='*.html' 2>/dev/null || {
+  echo "ERROR: Pattern from example not found in target files - integration incomplete"
+  echo "Do NOT delete __examples__/ until the pattern is confirmed present"
+  exit 1
+}
+```
+
+Only `rm -rf __examples__/` after the build passes **and** this grep confirms the pattern is
+present in the target.

package/skills/experience-ui-bundle-features-generate/references/react/features.md

@@ -0,0 +1,59 @@
+# React UI Bundle Features
+
+Framework reference for the **React** path of `experience-ui-bundle-features-generate`. Read
+this alongside the workflow spine in `SKILL.md`. The `@salesforce/ui-bundle-features` CLI
+installs the React variant of each feature into a React/Vite UI bundle (`"react"` in the
+bundle `package.json`, `.tsx` sources under `src/`).
+
+## Example files
+
+Features ship integration examples under `__examples__/` as **`.tsx`** files — often full,
+working pages with concrete names (e.g. `AccountSearch.tsx`), not bare stubs. Integrate the
+pattern into the target file named in `describe` output, then verify before deleting the
+`__examples__/` dir.
+
+## Files features may rewrite
+
+React features commonly touch the app shell and routing:
+
+- `src/appLayout.tsx` — the app layout/shell
+- `src/routes.tsx` — route registration
+- `src/App.tsx` — app entry (some features mount here)
+
+These are the paths to expect as conflicts in the two-pass conflict flow; resolve them per
+`SKILL.md` → *Conflict Handling* (the exact paths are whatever the CLI prints).
+
+## Mount the feature's entry component
+
+Mount the OOTB component the feature ships rather than hand-rolling a parallel one. For search,
+mount the feature's `<Search>` component (JSX) on the search-results page:
+
+```tsx
+import { Search } from "./features/search";      // path per describe output
+// ...
+export default function SearchResults() {
+  return <Search />;                              // do NOT hand-roll a results page
+}
+```
+
+## Build & verify
+
+Build command (run from the UI bundle dir):
+
+```bash
+npm run build
+```
+
+Worked grep for the *verify-before-delete* check (adjust the symbol to one from the example
+you integrated — here the `SearchInput`/`useSearch` pattern integrated into a page):
+
+```bash
+grep -q "SearchInput\|useSearch" src/pages/*.tsx src/components/*.tsx 2>/dev/null || {
+  echo "ERROR: Pattern from example not found in target files - integration incomplete"
+  echo "Do NOT delete __examples__/ until the pattern is confirmed present"
+  exit 1
+}
+```
+
+Only `rm -rf __examples__/` after the build passes **and** this grep confirms the pattern is
+present in the target.