@salesforce/afv-skills 1.65.0 → 1.66.0

package/skills/experience-defer-rendering-workspace-page-setup-configure/SKILL.md

@@ -1,41 +0,0 @@
----
-name: experience-defer-rendering-workspace-page-setup-configure
-description: "Use this skill when users want to toggles the DeferRenderingWorkspacePage org preference. Trigger when users mention defer, rendering, workspace, page, setup, defer rendering workspace page setup page."
-metadata:
-  version: "1.0"
----
-
-# Managing Defer Rendering Workspace Page Setup Page
-
-## When to Use This Skill
-
-Toggles the DeferRenderingWorkspacePage org preference. GET /setup/org/preferences/DeferRenderingWorkspacePage returns {isPreferenceEnabled:bool}; PATCH same path with body {desiredState:bool} flips it and returns the post-write state — no separate verify. Read-then-conditional-write is optional; PATCH alone suffices when the desired state is known.
-
-## Operations Reference
-
-Operations grouped by purpose. Use these as the building blocks for the workflows above.
-
-### Summary
-
-| Operation | Purpose | Status | Call | Depends on |
-|-----------|---------|--------|------|------------|
-| `isOrgPreferenceEnabled_wire_2` | read | — | `checkPreference` | — |
-| `setOrgPreferences_1` | write | — | `updatePreference` | `isOrgPreferenceEnabled_wire_2` |
-
-### Read operations
-
-#### `isOrgPreferenceEnabled_wire_2`
-
-Wire-fetch the current value of the DeferRenderingWorkspacePage org preference. The result drives the toggle's checked state on page load.
-
-**Call:** `checkPreference`
-
-### Write operations
-
-#### `setOrgPreferences_1`
-
-Persist the new boolean value of the DeferRenderingWorkspacePage org preference when the admin flips the toggle. On failure the UI dispatches an error toast with the UpdatePrefError label.
-
-**Call:** `updatePreference`
-
-**Depends on:** `isOrgPreferenceEnabled_wire_2`

package/skills/experience-field-service-app-builder-configure/SKILL.md

