@salesforce/afv-skills 1.12.0 → 1.14.0

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@salesforce/afv-skills",
-  "version": "1.12.0",
+  "version": "1.14.0",
   "description": "Salesforce skills for Agentforce Vibes",
   "license": "CC-BY-NC-4.0",
   "files": [
@@ -11,8 +11,8 @@
     "registry": "https://registry.npmjs.org"
   },
   "devDependencies": {
-    "@salesforce/ui-bundle-template-app-react-sample-b2e": "^1.120.6",
-    "@salesforce/ui-bundle-template-app-react-sample-b2x": "^1.120.6",
+    "@salesforce/ui-bundle-template-app-react-sample-b2e": "^10.2.2",
+    "@salesforce/ui-bundle-template-app-react-sample-b2x": "^10.2.2",
     "@salesforce/webapp-template-app-react-sample-b2e-experimental": "^1.117.1",
     "@salesforce/webapp-template-app-react-sample-b2x-experimental": "^1.117.1",
     "@types/js-yaml": "^4.0.9",

package/skills/building-mobile-apps/SKILL.md

@@ -0,0 +1,70 @@
+---
+name: building-mobile-apps
+description: "The entry point for building any Salesforce native mobile app on iOS or Android. TRIGGER when the user says: \"build a Salesforce iOS app\", \"add Salesforce login to my Android app\", \"set up Mobile SDK\", \"add MobileSync / SmartStore offline storage\", \"embed an Agentforce agent in my mobile app\", \"add Agentforce chat to iOS/Android\", or otherwise asks to create, extend, or integrate a Salesforce mobile experience in Swift or Kotlin (MSDK, Agentforce SDK, or both). SKIP when the user is building a non-Salesforce mobile app, using React Native / Flutter / Ionic without Salesforce integration, asking about generic mobile UI design, or working on a Salesforce-adjacent web/desktop surface (LWC, Experience Cloud, Mobile Publisher branding-only)."
+license: Apache-2.0
+metadata:
+  version: "1.0"
+---
+
+# Salesforce Mobile
+
+Route the user to the right SDK-family skill for building Salesforce-connected mobile apps. Do not implement features here; child skills own scenario detection and step-by-step instructions.
+
+## Before routing
+
+Disambiguate on two dimensions: **SDK family** (Mobile SDK vs. Agentforce SDK) and **platform** (iOS vs. Android). They are not mutually exclusive — an app can use both SDKs.
+
+If the user's intent could plausibly map to either SDK, ask before routing. Guessing wrong wastes the user's time because the child skills are platform- and SDK-specific.
+
+## Routing — which SDK family?
+
+| User's situation | SDK |
+|---|---|
+| Authenticating end users to Salesforce, syncing records (MobileSync), storing data offline (SmartStore), biometric login, push notifications, REST integration | **Mobile SDK** |
+| Embedding an Agentforce agent — chat UI, agent conversations, conversational features as the primary surface | **Agentforce SDK** |
+| Both (data-driven app with an embedded agent) | **Mobile SDK first**, then **Agentforce SDK** layered on top |
+
+### Tiebreakers when both seem to apply
+
+- Is the agent the *primary surface* (chat-first app), or a *feature inside* an otherwise data-driven app?
+  - Primary → Agentforce SDK
+  - Feature → Mobile SDK; embed the agent via Agentforce SDK alongside it
+- Are end users authenticating into Salesforce data?
+  - Yes → Mobile SDK is required (Agentforce SDK can be added on top).
+  - No → Agentforce SDK alone is likely sufficient (it uses guest auth).
+- Asking about offline storage, sync, REST, push, or biometrics? → Mobile SDK.
+- Asking about agent conversations, chat UI, or streaming responses? → Agentforce SDK.
+
+When still unclear, ask the user directly.
+
+## Routing — which platform?
+
+| Platform | Mobile SDK skill | Agentforce SDK skill |
+|---|---|---|
+| iOS (Swift) | `ios-mobile-sdk` | `integrate-agentforce-ios` |
+| Android (Kotlin) | `android-mobile-sdk` | `integrate-agentforce-android` |
+
+If the user wants both platforms, route to each child skill separately — they are independent.
+
+## Combined workflows (Mobile SDK + Agentforce SDK)
+
+When an app needs both:
+
+1. Route to the Mobile SDK platform skill first to scaffold and authenticate.
+2. Route to the Agentforce SDK platform skill to layer the agent surface.
+3. Treat each child skill's instructions as authoritative for its SDK; do not merge their steps. Each SDK owns its own auth setup, dependency installation order, and initialization sequence — interleaving them produces conflicting config and broken init order.
+
+This sequencing is the only multi-skill logic this skill owns. Everything else lives inside the child skills.
+
+## Loading a child skill
+
+Invoke the child skill by name through the harness. If it is not available locally, prompt the user to install it with `npx skills add <repo>`. If the user confirms (or has pre-authorized installs), run the command and load the child skill — do not make the user go figure out how to continue the workflow. If the user declines, stop and explain that the child skill owns the SDK's setup steps and the workflow cannot continue without it. Each child skill is published from a public repo:
+
+| Skill | Repo | Install command |
+|---|---|---|
+| `ios-mobile-sdk` | [`forcedotcom/SalesforceMobileSDK-Templates`](https://github.com/forcedotcom/SalesforceMobileSDK-Templates) → `skills/ios-mobile-sdk/` | `npx --yes skills add forcedotcom/SalesforceMobileSDK-Templates --skill ios-mobile-sdk --yes` |
+| `android-mobile-sdk` | [`forcedotcom/SalesforceMobileSDK-Templates`](https://github.com/forcedotcom/SalesforceMobileSDK-Templates) → `skills/android-mobile-sdk/` | `npx --yes skills add forcedotcom/SalesforceMobileSDK-Templates --skill android-mobile-sdk --yes` |
+| `integrate-agentforce-ios` | [`salesforce/AgentforceMobileSDK-iOS`](https://github.com/salesforce/AgentforceMobileSDK-iOS) → `skills/integrate-agentforce-ios/` | `npx --yes skills add salesforce/AgentforceMobileSDK-iOS --skill integrate-agentforce-ios --yes` |
+| `integrate-agentforce-android` | [`salesforce/AgentforceMobileSDK-Android`](https://github.com/salesforce/AgentforceMobileSDK-Android) → `skills/integrate-agentforce-android/` | `npx --yes skills add salesforce/AgentforceMobileSDK-Android --skill integrate-agentforce-android --yes` |
+
+After install, load the child skill and let it take over. Do not inline the child skill's content — the child skill owns scenario detection, prerequisites, and step-by-step instructions.

package/skills/building-ui-bundle-app/SKILL.md

@@ -3,7 +3,7 @@ name: building-ui-bundle-app
 description: "MUST activate when the user wants to build, create, or generate a React application, React app, web application, single-page application (SPA), or frontend application — even if no project files exist yet. MUST also activate when the project contains a uiBundles/*/src/ directory or sfdx-project.json and the prompt says create, build, construct, or generate a new app, site, or page from scratch — even if the prompt also describes visual styling. MUST also activate when the task spans more than one ui-bundle skill. Use this skill when building a complete app end-to-end. This is the orchestrator that coordinates scaffolding, features, data access, frontend UI, integrations, and deployment in the correct dependency order. Without it, phases execute out of order and the app breaks. Do NOT use for Lightning Experience apps with custom objects (use generating-lightning-app). Do NOT use for single-concern edits to an existing page (use building-ui-bundle-frontend)."
 metadata:
   version: "1.0"
-  related-skills: generating-ui-bundle-metadata, generating-ui-bundle-features, using-ui-bundle-salesforce-data, building-ui-bundle-frontend, implementing-ui-bundle-agentforce-conversation-client, implementing-ui-bundle-file-upload, deploying-ui-bundle, generating-ui-bundle-site
+  related-skills: generating-ui-bundle-metadata, generating-ui-bundle-features, using-ui-bundle-salesforce-data, building-ui-bundle-frontend, implementing-ui-bundle-agentforce-conversation-client, implementing-ui-bundle-file-upload, deploying-ui-bundle, generating-ui-bundle-site, generating-ui-bundle-custom-app
 ---
 
 # Building a UI Bundle App
@@ -126,7 +126,11 @@ Final UI bundle build (rebuilds with the deployed schema)
 
 Follows the canonical 7-step deployment sequence. Must deploy metadata before fetching schema. Must assign permissions before schema fetch.
 
-### Phase 7: Experience Site (Optional)
+### Phase 7: Hosting Target
+
+Choose **one** of the following based on the app's audience:
+
+#### Phase 7a: Experience Site (External)
 
 ```
 Resolve site properties (siteName, appDevName, etc.)
@@ -136,7 +140,21 @@ Generate site metadata (Network, CustomSite, DigitalExperience)
 Deploy site infrastructure
 ```
 
-Creates the Digital Experience site that hosts the UI bundle. Only needed when the user wants a public-facing or authenticated site URL.
+Creates the Digital Experience site that hosts the UI bundle. Use when the user wants a public-facing or authenticated site URL for external users.
+
+#### Phase 7b: Custom Application (Internal)
+
+```
+Resolve app properties (appName, appNamespace, appLabel)
+    v
+Generate CustomApplication metadata (applications/*.app-meta.xml)
+    v
+Add <target>CustomApplication</target> to .uibundle-meta.xml
+    v
+Deploy custom application
+```
+
+Creates a Custom Application entry in the Lightning App Launcher. Use when the app is for internal users accessing it within Lightning Experience.
 
 ---
 
@@ -184,7 +202,7 @@ INTEGRATIONS (if applicable):
 
 DEPLOYMENT:
 - Target org: [org alias if known]
-- Experience Site: [yes/no, site name if applicable]
+- Hosting target: [Experience Site / Custom Application / none]
 
 SKILL LOAD ORDER:
 1. generating-ui-bundle-metadata
@@ -194,7 +212,8 @@ SKILL LOAD ORDER:
 5a. implementing-ui-bundle-agentforce-conversation-client (if chat requested)
 5b. implementing-ui-bundle-file-upload (if file upload requested)
 6. deploying-ui-bundle
-7. generating-experience-react-site (if site requested)
+7a. generating-ui-bundle-site (if Experience Site requested -- external users)
+7b. generating-ui-bundle-custom-app (if Custom Application requested -- internal users)
 ```
 
 ### STEP 2: Per-Phase Execution
@@ -248,12 +267,18 @@ Execute each phase sequentially. Complete all steps within a phase before moving
 - 3. Verify: Confirm deployment succeeds and app is accessible
 - 4. Checkpoint: App deployed -- proceed to Phase 7 if needed
 
-**Phase 7 -- Experience Site** (skip if not requested)
-- 1. Load skill: Invoke `generating-experience-react-site`
+**Phase 7a -- Experience Site** (skip if not requested or if Custom Application chosen)
+- 1. Load skill: Invoke `generating-ui-bundle-site`
 - 2. Execute: Resolve properties, generate site metadata, deploy
 - 3. Verify: Confirm site URL is accessible
 - 4. Checkpoint: Site live -- build complete
 
+**Phase 7b -- Custom Application** (skip if not requested or if Experience Site chosen)
+- 1. Load skill: Invoke `generating-ui-bundle-custom-app`
+- 2. Execute: Resolve app properties, generate CustomApplication metadata, add CustomApplication target to meta XML
+- 3. Verify: Confirm app appears in App Launcher
+- 4. Checkpoint: App registered -- build complete
+
 ### STEP 3: Final Summary
 
 After all phases complete, present a build summary:
@@ -268,7 +293,7 @@ PHASES COMPLETED:
 [x] Phase 4: UI -- [count] pages, [count] components
 [x] Phase 5: Integrations -- [list or "none"]
 [x] Phase 6: Deployment -- deployed to [org]
-[x] Phase 7: Experience Site -- [site URL or "skipped"]
+[x] Phase 7: Hosting Target -- [Experience Site URL / Custom Application name / "skipped"]
 
 FILES GENERATED:
 [list key files and their paths]

package/skills/generating-custom-application/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: generating-custom-application
-description: "Use this skill when users need to create or configure Salesforce Custom Applications. Trigger when users mention custom apps, application metadata, app navigation, or organizing tabs into applications. Use when users want to create app containers for tabs and pages. Always use this skill for custom application work."
+description: "Use this skill when users need to create or configure tab-based Salesforce Custom Applications with navigation, branding, and action overrides. Trigger when users mention custom apps, application metadata, app navigation, or organizing tabs into applications. Use when users want to create app containers for tabs and pages. Do NOT use when the goal is hosting a React UI bundle in the App Launcher — use generating-ui-bundle-custom-app for that case."
 metadata:
   version: "1.0"
 ---

package/skills/generating-ui-bundle-custom-app/SKILL.md

@@ -0,0 +1,93 @@
+---
+name: generating-ui-bundle-custom-app
+description: "MUST activate when the project contains a uiBundles/*/src/ directory and the task involves creating or configuring a Custom Application for hosting a UI bundle in Lightning Experience. Use this skill when creating a CustomApplication metadata record to surface the UI bundle in the App Launcher. Activate when files matching applications/*.app-meta.xml exist and need modification, or when the user wants to expose their app via the Lightning App Launcher without a Digital Experience Site. Do NOT use generating-custom-application for this — UI bundle apps do not use tabs, action overrides, or flexipages."
+metadata:
+  version: "1.0"
+---
+
+# Custom Application for React UI Bundles
+Create and configure a Salesforce Custom Application that hosts a React UI bundle in Lightning Experience. This skill generates the CustomApplication metadata so the app appears in the Lightning App Launcher and can be accessed by internal users.
+
+Custom Applications differ from Experience Sites: they don't need Networks, CustomSite, DigitalExperienceConfig, or DigitalExperienceBundle metadata. The Custom Application acts as a thin launcher entry that delegates rendering to the React UI bundle referenced by `uiBundle`.
+
+## Required Properties
+Resolve all 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 |
+|----------|--------|----------------|
+| **appName** | `lowercamelcase` (e.g., `myInternalApp`) | The UI bundle name from `uiBundles/<name>/` directory |
+| **appNamespace** | String | `namespace` in `sfdx-project.json` → `sf data query -q "SELECT NamespacePrefix FROM Organization" --target-org ${usernameOrAlias}` → default `c` |
+| **appLabel** | Human-readable string | User-provided, or derive from appName by converting camelCase to Title Case |
+
+The `appNamespace` and `appName` connect the Custom Application to the correct React UI bundle. In newer API versions this uses `<uiBundle>{appNamespace}__{appName}</uiBundle>`; in older versions it uses `<webApplication>{appName}</webApplication>`. Getting this wrong means the app launcher entry exists but shows a blank page. Step 2 of the workflow determines which field to use.
+
+## Generation Workflow
+### Step 1: Resolve All Required Properties
+Determine values for all properties before constructing anything. Use the resolution strategies in the table above.
+
+### Step 2: Query API Context (Version-Aware Field Discovery)
+Call `salesforce-api-context` MCP tools to discover which fields exist for the target org's API version. This ensures the generated metadata is compatible with the user's Salesforce version.
+
+**Required calls:**
+1. Call `get_metadata_type_fields` for `CustomApplication` — check whether the `uiBundle` field exists
+2. Call `get_metadata_type_fields` for `UIBundle` — check whether the `target` field exists
+
+**Field resolution based on API response:**
+
+| Field Check | If present | If absent (older API version) |
+|-------------|-----------|-------------------------------|
+| `CustomApplication.uiBundle` | Use `<uiBundle>{appNamespace}__{appName}</uiBundle>` | Use `<webApplication>{appName}</webApplication>` (no namespace) |
+| `UIBundle.target` | Use `<target>CustomApplication</target>` | Omit the `<target>` element entirely |
+
+If `salesforce-api-context` is unavailable after a real attempt, fall back to the newer field names (`uiBundle` + `target`).
+
+### Step 3: Create the Project Structure
+Create any files and directories that don't already exist:
+
+| Metadata Type | Path |
+|--------------|------|
+| CustomApplication | `<sourceDir>/applications/{appName}.app-meta.xml` |
+
+**Note:** `<sourceDir>` is determined from `sfdx-project.json`. Read `packageDirectories[]` and use the entry where `"default": true`; the full source directory is `<path>/main/default`. If no default is set, use the first entry. Commonly `force-app/main/default`, but this path is configurable.
+
+### Step 4: Populate All Metadata Fields
+Use the default template in the doc below. Values in `{braces}` are resolved property references — substitute them with the actual values from Step 1. Apply the field resolution from Step 2 to determine which XML elements to use.
+
+| Metadata Type | Template Reference |
+|--------------|-------------------|
+| CustomApplication | [configure-metadata-custom-application.md](docs/configure-metadata-custom-application.md) |
+
+### Execution Note for Step 4: Load and use the doc
+- Agents MUST read the full contents of the docs/*.md file referenced in Step 4 before attempting to populate metadata fields.
+- Read the file in full, replace placeholders (e.g. `{appName}`) with the resolved values, then use the expanded template to populate the metadata XML content.
+- If Step 2 determined the older field names apply, substitute `<uiBundle>` with `<webApplication>` in the generated output.
+
+### Step 5: Update UI Bundle Meta XML
+If Step 2 confirmed the `target` field exists on `UIBundle`, add `<target>CustomApplication</target>` to the `.uibundle-meta.xml` file (skip if the field doesn't exist in the org's API version):
+
+```xml
+<?xml version="1.0" encoding="UTF-8"?>
+<UIBundle xmlns="http://soap.sforce.com/2006/04/metadata">
+    <masterLabel>{appName}</masterLabel>
+    <description>A Salesforce UI Bundle.</description>
+    <isActive>true</isActive>
+    <version>1</version>
+    <target>CustomApplication</target>
+</UIBundle>
+```
+
+### Step 6: Do Not Modify Non-Templated Properties
+Do not modify any default property values for `CustomApplication` metadata that are not expressed as variables wrapped in `{braces}`.
+
+## Verification Checklist
+Before deploying, confirm:
+
+- [ ] All required properties are resolved
+- [ ] API context was queried to determine available fields (Step 2)
+- [ ] `applications/{appName}.app-meta.xml` exists with correct content
+- [ ] The bundle reference field matches the org's API version (`<uiBundle>` or `<webApplication>`)
+- [ ] If `target` field is supported: `.uibundle-meta.xml` has `<target>CustomApplication</target>`
+- [ ] Deployment validates successfully:
+```bash
+sf project deploy validate --metadata CustomApplication UIBundle --target-org ${usernameOrAlias}
+```

package/skills/generating-ui-bundle-custom-app/docs/configure-metadata-custom-application.md

@@ -0,0 +1,70 @@
+# Configure Metadata: CustomApplication
+
+## Purpose
+This configuration file creates a **net-new, default** CustomApplication metadata record for a Lightning Experience app that hosts a React UI bundle. It is not intended to edit or modify an existing CustomApplication record. Use this template only when provisioning a brand-new Custom Application for a UI bundle.
+
+## File Location
+```
+<sourceDir>/applications/{appName}.app-meta.xml
+```
+
+**Note:** Determine `<sourceDir>` from `sfdx-project.json` → `packageDirectories[]` → find the entry with `"default": true` → use its `path` value + `/main/default`. Commonly `force-app/main/default`, but this is configurable.
+
+## Default Template (newer API versions — `uiBundle` field available)
+```xml
+<?xml version="1.0" encoding="UTF-8"?>
+<CustomApplication xmlns="http://soap.sforce.com/2006/04/metadata">
+    <brand>
+        <headerColor>#0070D2</headerColor>
+        <shouldOverrideOrgTheme>false</shouldOverrideOrgTheme>
+    </brand>
+    <formFactors>Small</formFactors>
+    <formFactors>Large</formFactors>
+    <isNavAutoTempTabsDisabled>false</isNavAutoTempTabsDisabled>
+    <isNavPersonalizationDisabled>false</isNavPersonalizationDisabled>
+    <isNavTabPersistenceDisabled>false</isNavTabPersistenceDisabled>
+    <isOmniPinnedViewEnabled>false</isOmniPinnedViewEnabled>
+    <label>{appLabel}</label>
+    <navType>Standard</navType>
+    <uiBundle>{appNamespace}__{appName}</uiBundle>
+    <uiType>Lightning</uiType>
+</CustomApplication>
+```
+
+## Fallback Template (older API versions — `uiBundle` field NOT available)
+```xml
+<?xml version="1.0" encoding="UTF-8"?>
+<CustomApplication xmlns="http://soap.sforce.com/2006/04/metadata">
+    <brand>
+        <headerColor>#0070D2</headerColor>
+        <shouldOverrideOrgTheme>false</shouldOverrideOrgTheme>
+    </brand>
+    <formFactors>Small</formFactors>
+    <formFactors>Large</formFactors>
+    <isNavAutoTempTabsDisabled>false</isNavAutoTempTabsDisabled>
+    <isNavPersonalizationDisabled>false</isNavPersonalizationDisabled>
+    <isNavTabPersistenceDisabled>false</isNavTabPersistenceDisabled>
+    <isOmniPinnedViewEnabled>false</isOmniPinnedViewEnabled>
+    <label>{appLabel}</label>
+    <navType>Standard</navType>
+    <webApplication>{appName}</webApplication>
+    <uiType>Lightning</uiType>
+</CustomApplication>
+```
+
+## Field Reference
+
+| Field | Required | Version | Description |
+|-------|----------|---------|-------------|
+| `brand.headerColor` | Yes | All | Hex color for the app header bar in Lightning Experience. Default: `#0070D2` (Salesforce blue). |
+| `brand.shouldOverrideOrgTheme` | Yes | All | Whether this app's branding overrides the org theme. Default: `false`. |
+| `formFactors` | Yes | All | Supported form factors. Include both `Small` (mobile) and `Large` (desktop) for full coverage. |
+| `isNavAutoTempTabsDisabled` | Yes | All | Disable auto-creation of temporary tabs. Default: `false`. |
+| `isNavPersonalizationDisabled` | Yes | All | Disable user personalization of navigation. Default: `false`. |
+| `isNavTabPersistenceDisabled` | Yes | All | Disable persistence of nav tabs across sessions. Default: `false`. |
+| `isOmniPinnedViewEnabled` | Yes | All | Enable Omni-channel pinned view. Default: `false`. |
+| `label` | Yes | All | Human-readable label shown in the App Launcher and app switcher. |
+| `navType` | Yes | All | Navigation type. Use `Standard` for standard Lightning navigation. |
+| `uiBundle` | Conditional | Newer | Namespace-qualified developer name of the UI bundle (`{appNamespace}__{appName}`). Use when `get_metadata_type_fields` confirms this field exists on `CustomApplication`. |
+| `webApplication` | Conditional | Older | Developer name of the UI bundle (`{appName}`, no namespace). Use when `uiBundle` field is not available. |
+| `uiType` | Yes | All | UI framework type. Must be `Lightning` for UI bundle apps. |

package/skills/generating-ui-bundle-metadata/SKILL.md

@@ -24,6 +24,7 @@ After generation:
 1. Replace all default boilerplate — "React App", "Vite + React", default `<title>`, placeholder text
 2. Populate the home page with real content (landing section, banners, hero, navigation)
 3. Update navigation and placeholders (see the `building-ui-bundle-frontend` skill)
+4. **Configure a hosting target** — a UI bundle without a `<target>` in its meta XML will not be visible in the org. Use `generating-ui-bundle-custom-app` for internal (App Launcher) apps or `generating-ui-bundle-site` for external (Experience Site) apps.
 
 Always install dependencies before running any scripts in the UI bundle directory.
 
@@ -39,7 +40,44 @@ A UIBundle bundle lives under `uiBundles/<AppName>/` and must contain:
 ### Meta XML
 
 Required fields: `masterLabel`, `version` (max 20 chars), `isActive` (boolean).
-Optional: `description` (max 255 chars).
+Optional: `description` (max 255 chars), `target`.
+
+#### Target Field
+
+The `<target>` element specifies where the UI bundle is hosted:
+
+| Value | Use Case | Companion Metadata |
+|-------|----------|-------------------|
+| `Experience` | External-facing site via Digital Experience | Network, CustomSite, DigitalExperienceConfig, DigitalExperienceBundle |
+| `CustomApplication` | Internal app via Lightning App Launcher | CustomApplication (`applications/*.app-meta.xml`) |
+
+A `<target>` is **required** for the app to be accessible in a Salesforce org. A UI bundle deployed without a target will not appear anywhere — no App Launcher entry, no Experience Site URL. Always pair the bundle with one of:
+- `generating-ui-bundle-site` (for `Experience` target)
+- `generating-ui-bundle-custom-app` (for `CustomApplication` target)
+
+**Example with Experience target:**
+```xml
+<?xml version="1.0" encoding="UTF-8"?>
+<UIBundle xmlns="http://soap.sforce.com/2006/04/metadata">
+    <masterLabel>propertyrentalapp</masterLabel>
+    <description>A Salesforce UI Bundle.</description>
+    <isActive>true</isActive>
+    <version>1</version>
+    <target>Experience</target>
+</UIBundle>
+```
+
+**Example with CustomApplication target:**
+```xml
+<?xml version="1.0" encoding="UTF-8"?>
+<UIBundle xmlns="http://soap.sforce.com/2006/04/metadata">
+    <masterLabel>propertymanagementapp</masterLabel>
+    <description>A Salesforce UI Bundle.</description>
+    <isActive>true</isActive>
+    <version>1</version>
+    <target>CustomApplication</target>
+</UIBundle>
+```
 
 ### ui-bundle.json
 

package/skills/reviewing-lwc-mobile-offline/SKILL.md

@@ -0,0 +1,168 @@
+---
+name: reviewing-lwc-mobile-offline
+description: "Review a Lightning Web Component for **mobile offline** compatibility — the Komaci offline static analyzer that pre-primes the data graph for Salesforce Mobile App Plus and Field Service Mobile App. Produces a finding list with code-level fixes covering inline GraphQL queries in `@wire` configurations, modern `lwc:if` / `lwc:elseif` / `lwc:else` directives, and Komaci ESLint rule violations (private wire properties, non-local reactive references, getter side-effects). Use when the user asks for a \"mobile offline review\", \"Komaci check\", \"offline priming audit\", \"offline priming failure\", or \"offline data graph error\", or to validate an LWC against the `@salesforce/eslint-plugin-lwc-graph-analyzer` recommended ruleset. Do not use for generic LWC code review (use an appropriate domain review skill) or for building LWCs with native mobile capabilities (use `using-mobile-native-capabilities`)."
+metadata:
+  version: "1.0"
+---
+<!-- adk-managed-skill -->
+
+# Reviewing LWC Mobile Offline
+
+Run a structured offline-priming compliance pass over a Lightning Web
+Component, producing a report of issues found and code-level fixes to bring
+the component into compliance with Komaci's static analysis requirements
+for the Salesforce Mobile App Plus and Field Service Mobile App.
+
+## When to Use
+
+- The user asks for a "mobile offline review", "Komaci check", or "offline
+  priming audit" on a specific LWC.
+- Preparing a component to ship in Salesforce Mobile App Plus or Field
+  Service Mobile App offline mode.
+- Investigating priming failures reported by the offline analyzer.
+
+Do NOT use this skill for:
+
+- Building an LWC that uses native mobile capabilities (barcode scanner,
+  biometrics, location, etc.) — use `using-mobile-native-capabilities`.
+- Generic LWC code review — use the appropriate domain skill
+  (`reviewing-lws-security`, `reviewing-lwc-rtl`, `accessibility-code-review`).
+
+## Prerequisites
+
+- Component path (LWC bundle under `modules/…`).
+- Access to the component's JS/TS and HTML templates.
+- Local Node + npm; ability to run `npx eslint` with the
+  `@salesforce/eslint-plugin-lwc-graph-analyzer` plugin.
+
+## Knowledge Base
+
+[Mobile Offline Grounding](references/grounding.md) explains the three
+violation categories and why each blocks offline priming. Read it before
+judging. The per-reviewer references below are the source of truth for the
+rules and remediations:
+
+- Inline GraphQL wire configuration: [Inline GraphQL Reviewer](references/inline-graphql.md)
+- `lwc:if` conditional rendering compatibility: [lwc:if Reviewer](references/lwc-if.md)
+- Komaci ESLint static analysis: [Komaci ESLint Reviewer](references/komaci-eslint.md)
+
+## Workflow
+
+### Step 1 — Scope the review
+
+Identify the component bundle: `.html`, `.js`/`.ts`. CSS and meta files are
+not in scope for offline priming. If the bundle has multiple HTML
+templates, all are reviewed.
+
+### Step 2 — Read the grounding and per-reviewer references
+
+Read [Mobile Offline Grounding](references/grounding.md) and the three
+per-reviewer references end-to-end before judging. Cite the specific
+reviewer when emitting each finding so the report is auditable.
+
+### Step 3 — `lwc:if` / `lwc:elseif` / `lwc:else` (HTML)
+
+Walk every `.html` file in the bundle and apply the rules in
+[lwc:if Reviewer](references/lwc-if.md). For each occurrence of
+`lwc:if={…}`, `lwc:elseif={…}`, or `lwc:else`, emit a finding with the
+exact `if:true` / `if:false` rewrite — including the nesting required to
+preserve `lwc:elseif` and `lwc:else` semantics.
+
+### Step 4 — Inline GraphQL in `@wire` (JS)
+
+Walk every `.js`/`.ts` file in the bundle and apply the rules in
+[Inline GraphQL Reviewer](references/inline-graphql.md). For each `@wire`
+that references a `gql` template literal directly (or via a top-level
+constant), emit a finding that names a concrete getter and shows the
+rewritten `@wire` configuration.
+
+### Step 5 — Komaci ESLint pass (JS)
+
+Run the Komaci ESLint analyzer over the bundle's JS file using the
+bundled script. It applies the
+`@salesforce/eslint-plugin-lwc-graph-analyzer` recommended ruleset with
+the `bundleAnalyzer` processor enabled.
+
+```bash
+scripts/run-komaci.sh path/to/component.js
+```
+
+The script requires `@salesforce/eslint-plugin-lwc-graph-analyzer` to
+be resolvable from the working directory, and the component's sibling
+HTML templates must live next to the JS file (the plugin's
+`bundleAnalyzer` processor uses them to resolve the offline data
+graph). Output is ESLint `--format json` on stdout.
+
+For each `messages[*]` entry in the output, group by `ruleId` and look
+up the per-rule remediation in
+[Komaci ESLint Reviewer](references/komaci-eslint.md). Emit a finding
+per (rule, line) pair with the exact remediation text from the
+reference; do not invent new advice. See the reference for the manual
+`npx eslint ...` invocation if the script is unavailable in the runtime
+environment.
+
+### Step 6 — Produce the report
+
+Emit a report in this shape:
+
+```
+## Mobile Offline (Komaci priming)
+- <reviewer> — <file>:<startLine>:<startColumn>-<endLine>:<endColumn> — <type>
+  Description: <verbatim from the reviewer reference>
+  Intent analysis: <verbatim from the reviewer reference>
+  Suggested action: <verbatim from the reviewer reference>
+  Code: |
+    <source snippet from startLine through endLine, optional but
+     recommended when the violation spans multiple lines>
+  Applied: yes/no
+
+## Summary
+- <n> issues found; <m> fixed; <k> deferred (with reason)
+```
+
+For Komaci ESLint findings, take `startLine`/`startColumn`/`endLine`/
+`endColumn` from the ESLint message's `line`/`column`/`endLine`/`endColumn`.
+For Inline GraphQL and `lwc:if` findings, supply the line/column range you
+observed in the source. If `endLine`/`endColumn` are not available for a
+finding, fall back to `<file>:<startLine>` and omit the trailing range.
+
+Cite the reviewer (Inline GraphQL / lwc:if / Komaci ESLint rule id) on every
+finding.
+
+### Step 7 — Apply fixes
+
+Apply the remediations directly when the user asked for fixes. If a
+remediation conflicts with the component's behavior outside offline (e.g.
+the developer relies on `lwc:elseif` for readability and the user is not
+yet shipping to mobile offline), surface the conflict in the deferred list
+rather than silently rewriting.
+
+
+## Verification Checklist
+
+- [ ] Every `lwc:if` / `lwc:elseif` / `lwc:else` flagged or absent.
+- [ ] Every `@wire` referencing `gql` checked; inline queries extracted to
+      a getter.
+- [ ] Komaci ESLint analyzer was actually run; findings cite real rule
+      ids, not invented ones.
+- [ ] Each finding cites the originating reviewer or rule id.
+- [ ] No remediation outside the three categories above (other concerns
+      belong to other skills).
+
+
+## Troubleshooting
+
+- **`npx eslint` cannot find the plugin** — install
+  `@salesforce/eslint-plugin-lwc-graph-analyzer` in the workspace, or use a
+  pinned local install path. The plugin is the canonical source of Komaci
+  rules.
+- **`bundleAnalyzer` related errors** — the recommended config drives the
+  bundle processor; do not strip it. The processor expects sibling HTML
+  files to be discoverable. If running on a stripped-down JS file, supply
+  the matching HTML in the temp directory.
+- **No findings for a component you expect to fail** — confirm the
+  recommended ruleset is applied (not just `bundleAnalyzer` with empty
+  rules). Some rules require the HTML to be present alongside the JS.
+- **Findings duplicate `lwc:if` from the dedicated reviewer** — the Komaci
+  plugin does not check templates; the `lwc:if` check is HTML-only and
+  comes from Step 3. Findings from Step 5 are JS-only.

package/skills/reviewing-lwc-mobile-offline/references/grounding.md

@@ -0,0 +1,7 @@
+You are an expert code reviewer specializing in Lightning Web Components (LWC) that must run in the **Salesforce Mobile App Plus** and **Field Service Mobile App** in offline mode. The Komaci static-analysis engine pre-primes the data graph for offline use; certain LWC patterns prevent priming and must be flagged with actionable remediations.
+
+Your reviews focus on three categories:
+
+1. **Conditional rendering compatibility** — modern `lwc:if` / `lwc:elseif` / `lwc:else` directives are incompatible with Komaci priming and must be rewritten as legacy `if:true` / `if:false` branches.
+2. **GraphQL wire configuration** — inline GraphQL queries in `@wire` configurations prevent Komaci from understanding the data graph; queries must be extracted to a getter on the component class.
+3. **Komaci ESLint rule violations** — the `@salesforce/eslint-plugin-lwc-graph-analyzer` plugin exposes a recommended rule set that catches additional priming-blockers (private wire properties, non-local reactive references, getter side-effects, etc.).

package/skills/reviewing-lwc-mobile-offline/references/inline-graphql.md

@@ -0,0 +1,43 @@
+# Inline GraphQL Wire Configuration
+
+## Framework for the analysis
+
+The Komaci offline static analysis engine requires GraphQL queries to be **extracted from `@wire` adapter configurations into separate getter methods** for proper offline data priming. Inline GraphQL query strings within `@wire` adapter calls prevent the static analysis engine from understanding and optimizing data dependencies for offline scenarios.
+
+**FOCUS:** Only report improper usage of GraphQL queries and variables accessed outside of a component getter function. Do not provide feedback on any other adapter use.
+
+Key points to consider:
+
+- GraphQL queries and variables MUST be accessed from a getter function within the component class.
+- GraphQL queries MUST NOT be inlined in the wire adapter configuration object.
+- GraphQL variables MUST NOT be inlined in the wire adapter configuration object.
+- GraphQL queries MUST NOT be defined as top-level constants.
+- GraphQL variables MUST NOT be defined as top-level constants.
+- If the query is already in a getter function, do not provide feedback.
+- If the component does not use GraphQL, does not import GraphQL, does not use `@wire`, or does not contain a query in a `gql` template literal, do not provide feedback or analyze further.
+
+## Request
+
+Review the JavaScript files for `@wire` decorators with inline GraphQL queries:
+
+1. Identify `@wire` decorators that use GraphQL wire adapters.
+2. Look for literal GraphQL query strings within the wire configuration objects.
+3. Check for template literals or string literals containing GraphQL syntax.
+4. Analyze the complexity and reusability of the inline queries.
+5. Determine appropriate getter method names for extracted queries.
+6. Validate that extraction will not break existing functionality.
+7. Report each violation with specific refactoring guidance.
+
+For each violation, provide a strong suggested action that names a concrete getter — e.g. _"The query MUST be extracted into a getter function called `fooQuery` and accessed by the config `@wire(graphql, { query: '$fooQuery' })`."_
+
+Rules to follow:
+
+- If no action is required, return an empty list. Do not return null or any other value — return an empty array.
+- Keep issues concise; avoid duplicated issues or unnecessary analysis for things that are not real violations.
+- Stick to the instructions for the specific reviewer in scope. Issues outside that scope will be analyzed by other reviewers.
+- For each violation, provide:
+  - The exact violation type as defined by the reviewer in scope.
+  - A description of why it is a problem in the context of mobile offline priming.
+  - An intent analysis explaining what the developer likely intended.
+  - A suggested action with concrete code-level remediation.
+- Do not make assumptions about other components that may be referenced.