@salesforce/afv-skills 1.65.0 → 1.65.1

package/skills/experience-lightning-out-configure/SKILL.md

@@ -1,129 +0,0 @@
----
-name: experience-lightning-out-configure
-description: "Use this skill when users want to full lifecycle management of Lightning Out Apps — list, create, read, update, delete — without opening the Setup UI. Trigger when users mention lightning, out, lightning out."
-metadata:
-  version: "1.0"
-  accessCheck: "UserPermissions.ViewSetup"
----
-
-# Managing Lightning Out
-
-## When to Use This Skill
-
-Full lifecycle management of Lightning Out Apps — list, create, read, update, delete — without opening the Setup UI. The Setup page itself only lists (Setup GraphQL, 50 most recent) and deletes (Connect setup-entity adapter after a destructive confirm modal); create and edit on the page are navigations to a wizard, not API calls. This skill promotes the full CRUD surface to first-class steps: LightningOutApp is a Tooling-API metadata sObject (key prefix `1Us`; toolingApiAccess=always; all four CRUD verbs allowed per UDD), so create / get-by-id / update run as native Tooling sObject calls (verified live), while list stays on Setup GraphQL and delete on the page's Connect adapter. Every LightningOutApp has a restricted `Runtime` picklist (`CLWR` classic vs `LWR_CORE` label `LWR@Core`) that the Setup GraphQL list projection omits — use get-by-id or Tooling SOQL to see it. Permissions: ViewSetup to read; CustomizeApplication to create, update, or delete.
-
-## Workflow
-
-Full CRUD, all first-class steps.
-
-- LIST — graphql_wire_2 (Setup GraphQL): up to 50 apps, newest first, projecting Id / ApplicationName / IsEnabled. NOTE it OMITS the Runtime picklist, DeveloperName and Language.
-- CREATE — create_LightningOutApp_1 (Tooling sObject POST): required DeveloperName (unique API name, no spaces), MasterLabel (UI label), ApplicationName (the app to expose); optional IsEnabled (default false), Language (optional; server-defaulted to the org locale, e.g. en_US), Runtime (`CLWR` | `LWR_CORE`). Returns the new record's Id.
-- GET — get_LightningOutApp_1 (Tooling GET by Id): full field set INCLUDING Runtime / DeveloperName / Language that the list step hides.
-- UPDATE — update_LightningOutApp_1 (Tooling PATCH by Id): send only the fields to change; 204 on success.
-- DELETE — deleteRecords_1 (Connect setup-entity adapter): the Setup page opens a destructive confirm modal first — replicate that gate. Do NOT loop deletes; each is an irreversible Tooling-backed delete. (Tooling sObject DELETE on `/tooling/sobjects/LightningOutApp/{id}` is the equivalent lateral verb if you're not on the Setup-shell binding.)
-
-First-class concept — `Runtime` picklist. Every LightningOutApp has a restricted `Runtime` field (`CLWR` = classic Lightning Web Runtime; `LWR_CORE` label `LWR@Core`). Because the list step omits it, use get_LightningOutApp_1 or Tooling SOQL when the runtime distinction matters.
-
-All Tooling CRUD steps bypass the Setup-shell access check, so gate them on ViewSetup (read) and CustomizeApplication (create / update / delete) at the caller.
-
-## Critical Constraints
-
-**Preconditions:**
-
-- Caller must have the ViewSetup user permission (UDD access check `View Lightning Out access = UserPermissions.ViewSetup`) to read apps via graphql_wire_2 or get_LightningOutApp_1. (check: `UserPermissions.ViewSetup`)
-- Create (create_LightningOutApp_1), update (update_LightningOutApp_1), and delete (deleteRecords_1) additionally require the CustomizeApplication user permission (UDD access check `Modify Lightning Out permission = Customize Application permission, UserPermissions.ViewSetup`). (check: `Customize Application permission`)
-
-**Destructive operations — require explicit user confirmation:**
-
-- **`deleteRecords_1`** — Delete one LightningOutApp record by recordId via the Connect setup-entity adapter (`force/ldsAdaptersSetupApi.deleteRecords` with `objectApiName: 'LightningOutApp'` and `setupEntityInputRepresentation.entities: [{ recordId }]`). The LWC opens a destructive ConfirmationModal first; only on confirm does it issue the call, then locally filters the row out and shows a success toast. recordId is the `id` from any graphql_wire_2 row.
-  - 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 |
-|-----------|---------|--------|------|------------|
-| `graphql_wire_2` | read | — | `setup.query.LightningOutApp` | — |
-| `deleteRecords_1` | delete | — | `deleteRecords` | `graphql_wire_2` |
-| `create_LightningOutApp_1` | write | — | `sobjects/LightningOutApp` | — |
-| `get_LightningOutApp_1` | read | — | `sobjects/LightningOutApp/{id}` | `graphql_wire_2` |
-| `update_LightningOutApp_1` | write | — | `sobjects/LightningOutApp/{id}` | `graphql_wire_2` |
-
-### Dependency graph
-
-```mermaid
-graph TD
-  graphql_wire_2["graphql_wire_2 (read)"]
-  deleteRecords_1["deleteRecords_1 (delete)"]
-  create_LightningOutApp_1["create_LightningOutApp_1 (write)"]
-  get_LightningOutApp_1["get_LightningOutApp_1 (read)"]
-  update_LightningOutApp_1["update_LightningOutApp_1 (write)"]
-  graphql_wire_2 --> deleteRecords_1
-  graphql_wire_2 --> get_LightningOutApp_1
-  graphql_wire_2 --> update_LightningOutApp_1
-```
-
-### Read operations
-
-#### `graphql_wire_2`
-
-Fetch up to 50 LightningOutApp records via Setup GraphQL (`setup.query.LightningOutApp`), ordered by LastModifiedDate desc. The query projects `Id`, `ApplicationName.value`, and `IsEnabled.value`. The LWC populates a sortable table with App Id, App Name, App Status columns; sorting after load is client-side.
-
-**Call:** `setup.query.LightningOutApp`
-
-**Output:** Setup-GraphQL value-wrap envelope under setup.query.LightningOutApp.edges[].node — each node carries Id (string, 18-char LightningOutApp record id, key prefix `1Us`), ApplicationName.value (string, the app's display name), IsEnabled.value (boolean, current activation status). Up to 50 entries, ordered LastModifiedDate desc. NOTE: the projection OMITS the restricted picklist `Runtime` (`CLWR` | `LWR_CORE` label `LWR@Core`) that distinguishes classic Lightning-Out apps from LWR@Core apps, as well as DeveloperName and Language. Callers that need Runtime or arbitrary field-set / WHERE-filters should switch to Tooling SOQL over `LightningOutApp` (see notes.coverage_gap on this step).
-
-#### `get_LightningOutApp_1`
-
-Read a single LightningOutApp record by Id via the Tooling sObject API (`GET /services/data/vXX.0/tooling/sobjects/LightningOutApp/{id}`). Unlike the Setup GraphQL list step, this projects the FULL field set — including the Runtime picklist, DeveloperName and Language that the list omits. The {id} is any `1Us` record Id (e.g. from graphql_wire_2 or create_LightningOutApp_1).
-
-**Call:** `sobjects/LightningOutApp/{id}`
-
-**Depends on:** `graphql_wire_2`
-
-**Output:** Tooling sObject GET — 200 with the full record: Id, DeveloperName, MasterLabel, ApplicationName, IsEnabled (boolean), Runtime (`CLWR` | `LWR_CORE`), Language, plus audit fields (CreatedDate/CreatedById, LastModifiedDate/LastModifiedById, SystemModstamp, IsDeleted).
-
-### Write operations
-
-#### `create_LightningOutApp_1`
-
-Create a new LightningOutApp record via the Tooling sObject API (`POST /services/data/vXX.0/tooling/sobjects/LightningOutApp`). Required body fields: DeveloperName (unique API name, no spaces), MasterLabel (UI display label), ApplicationName (the Aura/LWR app being exposed). Optional: IsEnabled (boolean, default false), Language (optional; server-defaulted to the org locale, e.g. en_US), Runtime (restricted picklist `CLWR` | `LWR_CORE`). This is a lateral programmatic surface — the Setup page routes 'New' to a navigation wizard rather than a direct create call.
-
-**Call:** `sobjects/LightningOutApp`
-
-**Output:** Tooling sObject create response — 201 with `{ id: <new 1Us record Id>, success: true, errors: [] }`. The returned id feeds get_LightningOutApp_1 / update_LightningOutApp_1 / deleteRecords_1.
-
-**Notes:** required_fields: ['DeveloperName', 'MasterLabel', 'ApplicationName']; runtime_picklist: ['CLWR', 'LWR_CORE']
-
-#### `update_LightningOutApp_1`
-
-Update an existing LightningOutApp record by Id via the Tooling sObject API (`PATCH /services/data/vXX.0/tooling/sobjects/LightningOutApp/{id}`). Send only the fields to change in the body; omitted fields are left unchanged. This is a lateral programmatic surface — the Setup page routes 'Edit' to a navigation wizard rather than a direct update call.
-
-Updateable fields (per the LightningOutApp Tooling describe, updateable=true): DeveloperName, MasterLabel, ApplicationName, IsEnabled, Runtime (`CLWR` | `LWR_CORE`), Language. The system/audit fields (Id, IsDeleted, CreatedDate/ById, LastModifiedDate/ById, SystemModstamp) are not updateable.
-
-Verification precision: a live PATCH round-trip confirmed IsEnabled + MasterLabel (→ 204). The remaining updateable fields are confirmed by the object describe's per-field updateable=true flag, not by an individual live PATCH.
-
-Cautions: DeveloperName is updateable but is the unique API name — renaming it is a breaking change for anything referencing the app by name; treat it as effectively immutable unless the caller explicitly wants a rename. Switching Runtime (`CLWR` ↔ `LWR_CORE`) is a behavioral migration between the classic and LWR@Core runtimes, not a cosmetic toggle — confirm intent before changing it.
-
-**Call:** `sobjects/LightningOutApp/{id}`
-
-**Depends on:** `graphql_wire_2`
-
-**Output:** Tooling sObject PATCH — 204 No Content on success (empty body). Re-read via get_LightningOutApp_1 to confirm the new values.
-
-**Notes:** runtime_picklist: ['CLWR', 'LWR_CORE']; updateable_fields: ['DeveloperName', 'MasterLabel', 'ApplicationName', 'IsEnabled', 'Runtime', 'Language']
-
-### Destructive operations
-
-#### `deleteRecords_1`
-
-Delete one LightningOutApp record by recordId via the Connect setup-entity adapter (`force/ldsAdaptersSetupApi.deleteRecords` with `objectApiName: 'LightningOutApp'` and `setupEntityInputRepresentation.entities: [{ recordId }]`). The LWC opens a destructive ConfirmationModal first; only on confirm does it issue the call, then locally filters the row out and shows a success toast. recordId is the `id` from any graphql_wire_2 row.
-
-**Call:** `deleteRecords`
-
-**Depends on:** `graphql_wire_2`
-
-**Output:** Connect setup-entity-adapter delete: promise resolves on success (the LWC discards the resolved value and removes the row locally); rejects with an error object whose `message` field surfaces in a UI error toast. Underlying delete is a Tooling-family delete on the LightningOutApp record (UDD declares `apiAccess=never` for the standard sObject family, only Tooling).

package/skills/experience-lightning-preview-configure/SKILL.md

@@ -1,67 +0,0 @@
----
-name: experience-lightning-preview-configure
-description: "Use this skill when users want to reads or toggles the LocalDevelopmentPreviewPref org preference (Beta) controlling whether LWC local-development preview is available in the org. Trigger when users mention lightning, preview, lightning preview."
-metadata:
-  version: "1.0"
-  accessCheck: "Gater.org.salesforce.lwc.localDevPreview || OrgPermissions.LocalDevelopmentPreview"
----
-
-# Managing Lightning Preview
-
-## When to Use This Skill
-
-Reads or toggles the LocalDevelopmentPreviewPref org preference (Beta) controlling whether LWC local-development preview is available in the org. Single-preference SOR backed by GET/PATCH /setup/org/preferences/LocalDevelopmentPreviewPref (Connect API). Read returns isPreferenceEnabled; write takes desiredState and returns the resulting isPreferenceEnabled. Requires the org's LocalDevelopmentPreview org permission OR the org.salesforce.lwc.localDevPreview Beta gater, plus the running user's permission to modify Lightning Components Setup.
-
-## Workflow
-
-Workflow: (1) call step `isOrgPreferenceEnabled_wire_2` to read current state; (2) if change needed, confirm the target state with a human, then call step `setOrgPreferences_1` with `desiredState` = target boolean; (3) verify by re-reading — the PATCH response's `isPreferenceEnabled` must equal `desiredState`. Both steps target the same Connect API resource `/setup/org/preferences/LocalDevelopmentPreviewPref` (GET + PATCH). LocalDevelopmentPreviewPref is an ORG preference (org-wide singleton), not a user preference — a single write affects every user in the org. The write is idempotent: PATCH `desiredState: true` on an already-enabled preference returns 200 with `isPreferenceEnabled: true` (no error, no state change). Preconditions: the org must have either the LocalDevelopmentPreview org permission or the org.salesforce.lwc.localDevPreview Beta gater; the caller must have the "Modify Lightning Components Setup" permission (part of the Customize Application family). If either precondition fails, the setup node itself is not accessible and API calls return 403.
-
-## Critical Constraints
-
-**Preconditions:**
-
-- Org must have either the LocalDevelopmentPreview org permission enabled OR the org.salesforce.lwc.localDevPreview Beta gater turned on; otherwise the LightningPreview setup node is not visible and the preference cannot be toggled. (check: `Gater.org.salesforce.lwc.localDevPreview || OrgPermissions.LocalDevelopmentPreview`)
-- Running user must have the Customize Application permission family that grants modify-Lightning-Components-Setup access. (check: `Modify Lightning Components Setup permission`)
-
-**Operational rules:**
-
-- HUMAN CONFIRMATION REQUIRED BEFORE THE WRITE: step `setOrgPreferences_1` is an org-wide singleton — one PATCH flips LWC local-development preview for every user in the org. An autonomous agent must confirm the intended target state with a human before invoking the write. The read step is safe to call freely.
-
-## 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 | — | `/services/data/v67.0/setup/org/preferences/LocalDevelopmentPreviewPref` | — |
-| `setOrgPreferences_1` | write | — | `/services/data/v67.0/setup/org/preferences/LocalDevelopmentPreviewPref` | `isOrgPreferenceEnabled_wire_2` |
-
-### Read operations
-
-#### `isOrgPreferenceEnabled_wire_2`
-
-Reads the current LocalDevelopmentPreviewPref org preference state. Returns PreferenceCheckOutputRepresentation with a single boolean isPreferenceEnabled.
-
-**Call:** `/services/data/v67.0/setup/org/preferences/LocalDevelopmentPreviewPref`
-
-**Output:** PreferenceCheckOutputRepresentation — single boolean field isPreferenceEnabled indicating whether the named preference is currently on for the org.
-
-**Notes:** success_shape: Spec documents only a 200 response returning PreferenceCheckOutputRepresentation with a single boolean `isPreferenceEnabled`. When the preference exists but is currently disabled the response is 200 with `isPreferenceEnabled: false` — this is NOT the "preference does not exist" case, do not conflate them.; error_contracts: Non-200 shapes are Connect API framework defaults, not documented in the v67 spec. Expect 403 when the caller lacks the "Modify Lightning Components Setup" user permission (grounded in the setup-manifest access expression's user-perm clause). An unknown preferenceName returns 404 NOT_FOUND ("The requested resource does not exist") — confirmed live on org 00Dxx00VINhTI8C, 2026-07-21. A 200 with `isPreferenceEnabled: false` therefore unambiguously means the preference exists but is currently disabled; it is never returned for a nonexistent preference. Do not conflate the two states.; idempotency: Safe to poll — GET is side-effect-free. No rate-limit contract documented for this endpoint; the wire adapter caches per-session.
-
-### Write operations
-
-#### `setOrgPreferences_1`
-
-Sets the LocalDevelopmentPreviewPref org preference to the boolean desiredState in the PATCH body. Returns PreferenceCheckOutputRepresentation reflecting the post-update isPreferenceEnabled value.
-
-**Call:** `/services/data/v67.0/setup/org/preferences/LocalDevelopmentPreviewPref`
-
-**Depends on:** `isOrgPreferenceEnabled_wire_2`
-
-**Output:** PreferenceCheckOutputRepresentation — isPreferenceEnabled boolean reflecting the post-update state of the preference.
-
-**Rollback:** Re-invoke this step with `desiredState` set to the value returned by the pre-change GET (step `isOrgPreferenceEnabled_wire_2`). Rollback is a symmetric PATCH — there is no compensating action beyond flipping the boolean back. If the pre-change read returned `isPreferenceEnabled: false` and the caller enabled the preference, rollback PATCH `desiredState: false`; the response's `isPreferenceEnabled: false` confirms the restore.
-
-**Notes:** success_shape: Spec documents only a 200 response returning PreferenceCheckOutputRepresentation with `isPreferenceEnabled` echoing the post-update state. Request body PreferenceCheckInputRepresentation has a single boolean `desiredState`; the spec schema does not mark it required, but the field is the only property — a PATCH without it is trivially malformed.; error_contracts: Non-200 shapes are Connect API framework defaults, not documented in the v67 spec. Expect 403 when the caller lacks the "Modify Lightning Components Setup" user permission (grounded in the setup-manifest access expression's user-perm clause). Malformed bodies (missing `desiredState`, wrong type, wrong content-type) hit the Connect framework's 400 BAD_REQUEST default. An unknown preferenceName returns 404 NOT_FOUND — confirmed live on org 00Dxx00VINhTI8C, 2026-07-21 (same probe as the paired read step); it is not the 200-with-false state.; idempotency: Idempotent — confirmed live on org 00Dxx00VINhTI8C, 2026-07-21: PATCH `desiredState: true` on an already-enabled preference returns 200 with `isPreferenceEnabled: true`, no error, no state change. Safe to retry on network timeout with the same `desiredState`. Verified end-to-end via a reversible enable → repeat-enable → rollback sequence.; scope: Org-wide singleton. A single successful PATCH affects every user in the org immediately — there is no per-user override for this preference.; shared_controller_dependency: The Aura route this step is substituted from (SetupMetadataController.setOrgPreference) is referenced by 30+ other preference-toggle SORs. Substituting this SOR to Connect API does not deprecate the underlying Aura route; the route remains callable and referenced. Do NOT propose an Option-3 rejection contract on the Aura route from this SOR — it would break every unrejected preference SOR that still references it.

package/skills/experience-lightning-types-query/SKILL.md

@@ -1,98 +0,0 @@
----
-name: experience-lightning-types-query
-description: "Use this skill when users want to use this skill when an admin or developer wants to discover what Lightning Types exist in their org (Standard out-of-the-box types, Custom types created via Metadata API, or Managed types from installed packages), or to retrieve the detailed schema + editor/renderer configuration. Trigger when users mention lightning, types, lightning types."
-metadata:
-  version: "1.0"
-  accessCheck: "OrgPermissions.LightningTypeBundle"
----
-
-# Querying Lightning Types
-
-## When to Use This Skill
-
-Use this skill when an admin or developer wants to discover what Lightning Types exist in their org (Standard out-of-the-box types, Custom types created via Metadata API, or Managed types from installed packages), or to retrieve the detailed schema + editor/renderer configuration of a specific type by its fully qualified name (FQN). Typical flow: list types (filter by category, source, or config target as needed) → pick a type from the response → fetch its detail by FQN. Both operations are read-only — there are no Connect API endpoints for creating, updating, or deleting Lightning Types in this family (Custom Type authoring still flows through the Metadata API, which is out of scope for this skill).
-
-## Workflow
-
-list-lightning-types → (optional) filter further → get-lightning-type-detail.
-Discovery first: list-lightning-types returns paginated summaries (namespacePrefix, developerName, title, description, source, detailUrl). Use pageSize 1-250 (default 25, max 250) to control batch size and page (0-based) to advance. If you need only Custom or Managed types, set excludeStandardTypes=true — Standard types are the OOTB type catalog and are usually the bulk of results. Filter to types intended for a specific surface via editorConfigTarget / rendererConfigTarget (e.g., LightningCommunity, ExperienceBuilder, PromptBuilder). Filter by underlying category with category=Apex or category=Object when the caller cares about type backing.
-Detail lookup: get-lightning-type-detail takes the FQN (namespacePrefix__developerName, e.g. lightning__booleanType, setup_discovery__considerationType, c__myCustomType) and returns the full schema + editor/renderer configurations for the requested target. By default configs come back expanded (computed propertyRenderers + layout, with OOTB config generation); pass expandConfigs=false to inspect what is actually configured (useful when debugging CLT Setup UI overrides). Pass includeSubSchemaDefinitions=true to inline referenced subschemas under $defs so the response is self-contained.
-No write APIs in this family. Custom Type creation/update/deletion goes through the Metadata API (CustomLightningType metadata type) — not covered here.
-Common gotchas: the API returns 403 FUNCTIONALITY_NOT_ENABLED if the org does not have OrgPermissions.LightningTypeBundle (default-enabled but can be disabled in some orgs). pageSize outside [1, 250] returns 400 INVALID_PAGING_OPTION. An unknown editorConfigTarget / rendererConfigTarget enum value returns 400 ILLEGAL_QUERY_PARAMETER_VALUE — the precise accepted set is enumerated in the inputs below and is broader in v66 than in the DRB. An FQN that does not exist returns 404 NOT_FOUND.
-
-## Critical Constraints
-
-**Preconditions:**
-
-- Org must have the LightningTypeBundle permission enabled (default-enabled) (check: `OrgPermissions.LightningTypeBundle`)
-- API must be available at v66.0 or later (Connect API was introduced in 254/v63 and has evolved through v66; SOR is authored against v66 wire shape) (check: `ApiVersion >= 63.0`)
-
-## Operations Reference
-
-Operations grouped by purpose. Use these as the building blocks for the workflows above.
-
-### Summary
-
-| Operation | Purpose | Status | Call | Depends on |
-|-----------|---------|--------|------|------------|
-| `list-lightning-types` | read | implemented | `getLightningTypeCollection` | — |
-| `get-lightning-type-detail` | read | implemented | `getLightningType` | `list-lightning-types` |
-
-### Read operations
-
-#### `list-lightning-types`
-
-Fetch a paginated list of Lightning Types in the org. Returns a LightningTypeCollectionRepresentation with `count`, `lightningTypes[]` (summary entries), and `currentPageUrl` / `nextPageUrl` / `previousPageUrl` for navigation. Each summary entry contains namespacePrefix, developerName, title, description, source (Standard / Custom / Managed), and detailUrl for drilling into the full type. Custom types additionally carry id, createdDate, createdBy, updatedDate, updatedBy.
-
-
-**Call:** `getLightningTypeCollection`   — status: `implemented`
-
-**Inputs:**
-
-- `category` *(`String`)* — Filter by underlying schema category. Valid values: 'Apex' (for @apexClassType-backed types), 'Object' (for lightning__objectType-backed types). Omit to include all categories. NOTE: enum is title-case in v66 ('Apex' / 'Object'), not the lowercase form shown in the DRB summary.
-
-- `editorConfigTarget` *(`String`)* — Return only types that have an editor configuration for the given target. Accepted values are broader in v66 than in the DRB (the DRB lists 6; v66 has 12).
-
-- `rendererConfigTarget` *(`String`)* — Return only types that have a renderer configuration for the given target. Accepted values are broader in v66 than in the DRB (the DRB lists 7; v66 has 16).
-
-- `excludeStandardTypes` *(`Boolean`)* — When true, omit Standard (OOTB) types from the response — useful to retrieve only Custom and Managed types. NOT documented in the DRB but live in v66.
-
-- `fullyQualifiedNames` *(`List<String>`)* — Comma-separated list of FQNs (namespacePrefix__developerName) to fetch a specific subset. Each FQN element follows the pattern `<namespacePrefix>__<developerName>`, e.g. `lightning__booleanType,c__myCustomType`.
-
-- `language` *(`String`)* — Locale code (e.g. `fr`, `en_AU`, `en_US`) controlling the language of the returned title and description. If omitted, the logged-in user's language is used; ENGLISH is the fallback when translations don't exist.
-
-- `page` *(`Integer`)* — 0-based page index. Default 0 returns the first page.
-- `pageSize` *(`Integer`)* — Items per page. Valid range is 1-250 inclusive (default 25). Values outside this range return 400 INVALID_PAGING_OPTION.
-
-#### `get-lightning-type-detail`
-
-Fetch the full / detailed information about a single Lightning Type by its fully qualified name. Returns a LightningTypeDetailRepresentation containing the JSON Schema definition (`schema`), the editor configuration (`editorConfig`) and renderer configuration (`rendererConfig`) for the requested target, and source metadata (createdBy, updatedBy, etc., for Custom types).
-
-
-**Call:** `getLightningType`   — status: `implemented`
-
-**Inputs:**
-
-- `fullyQualifiedName` *(`String`)* — The fully qualified name in `namespacePrefix__developerName` form, e.g. `lightning__booleanType` (Standard), `setup_discovery__considerationType` (Standard), `c__myCustomType` (Custom in default namespace). Typically threaded from a list-lightning-types response — pick a `lightningTypes[i].namespacePrefix` + `developerName` and join with `__`. An unknown FQN returns 404 NOT_FOUND.
-
-- `editorConfigTarget` *(`String`)* — Editor configuration target. If unspecified, the Default editor configuration is returned. Accepted values match the LightningModelTypesEditorConfigEnum (12 values; see list-lightning-types step inputs for the full set).
-
-- `rendererConfigTarget` *(`String`)* — Renderer configuration target. If unspecified, the Default renderer configuration is returned. Accepted values match the LightningModelTypesRendererConfigEnum (16 values).
-
-- `includeSubSchemaDefinitions` *(`Boolean`)* — When true, the response inlines all referenced external sub-schema definitions under a `$defs` block in the schema, replacing `sfdc_cms:type`-style refs with `$ref: #/$defs/...` internal refs. Use when you want a self-contained schema for offline analysis. Default false keeps the response compact.
-
-- `expandConfigs` *(`Boolean`)* — Default true returns "expanded" editor / renderer configs (OOTB config generation, computed propertyRenderers, computed layout including override expansion). Set false to return configs as stored — primary use case is letting users inspect what's actually configured in the CLT Setup UI. (Since v258 in the DRB; live on v66.)
-
-- `applyDefaults` *(`Boolean`)* — Boolean toggle present in v66 (not in the DRB). Spec description is sparse — agent should treat as advanced/experimental. Likely controls whether default values from the schema are applied to the response. Omit unless an explicit need exists.
-
-- `language` *(`String`)* — Locale code controlling the language of returned labels (title / description / property labels). Falls back to the user's language, then ENGLISH.
-
-
-**Depends on:** `list-lightning-types`
-
-**Output:** $.description
-
-## Notes
-
-- **related_apis:** GET /connect/lightning-types/references/{id} — returns references to a Lightning Type by 18-char Id (different controller — shared.lightning.model); not authored here, but see operation_id shared.lightning.model.connect.api.getLightningTypeReferences for callers needing reference inspection., GET /connect/lightning-model/candidate-types — vocabulary-driven type candidate lookup; complementary discovery API on a different controller., POST /connect/lightning-model/type-bundles — write API for upserting Lightning Type bundles; lives on shared-lightning-model-connect-api, different controller, not part of this skill's read-only family.
-- **out_of_scope:** Custom Type creation, update, and deletion (still flows through the Metadata API CustomLightningType metadata type)., Lightning Object Types and Lightning Type bundles (handled by shared-lightning-model-connect-api, not this family).

package/skills/experience-malware-scan-configure/SKILL.md

@@ -1,71 +0,0 @@
----
-name: experience-malware-scan-configure
-description: "Use this skill when users want to use this skill to read or change the org's malware-scan posture for file uploads. Trigger when users mention malware, scan, settings, malware scan settings."
-metadata:
-  version: "1.0"
----
-
-# Managing Malware Scan Settings
-
-## When to Use This Skill
-
-Use this skill to read or change the org's malware-scan posture for file
-uploads. Backed by Metadata API ContentSettings:
-  - enableSecureSalesforceFiles → enable/disable scanning
-  - enableMaliciousFileNotifications → enable/disable user notifications
-Read = retrieve Settings:Content. Write = deploy a Settings:Content with
-the desired values.
-
-## Operations Reference
-
-Operations grouped by purpose. Use these as the building blocks for the workflows above.
-
-### Summary
-
-| Operation | Purpose | Status | Call | Depends on |
-|-----------|---------|--------|------|------------|
-| `get_MalwareScanSettings_config_1` | read | — | `/headless/metadata` | — |
-| `update_MalwareScanSettings_config_1` | write | — | `/headless/metadata` | `get_MalwareScanSettings_config_1` |
-
-### Read operations
-
-#### `get_MalwareScanSettings_config_1`
-
-Read the org's current ContentSettings via the headless Metadata
-dispatcher (`/headless/metadata`) to inspect the malware-scan flags
-`enableSecureSalesforceFiles` and `enableMaliciousFileNotifications`.
-
-The agent calls dispatch against the served `/headless/metadata`
-route with the ContentSettings metadata type; the server dispatches
-the Metadata API retrieve. No shell / `sf` CLI required.
-
-Returns the ContentSettings record. The type also surfaces other Files
-org preferences; consumers should read only the two malware-scan flags
-above for this skill's purpose.
-
-**Call:** `/headless/metadata`
-
-### Write operations
-
-#### `update_MalwareScanSettings_config_1`
-
-Update the malware-scan posture by deploying ContentSettings via the
-headless Metadata dispatcher (`/headless/metadata`).
-
-The agent calls dispatch against the served `/headless/metadata`
-route with the ContentSettings metadata type and the desired field
-values:
-  - enableSecureSalesforceFiles: true|false
-  - enableMaliciousFileNotifications: true|false
-
-The server routes the Metadata API deploy; no shell / `sf` CLI
-required.
-
-Both flags are independent booleans. Deploying ContentSettings
-replaces ONLY the fields present in the payload — other
-ContentSettings values are preserved. Confirm post-deploy with the
-read step above.
-
-**Call:** `/headless/metadata`
-
-**Depends on:** `get_MalwareScanSettings_config_1`

package/skills/experience-my-salesforce-configure/SKILL.md

@@ -1,126 +0,0 @@
----
-name: experience-my-salesforce-configure
-description: "Use this skill when users want to mySalesforce1 setup home for non-CAMA Mobile Publisher app clones. Trigger when users mention my, salesforce, my salesforce."
-metadata:
-  version: "1.0"
----
-
-# Managing My Salesforce
-
-## When to Use This Skill
-
-MySalesforce1 setup home for non-CAMA Mobile Publisher app clones. Use this skill to read clone and readiness state, create eligible non-CAMA clones, acknowledge externally completed managed-package updates, delete clones, and read the registered developer identifier. CAMA creation through this Aura surface is rejected because CAMA is moving to Mobile App Designer; use the approved skill managing-mobile-publisher-connect-api-sfdc.mobile-publisher.connect.api-oas-67.0 for CAMA workflows.
-
-## Workflow
-
-Obtain the user's explicit permission immediately before every operation, including reads and writes. Read getMyS1HomePageModel for clones and capability flags. Before any create, isMigrationAndDeveloperReady must be true and getAvailableApps drives the appType selection. Thread createNewAppClone's AppCloneUIModel.id into updateManagedPackage or deleteAppClone. All writes refuse during ECA migration. This skill is approved only for non-CAMA app clones. Never call createNewAppClone with appType=CAMA or for an available-app entry whose hasCamaProject value is true. CAMA creation through this Aura surface is rejected because CAMA is moving to Mobile App Designer. Route CAMA requests to the approved skill managing-mobile-publisher-connect-api-sfdc.mobile-publisher.connect.api-oas-67.0. updateManagedPackage does not perform the external package installation: show the installPackageUrl, wait for the user to complete the installation, and obtain fresh explicit confirmation that it completed before calling updateManagedPackage to acknowledge the package update. Use getDeveloperId when the exact registered Mobile Publisher developer-account identifier is needed. For direct invocation, include className, action, params_schema, nested body, and query_params; never put parameter values in an args field.
-
-## Critical Constraints
-
-**Preconditions:**
-
-- ECA migration must NOT be in progress for the org. Every operation on the mobile home surface throws AuraHandledException when AppCloneAccessCheck.IS_ECA_MIGRATION_IN_PROGRESS is true. (check: `AppCloneAccessCheck.IS_ECA_MIGRATION_IN_PROGRESS == false`)
-- Caller must have View Setup permission, OR (in sandbox orgs) USER_HAS_MANAGED_ECAENABLED. Without one, getMyS1HomePageModel returns hasAccess=false and getAvailableApps returns an empty list. (check: `CAN_VIEW_APP_CLONE OR USER_HAS_MANAGED_ECAENABLED`)
-- A Mobile Publisher developer-account id must be registered for the org before creating new clones. isMigrationAndDeveloperReady returns false until this is set. (check: `MobilePublisherDeveloperId org-pref set (non-blank)`)
-
-**Destructive operations — require explicit user confirmation:**
-
-- **`deleteAppClone_1`** — Deletes the AppClone by id. Honors org-level allowDelete pref and AppCloneStandardEntity validation; refuses during ECA migration. AURA-IS-CANONICAL — no Connect DELETE on /connect/mobilepublisher/appCloneApps/{id}; raw sObject DELETE bypasses both gates.
-  - 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 |
-|-----------|---------|--------|------|------------|
-| `deleteAppClone_1` | delete | — | `DELETE /headless/invoke/platform/appclone-builder/delete-app-clone` | `getMyS1HomePageModel_1` |
-| `getAvailableApps_1` | read | — | `GET /headless/invoke/platform/appclone-builder/get-available-apps` | — |
-| `isMigrationAndDeveloperReady_1` | read | — | `GET /headless/invoke/platform/appclone-builder/is-migration-and-developer-ready` | — |
-| `getMyS1HomePageModel_1` | read | — | `GET /headless/invoke/platform/appclone-builder` | — |
-| `createNewAppClone_1` | write | — | `PATCH /headless/invoke/platform/appclone-builder/create-new-app-clone` | `getAvailableApps_1`, `isMigrationAndDeveloperReady_1` |
-| `updateManagedPackage_1` | write | — | `PATCH /headless/invoke/platform/appclone-builder/update-managed-package` | `getMyS1HomePageModel_1` |
-| `getDeveloperId_1` | read | — | `GET /headless/invoke/platform/appclone-setup/my-s1-home/get-developer-id` | — |
-
-### Dependency graph
-
-```mermaid
-graph TD
-  deleteAppClone_1["deleteAppClone_1 (delete)"]
-  getAvailableApps_1["getAvailableApps_1 (read)"]
-  isMigrationAndDeveloperReady_1["isMigrationAndDeveloperReady_1 (read)"]
-  getMyS1HomePageModel_1["getMyS1HomePageModel_1 (read)"]
-  createNewAppClone_1["createNewAppClone_1 (write)"]
-  updateManagedPackage_1["updateManagedPackage_1 (write)"]
-  getDeveloperId_1["getDeveloperId_1 (read)"]
-  getMyS1HomePageModel_1 --> deleteAppClone_1
-  getAvailableApps_1 --> createNewAppClone_1
-  isMigrationAndDeveloperReady_1 --> createNewAppClone_1
-  getMyS1HomePageModel_1 --> updateManagedPackage_1
-```
-
-### Read operations
-
-#### `getAvailableApps_1`
-
-Lists AvailableApp entries for this org — each carries appType (AppCloneTypeEnum), license counts, displayName/icon, selectability, CAMA-pre-existence flag. Empty without View Setup. AURA-IS-CANONICAL — picklist describe on AppCloneTypeEnum drops the license + CAMA signals.
-
-**Call:** `GET /headless/invoke/platform/appclone-builder/get-available-apps`
-
-**Output:** AvailableApp[] with per-entry appType (AppCloneTypeEnum; live-observed members on this org: Salesforce1, MyCommunity — set is not closed, other orgs may expose more), appName, displayText, selectable, availableLicenses (int, remaining), totalLicences (int, British-spelling in wire), iconName, hasCamaProject. Empty array when caller lacks View Setup.
-
-#### `isMigrationAndDeveloperReady_1`
-
-Boolean readiness — true iff ECA migration NOT in progress AND caller has View Setup AND a non-blank Mobile Publisher developer id is registered. UI gates the create-affordance on this. AURA-IS-CANONICAL — composes three cross-feature signals no single sObject/Tooling field exposes.
-
-**Call:** `GET /headless/invoke/platform/appclone-builder/is-migration-and-developer-ready`
-
-**Output:** Boolean scalar. true when ECA migration is not in progress AND caller has View Setup AND a non-blank Mobile Publisher developer id is registered. false blocks the create-affordance in the UI.
-
-#### `getMyS1HomePageModel_1`
-
-Loads MyS1HomePageModel composing active+archived clones, available apps, ECA-migration flags, sandbox/prod, allowDelete, CAMA project+DistributionScope picklists, rename/archive gate, and per-user UX state. Returns hasAccess=false without CAN_VIEW_APP_CLONE / USER_HAS_MANAGED_ECAENABLED. AURA-IS-CANONICAL — AppClone sObject SOQL cannot reconstruct the cross-feature composition.
-
-**Call:** `GET /headless/invoke/platform/appclone-builder`
-
-**Output:** Composite model. appClones + archivedAppClones (AppCloneUIModel[]), availableApps (AvailableApp[]), org-state flags (isEcaMigrationOrgPrefEnabled, allowDelete, orgHasMyCommunity, orgHasEca, orgHasSAppEnabledForEca, isSandbox, isProjectRenameArchiveEnabled, hasArchivedAppClones, showPlannedMigrationWarning, hideCASwitcherModal), template (name required=true maxLength=50, isEcaEnabled, isArchived) constraining new clone names, and hasAccess=false when caller lacks View Setup / USER_HAS_MANAGED_ECAENABLED.
-
-**Notes:** invocation_note: On mounts that support only direct-className dispatch, invoke via envelope body={className, action, params_schema, body, query_params} rather than {method, path, body, query_params}. Include every method parameter in params_schema and place argument values in the nested body. Route-mode envelopes 400 with 'className required for direct invocation' on such mounts.
-
-#### `getDeveloperId_1`
-
-Returns the Mobile Publisher developer-account identifier registered for this org, or null when the caller lacks View Setup. Refuses during ECA migration. Use this when the exact identifier is needed; isMigrationAndDeveloperReady only returns whether a non-blank identifier is present.
-
-**Call:** `GET /headless/invoke/platform/appclone-setup/my-s1-home/get-developer-id`
-
-**Output:** String developer-account identifier, or null when unavailable.
-
-### Write operations
-
-#### `createNewAppClone_1`
-
-Provisions a non-CAMA AppClone. Before creation, require isMigrationAndDeveloperReady=true and a selectable matching entry from the current getAvailableApps response. Do not call this operation with appType=CAMA or for an entry whose hasCamaProject value is true. CAMA creation through this Aura surface is rejected; use the approved skill managing-mobile-publisher-connect-api-sfdc.mobile-publisher.connect.api-oas-67.0. Returns AppCloneUIModel and refuses during ECA migration.
-
-**Call:** `PATCH /headless/invoke/platform/appclone-builder/create-new-app-clone`
-
-**Depends on:** `getAvailableApps_1`, `isMigrationAndDeveloperReady_1`
-
-#### `updateManagedPackage_1`
-
-Acknowledges a managed-package update for the named clone and OS after the user has completed the external package installation using installPackageUrl. The controller forces the package-update lifecycle action regardless of the supplied lifecycleAction. Refuses during ECA migration. Do not call this operation to initiate or perform the package installation.
-
-**Call:** `PATCH /headless/invoke/platform/appclone-builder/update-managed-package`
-
-**Depends on:** `getMyS1HomePageModel_1`
-
-### Destructive operations
-
-#### `deleteAppClone_1`
-
-Deletes the AppClone by id. Honors org-level allowDelete pref and AppCloneStandardEntity validation; refuses during ECA migration. AURA-IS-CANONICAL — no Connect DELETE on /connect/mobilepublisher/appCloneApps/{id}; raw sObject DELETE bypasses both gates.
-
-**Call:** `DELETE /headless/invoke/platform/appclone-builder/delete-app-clone`
-
-**Depends on:** `getMyS1HomePageModel_1`