@@ -1,187 +0,0 @@
----
-name: experience-field-service-app-builder-configure
-description: "Use this skill when users want to configure the Field Service mobile app navigation tabs experience for technicians and dispatchers: create / clone / update / delete app configurations, assign user profiles, and configure navigation tabs. Trigger when users mention field, service, app, builder, field service app builder."
-metadata:
-  version: "1.0"
-  accessCheck: "MobileBuilder.userCanViewMobileBuilder"
----
-
-# Managing Field Service App Builder
-
-## When to Use This Skill
-
-Configure the Field Service mobile app navigation tabs experience for technicians and dispatchers:
-create / clone / update / delete app configurations, assign user profiles, and configure navigation tabs.
-
-Supported tab types: Content Libraries, Inventory, Lightning Web Component (LWC), List View,
-LWC Attributes, Notifications, Schedule, Time Sheet.
-
-appType is constrained to "Sfs" for this SOR. App state enum: DRAFT | PUBLISHED. Other builders
-(SappMobileHome, SalesCloudMab, CAMA, CLT) use the same controller but have their own Setup pages
-and SORs.
-
-create / update / delete app configs now use the Applications Connect API
-(/services/data/v67.0/applications/{create,update,delete}/Sfs). The remaining read/profile/publish/
-clone steps dispatch through the UI Experience app Aura controller via
-/headless/invoke/platform/field-service-app-builder/...
-
-DESTRUCTIVE: delete-app-config permanently removes app configs — confirm with admin before invoking.
-
-CROSS-FEATURE DEPENDENCY: assign-profiles body items carry experienceContainerId + containerType
-referencing ExperienceContainer records administered by a sibling Setup workflow
-(the Experience container operation, guard view Experience profile assignment). This SOR does
-NOT create containers — read existing values from get-profile-assignments output and reuse them.
-
-## Workflow
-
-Typical create flow: get-apps → create-app-config → assign-profiles → publish-experience-metadata → verify-get-apps.
-
-Reuse appId from get-apps output across all downstream steps that need an app reference.
-
-Reuse experienceContainerId from get-profile-assignments output when calling assign-profiles — those
-container records are administered by a sibling SOR (CustomApp / ExperienceContainer); this SOR does
-not create them.
-
-Navigation menu (create/update contents): the nav menu MUST include the mandatory Notifications item
-(experience/namedPage → pageName "Notifications"); min 1 / max 15 items; sub-menus are not allowed.
-
-Verify-after-write: after create / update / clone-app-config → re-read get-apps; after assign-profiles
-→ get-profile-assignments; after publish → check lastPublished and state == PUBLISHED.
-
-## Critical Constraints
-
-**Preconditions:**
-
-- User must have MobileBuilder ViewMobileBuilder access (check: `Mobile App Builder access`)
-- (precondition) (check: `Mobile App Builder access`)
-
-**Destructive operations — require explicit user confirmation:**
-
-- **`delete-app-config`** — Delete an SFS app and all its draft content via the Applications Connect API. Identify the app by
-id (8sa...) or developerName in the path; appType is NOT in the URL (resolved from the stored
-container). Empty body. Returns {deletedExperienceContainerId, status:DELETED}. NOTE: the backend
-blocks deletion of apps that still have live ExperienceContainers (business rule, not a skill error).
-  - Rollback: No automatic rollback.
-
-## Operations Reference
-
-Operations grouped by purpose. Use these as the building blocks for the workflows above.
-
-### Summary
-
-| Operation | Purpose | Status | Call | Depends on |
-|-----------|---------|--------|------|------------|
-| `get-apps` | read | proposed | `GET /headless/invoke/platform/field-service-app-builder` | — |
-| `get-profile-assignments` | read | proposed | `GET /headless/invoke/platform/field-service-app-builder/get-profile-assignments` | — |
-| `assign-profiles` | write | proposed | `PATCH /headless/invoke/platform/field-service-app-builder/assign-profiles` | — |
-| `update-app-config` | write | proposed | `POST /services/data/v67.0/applications/update/{appIdOrDevName}/Sfs` | — |
-| `create-app-config` | write | proposed | `POST /services/data/v67.0/applications/create/Sfs` | — |
-| `publish-experience-metadata` | write | proposed | `PATCH /headless/invoke/platform/field-service-app-builder/publish-experience-metadata` | — |
-| `clone-app-config` | write | proposed | `PATCH /headless/invoke/platform/field-service-app-builder/clone-app-config` | — |
-| `delete-app-config` | delete | proposed | `POST /services/data/v67.0/applications/delete/{appIdOrDevName}` | — |
-
-### Read operations
-
-#### `get-apps`
-
-Get apps.
-
-**Call:** `GET /headless/invoke/platform/field-service-app-builder`   — status: `proposed`
-
-**Inputs:**
-
-- `appType` *(`String`)*
-
-#### `get-profile-assignments`
-
-Get profile assignments.
-
-**Call:** `GET /headless/invoke/platform/field-service-app-builder/get-profile-assignments`   — status: `proposed`
-
-**Inputs:**
-
-- `appType` *(`String`)*
-
-### Write operations
-
-#### `assign-profiles`
-
-Assign profiles.
-
-**Call:** `PATCH /headless/invoke/platform/field-service-app-builder/assign-profiles`   — status: `proposed`
-
-**Inputs:**
-
-- `profileAssignments` *(`List<Map<String, Object>>`)* — Value for profile assignments.
-
-#### `update-app-config`
-
-Update an existing SFS app (draft) via the Applications Connect API. All body fields optional.
-contents items WITH an id are updated; WITHOUT an id are created; deleteResourceIds removes resources.
-The nav menu must still satisfy the guardrails (mandatory Notifications item; min 1 / max 15; no
-sub-menus). Identify the app by id (8sa...) or developerName in the path. Returns 201 with
-{status:DRAFT, created/updated/deletedResourceIds}.
-
-**Call:** `POST /services/data/v67.0/applications/update/{appIdOrDevName}/Sfs`   — status: `proposed`
-
-**Inputs:**
-
-- `appType` *(`String`)* — Value for the app type field.
-- `label` *(`String`)* — Value for the label field.
-- `appId` *(`String`)* — Id of the app.
-
-#### `create-app-config`
-
-Create a new SFS (Field Service) app configuration (draft) via the Applications Connect API.
-Body: developerName + label + contents. contents carries a navigation menu (experience__sfsECDefinition
-with navMenuId + experience__navigationMenu with the nav items). The menu MUST include the mandatory
-Notifications item; min 1 / max 15 items; no sub-menus. Returns 201 {id, name, type:Sfs,
-isPublished:false}; id is the experienceContainerId used by update/delete.
-
-**Call:** `POST /services/data/v67.0/applications/create/Sfs`   — status: `proposed`
-
-**Inputs:**
-
-- `appType` *(`String`)* — Value for the app type field.
-- `label` *(`String`)* — Value for the label field.
-- `apiName` *(`String`)* — Name of the api.
-- `contentTypeFqn` *(`String`)* — Value for the content type fqn field.
-
-#### `publish-experience-metadata`
-
-Publish experience metadata.
-
-**Call:** `PATCH /headless/invoke/platform/field-service-app-builder/publish-experience-metadata`   — status: `proposed`
-
-**Inputs:**
-
-- `appId` *(`String`)* — Id of the app.
-
-#### `clone-app-config`
-
-Clone app config.
-
-**Call:** `PATCH /headless/invoke/platform/field-service-app-builder/clone-app-config`   — status: `proposed`
-
-**Inputs:**
-
-- `appType` *(`String`)* — Value for the app type field.
-- `label` *(`String`)* — Value for the label field.
-- `apiName` *(`String`)* — Name of the api.
-- `appId` *(`String`)* — Id of the app.
-
-### Destructive operations
-
-#### `delete-app-config`
-
-Delete an SFS app and all its draft content via the Applications Connect API. Identify the app by
-id (8sa...) or developerName in the path; appType is NOT in the URL (resolved from the stored
-container). Empty body. Returns {deletedExperienceContainerId, status:DELETED}. NOTE: the backend
-blocks deletion of apps that still have live ExperienceContainers (business rule, not a skill error).
-
-**Call:** `POST /services/data/v67.0/applications/delete/{appIdOrDevName}`   — status: `proposed`
-
-**Inputs:**
-
-- `appType` *(`String`)*
-- `appId` *(`String`)*

package/skills/experience-flow-category-configure/SKILL.md

@@ -1,117 +0,0 @@
----
-name: experience-flow-category-configure
-description: "Use this skill when users want to manage Flow Categories — Metadata API type (since v42) that bundles flows under a developer-name-keyed grouping for Setup-page browsing in Lightning Bolt experiences. Trigger when users mention flow, category, flow category."
-metadata:
-  version: "1.0"
----
-
-# Managing Flow Category
-
-## When to Use This Skill
-
-Manage Flow Categories — Metadata API type (since v42) that bundles flows under a developer-name-keyed grouping for Setup-page browsing in Lightning Bolt experiences. Each FlowCategory carries DeveloperName, MasterLabel, optional Description, and a flowCategoryItems[] list whose entries each name a flow developer name. Persistence is reachable via /headless/metadata deploy/delete/retrieve on the FlowCategory type; the underlying operation is THIN over Tooling sObject FlowCategory CRUD. Use this SOR to read a category, list its flows, create/update/delete a category, and validate developer-name uniqueness before save.
-
-## Workflow
-
-Validate uniqueness (is-developer-name-unique) before create; then save-flow-category (Metadata deploy upserts by FullName=DeveloperName; isUpdate=true requires the record Id in the flowCategory map). verify-save-flow-category retrieves the FullName to confirm. delete-flow-category is independent. get-flows reads flowCategoryItems[].flow from the same retrieve.
-
-## Critical Constraints
-
-**Destructive operations — require explicit user confirmation:**
-
-- **`delete-flow-category`** — Delete a FlowCategory by FullName via /headless/metadata destructiveChanges deploy on the FlowCategory type. Returns no data on success (treat 200/204 as success). Removes the category record and its flowCategoryItems children atomically.
-  - Rollback: No automatic rollback.
-
-## Verification Checklist
-
-After every write operation, confirm the effect by re-reading state:
-
-- After `delete-flow-category`: call `verify-delete-flow-category` (`/headless/metadata`)
-
-## Operations Reference
-
-Operations grouped by purpose. Use these as the building blocks for the workflows above.
-
-### Summary
-
-| Operation | Purpose | Status | Call | Depends on |
-|-----------|---------|--------|------|------------|
-| `save-flow-category` | write | proposed | `/headless/metadata` | — |
-| `delete-flow-category` | delete | proposed | `DELETE /headless/invoke/platform/flow-category/delete-flow-category` | — |
-| `verify-delete-flow-category` | verify | — | `/headless/metadata` | `delete-flow-category` |
-| `get-flows` | read | implemented | `/headless/metadata` | — |
-| `verify-save-flow-category` | read | proposed | `/headless/metadata` | `save-flow-category` |
-| `is-developer-name-unique` | read | implemented | `GET /headless/invoke/platform/flow-category/is-developer-name-unique` | — |
-
-### Read operations
-
-#### `get-flows`
-
-Retrieve FlowCategory by FullName via /headless/metadata; read flowCategoryItems[].flow — each entry names a flow developer name in the category. Aura's UI reformat is presentational; Metadata payload carries the data.
-
-**Call:** `/headless/metadata`   — status: `implemented`
-
-**Inputs:**
-
-- `flowCategoryId` *(`String`)*
-
-#### `verify-save-flow-category`
-
-Retrieve the FlowCategory by FullName via /headless/metadata after save. A non-empty members result with the saved DeveloperName, MasterLabel, Description, and flowCategoryItems echoes the deploy and confirms it took effect.
-
-**Call:** `/headless/metadata`   — status: `proposed`
-
-**Inputs:**
-
-- `id` *(`String`)*
-
-**Depends on:** `save-flow-category`
-
-#### `is-developer-name-unique`
-
-Returns true when no FlowCategory has the supplied developerName. Call before save-flow-category on create to validate a candidate DeveloperName. Disposition: AURA-IS-CANONICAL (Tooling-coverage evidence not vendored; see /notes/coverage_gap).
-
-**Call:** `GET /headless/invoke/platform/flow-category/is-developer-name-unique`   — status: `implemented`
-
-**Inputs:**
-
-- `developerName` *(`String`)*
-
-### Write operations
-
-#### `save-flow-category`
-
-Deploy FlowCategory via /headless/metadata. Body XML: DeveloperName, MasterLabel, optional Description, flowCategoryItems[].flow. Same op handles create + update — FullName=DeveloperName keys upsert; isUpdate=true requires record Id.
-
-**Call:** `/headless/metadata`   — status: `proposed`
-
-**Inputs:**
-
-- `flowCategory` *(`Map<String, Object>`)* — Value for flow category.
-- `isUpdate` *(`boolean`)* — Whether update is enabled.
-
-### Verify operations
-
-#### `verify-delete-flow-category`
-
-Retrieve the FlowCategory by FullName via /headless/metadata after delete. An empty members result confirms the destructiveChanges deploy landed; a non-empty result means the delete did not take effect.
-
-**Call:** `/headless/metadata`
-
-**Inputs:**
-
-- `id` *(`String`)*
-
-**Depends on:** `delete-flow-category`
-
-### Destructive operations
-
-#### `delete-flow-category`
-
-Delete a FlowCategory by FullName via /headless/metadata destructiveChanges deploy on the FlowCategory type. Returns no data on success (treat 200/204 as success). Removes the category record and its flowCategoryItems children atomically.
-
-**Call:** `DELETE /headless/invoke/platform/flow-category/delete-flow-category`   — status: `proposed`
-
-**Inputs:**
-
-- `id` *(`String`)*