@salesforce/afv-skills 1.65.0 → 1.66.0

package/skills/experience-record-discovery-query/SKILL.md

@@ -1,227 +0,0 @@
----
-name: experience-record-discovery-query
-description: "Read-only method for finding, listing, looking up, filtering, or identifying Salesforce records and setup entities through Headless-360. Before loading as a fallback, discover a task recipe for the requested result, even for a list or count constrained by a condition or relationship. If one fits, describe and follow it; use this skill only when none fits, or after a chosen recipe needs an entity resolved to its Id or API name. Covers Enterprise-vs-Tooling routing, SOSL-vs-SOQL selection, and proving a negative. Do not use for writes."
-metadata:
-  version: "1.0"
----
-
-# Finding records and metadata (record discovery)
-
-**Scope check.** Before loading this skill as a fallback, discover a recipe
-for the requested task, including requests phrased as a list or count of
-records matching a condition or relationship. If a recipe fits, describe and
-follow it. Use this skill only when no recipe fits, or when a chosen recipe
-needs an entity resolved as an input. Discover and describe the task recipe
-before asking for a missing or masked identifier. A query or evidence list may
-support the recipe, but it is not by itself an answer to the task.
-
-When the user asks to find, list, look up, or filter records or setup entities
-("show me all …", "find the … named …", "which … have …"), resolve it through
-the Headless-360 tools — never from memory of Salesforce schema.
-
-**Step 1 — Identify the entity type.** Before calling any discovery or query tool,
-check whether the user supplied only a bare category term. For bare
-"permissions", "licenses", "rules", "apps", or "agents" (including singular
-forms), ASK which specific kind they mean; several Salesforce entities fit each
-term. Do not select an API name or query one of them. A qualifier that identifies
-a kind (for example, "permission set licenses", "validation rules", "connected
-apps", or "Agentforce agents") resolves directly; it is not a bare category.
-Otherwise map the user's term to a Salesforce API name. Proceed only when confident:
-you can state the exact API name and no other object — including a closely related
-object in the same family (an assignment, license, or group variant) — is a plausible
-match. Recognizing the concept isn't the same as being confident which object to
-query: "permission sets" has several real, queryable variants (PermissionSet,
-PermissionSetAssignment, PermissionSetGroup, PermissionSetLicense). That family
-overlap, not just an unfamiliar acronym, is reason enough to fetch rather than guess.
-Otherwise — an unfamiliar acronym, synonym, colloquialism, or a term with a plausible
-rival object — fetch `describe({"id": "ref:record-discovery/assets/object-synonyms"})`
-before choosing an API name; do not ask instead of fetching. Use these exact arguments:
-
-```json
-{"id": "ref:record-discovery/assets/object-synonyms"}
-```
-
-This is an H360 reference artifact, not a file in this skill: do not use
-`skill read` for `assets/object-synonyms`, and use the `id` string exactly as
-shown above. The artifact has a known id, so it does not require `discover`
-first. If the
-reference does not resolve the term and more than one entity plausibly
-matches, ASK. Never guess an API name that could silently query the wrong
-entity.
-
-**Step 2 — Infer the API family, then try it and flip once if wrong.** Do NOT read
-describe-global to learn the family, and do NOT keep a memorized Tooling list. Decide
-the family by what the entity *is*:
-- **Tooling** = *definitions of code or schema* — Apex (class/trigger), Flow /
-  FlowDefinition, ValidationRule, WorkflowRule, CustomField, FlexiPage, WebLink,
-  EntityDefinition. "The metadata that defines how the org is built."
-- **Enterprise** = *records and anything with rows you query, assign, or own* — this
-  covers ordinary data (Account, Contact, `*__c`, …) **and** the admin/config objects
-  that store rows: PermissionSet, PermissionSetGroup, Profile, User, UserRole, Group,
-  RecordType, licenses, ConnectedApplication, TabDefinition. These *feel* like setup
-  but are Enterprise — route them to Enterprise first.
-- Mnemonic: **a definition of code or schema → Tooling; anything with rows you'd query,
-  assign, or own → Enterprise.**
-- **Query your inferred family first; flip ONCE on a clean miss.** A wrong family
-  returns `400 sObject type not supported`. On that error, retry the same query on the
-  other family's path. If the *other* path also errors, the problem is the API name,
-  not the family — stop flipping: re-resolve the name (Step 1) or do ONE basic describe,
-  then report. One flip, never a back-and-forth.
-- **Do not infer absence from a failed or incomplete read.** An unsupported-entity
-  error or a metadata parent response that omits named children does not prove
-  there are no matches. Follow the bounded error-recovery steps below; if the
-  available tools cannot enumerate the requested items, say that you could not
-  verify the result instead of reporting zero.
-- If an entity appears in BOTH families, prefer the Enterprise API.
-- **Query the entity resolved in Step 1 — never substitute a related object.**
-  For "my" / "assigned to me", filter rather than switch FROM: if the entity
-  has no direct owner field, filter via a subquery against its
-  assignment/ownership object — `WHERE Id IN (SELECT <ParentField> FROM
-  <AssignmentObject> WHERE <AssigneeField> = ...)` — querying that object
-  only to supply the filter, never as the result itself.
-- Reuse the exact API version segment the tools return in their paths; never
-  invent or change a version number.
-
-**Step 3 — Resolve the name field by a cheap ladder, not an up-front describe.**
-Do NOT describe the entity first just to learn its name field — a full describe
-floods context and is unnecessary on almost every turn. Instead assume the field
-is `Name` and query it. If the query errors with `400 No such column 'Name'`,
-retry once with `MasterLabel`. Only if THAT also errors — the rare double miss
-(e.g. ValidationRule needs `ValidationName`, ExternalClientApplication needs
-`DeveloperName`) — do ONE basic sObject describe to read the true name/label
-field, then query with it. Most entities resolve at `Name` or `MasterLabel`, so
-you pay the describe only on the outliers. A wrong name field errors cleanly
-(`400 No such column`), which is exactly what makes this ladder safe — you always
-get a signal to step down. Never open with a full `/describe` or a
-describe-global for this.
-
-**Step 4 — Choose the search and run it (read-only).** First decide predicate
-vs semantic — it determines which search to use. SOSL is NOT Enterprise-only; it
-works across many families but does not cover every entity (most Tooling/setup
-*definition* entities are not in the SOSL index), whereas SOQL works on anything
-queryable. So:
-- **By name / identifier (predicate)** — the user names a specific record
-  ("the … named X", "the … called X", a specific identifier). **Try SOSL first,
-  regardless of family** — a single SOSL search covers all the entity's name fields
-  at once, so on entities it covers you skip the Step-3 name-field ladder entirely.
-    - **If SOSL errors** (e.g. the entity is not SOSL-searchable — a Tooling
-      definition type returns an invalid-RETURNING-type error), **fall back to SOQL**:
-      route by the inferred family (Step 2, flip once on a family error) and match with
-      `WHERE <labelField> LIKE '%…%'`, where `<labelField>` comes from the Step-3
-      ladder (`Name` → `MasterLabel` → describe).
-    - **If SOSL returns zero rows, that is a valid "none found" — stop.** Do NOT fall
-      back to SOQL on an empty SOSL result; only a SOSL *error* triggers the fallback.
-      (Known limitation: SOSL indexing is not synchronous, so a just-created record can
-      be briefly invisible to SOSL and read as "none found." Narrow edge in a read flow;
-      accepted.)
-- **By description / free-text meaning (semantic)** — the user describes a topic
-  rather than naming a record ("… that mention X", "… related to X", "… about X").
-  **Do NOT use SOSL for these — use SOQL directly.** Route by the inferred family
-  (Step 2) and build a `WHERE … LIKE` against the entity's descriptive text fields,
-  resolving the field via the Step-3 ladder. SOSL is only for by-name lookups; using
-  it for a topic query wastes a round-trip and often errors.
-- **By count or other aggregate ("how many …", "total …", "average …")** — build
-  the aggregate SOQL (`COUNT()`, `SUM()`, `AVG()`, etc.) for the entity, route by
-  the inferred family (Step 2) exactly like any other SOQL, and `dispatch` it
-  through that family's query path. Whatever you report in Step 5 is the value
-  that path actually returned — there is no render-time query execution, so never
-  hand an un-dispatched query string to a rendering tool and call that "running" it.
-- Pass the query string through the tool's query-parameter map (q), never
-  inline in the URL path — an inline query is rejected before it reaches the org.
-- If a query errors, read the error and fix the specific cause (wrong field,
-  wrong family, wrong path) — do not re-issue the same shape hoping for a
-  different result. Two failed attempts on one entity means describe it once
-  and correct the field/path before trying a third.
-
-**Bound the result.** For a list, select only fields you will display and cap
-the search or query at 25 rows.
-
-**Tooling query recipes (reference).** For the
-Tooling entities below, query the tooling query path (`/services/data/vXX.X/tooling/query`,
-SOQL only) with the given SELECT and filter on the name field. These are correct as
-written — do NOT first try the Enterprise `/query` path, and do NOT fall back to a heavy
-endpoint (the UI tabs endpoint `/services/data/vXX/tabs`, the Metadata API read path,
-or a per-type describe / describe-global) — they return visual/metadata blobs and are
-never needed for find/list/count. If a thin query returns fewer fields than you want,
-add fields to the SELECT — do not switch to a heavier endpoint.
-
-| API name | Tooling SELECT (filter on name field with LIKE '%term%') |
-  |---|---|
-| TabDefinition (custom tabs) | `SELECT Id, Label, Name FROM TabDefinition WHERE IsCustom = true AND Label LIKE '%…%'` — Enterprise `/query` path, NOT tooling (CustomTabDefinition is NOT a queryable type in this org) |
-| ValidationRule | `SELECT Id, ValidationName, Active, EntityDefinition.DeveloperName FROM ValidationRule WHERE ValidationName LIKE '%…%'` |
-| FlexiPage | `SELECT Id, DeveloperName, MasterLabel, Type FROM FlexiPage WHERE MasterLabel LIKE '%…%'` |
-| WebLink | `SELECT Id, Name, PageOrSobjectType FROM WebLink WHERE Name LIKE '%…%'` |
-| ApexClass | `SELECT Id, Name, ApiVersion FROM ApexClass WHERE Name LIKE '%…%'` |
-| ApexTrigger | `SELECT Id, Name, TableEnumOrId, Status FROM ApexTrigger WHERE Name LIKE '%…%'` |
-| FlowDefinition | `SELECT Id, DeveloperName, ActiveVersionId FROM FlowDefinition WHERE DeveloperName LIKE '%…%'` |
-| WorkflowRule | `SELECT Id, Name, TableEnumOrId FROM WorkflowRule WHERE Name LIKE '%…%'` |
-| EntityDefinition (custom objects) | `SELECT Id, DeveloperName, QualifiedApiName, Label FROM EntityDefinition WHERE QualifiedApiName LIKE '%\_\_c'` |
-
-**Custom objects — escape the `__c` suffix.** To list custom objects, query
-EntityDefinition on the tooling path filtering on the API-name suffix `__c`. In SOQL `_`
-is a single-char wildcard, so you MUST backslash-escape the two underscores to match a
-LITERAL `__c`: write `WHERE QualifiedApiName LIKE '%\_\_c'`. (Unescaped `'%__c'` matches
-any object ending "<anychar><anychar>c" — e.g. dozens of system *Metric objects — an
-inflated, wrong answer.) Many orgs have zero custom objects; returning none is correct.
-
-**Name-field matching (optimization — an OR-set can save a step).** The single
-record-name field can silently miss label matches. When you already know the entity's
-candidate name fields (e.g. the directory was fetched and gave a name-field hint), you
-MAY search them as an OR-set in one query —
-`WHERE (Name LIKE '%…%' OR Label LIKE '%…%' OR MasterLabel LIKE '%…%')`, limited to that
-entity's fields — instead of stepping through the Step-3 ladder. This is an optional
-speed-up, not required: the ladder alone is sufficient and correct.
-
-**Describe-once backstop (only after the flip and the ladder are exhausted).** Family is
-handled by infer + flip-once (Step 2) and the name field by the ladder (Step 3). Only when
-BOTH have failed — the query errored on both family paths, or stepped past `MasterLabel` —
-do ONE live basic sObject describe (`GET …/tooling/sobjects/<X>` or the Enterprise
-equivalent, ~1.3 KB) to read the true family/name field, then retry once. Never describe
-blindly up front, and never fall back to a full `/describe` or a describe-global.
-
-**Step 5 — Present results.** Always render with `show_details` — never plain prose,
-and never the generic `render_lightning_types` tool (its `type` values are for other
-callers' registered Lightning types, none of which apply here; a fabricated type name
-silently hangs the chat). This applies just as much when there's no list of records to
-show — an aggregate result, a status, a single fact — as when there is: put whatever
-you're reporting in `show_details`'s `summary`, with `fields` left empty if there's
-nothing to break out. An empty `fields` array is never a reason to reach for
-`render_lightning_types` instead.
-
-For an open-ended "tell me everything about X" request, follow a **fixed** plan so
-the result is the same every time — do not improvise how much to pull:
-1. Resolve the record once (Steps 1–4).
-2. Read that one record's own fields (a single record read / describe). Present
-   those.
-3. **Stop there.** Do NOT enumerate related child records — assignments, member
-   permissions, field-permissions, usages, dependencies — as part of "everything
-   about." Those vary wildly in volume and make the answer unstable.
-4. If related data is likely relevant, **name the categories** available (e.g.
-   "I can also pull its assigned users, object permissions, or field permissions")
-   and offer to fetch them — let the user pick, rather than pulling a variable
-   amount unprompted.
-
-If more than one entity or record plausibly matches the request, show the
-candidates and ask the user which they meant — never silently pick one. If
-nothing matches, say so and offer to broaden the search.
-
-You are read-only in this flow: never create, update, freeze, or delete a record
-as part of discovery. If the user's next step is a change, follow the
-confirm-before-write rule from your base instructions.
-
-<!-- skill-validate: ignore-start -->
-<!-- codey:operations start -->
-## Operations Reference
-
-Operations this skill uses — routing and dependency reference.
-
-| Operation | Purpose | Status | Call | Depends on |
-|-----------|---------|--------|------|------------|
-| `sosl-name-search` | read | — | `GET /services/data/v68.0/search` | — |
-| `soql-query-enterprise` | read | — | `GET /services/data/v68.0/query` | — |
-| `soql-query-tooling` | read | — | `GET /services/data/v68.0/tooling/query` | — |
-| `sobject-basic-info` | read | — | `GET /services/data/v68.0/sobjects/{sobjectApiName}` | — |
-| `tooling-sobject-basic-info` | read | — | `GET /services/data/v68.0/tooling/sobjects/{sobjectApiName}` | — |
-| `read-record-by-id` | read | — | `GET /services/data/v68.0/sobjects/{sobjectApiName}/{recordId}` | `sosl-name-search` |
-<!-- codey:operations end -->
-<!-- skill-validate: ignore-end -->

package/skills/experience-regenerate-previews-open/SKILL.md

@@ -1,94 +0,0 @@
----
-name: experience-regenerate-previews-open
-description: "Use this skill when users want to navigation-only Setup recipe: invalidate cached ContentDocument preview renditions so the platform regenerates them on next access. Trigger when users mention regenerate, previews, regenerate previews."
-metadata:
-  version: "1.0"
----
-
-# Managing Regenerate Previews
-
-## When to Use This Skill
-
-Navigation-only Setup recipe: invalidate cached ContentDocument
-preview renditions so the platform regenerates them on next
-access. Driven via the Setup UI at
-/lightning/setup/RegeneratePreviews/home; gated by Customize
-Application perm and the Files/Content org features.
-
-No public API exposes this verb. Connect / Tooling / Metadata /
-sObject / LDS-GraphQL all eliminate: 0 spec hits across
-core-yamls + core-generated-yamls; live-org Tooling probe →
-INVALID_TYPE on SOQL and 404 on describe; rendition-cache state
-is runtime-only, not Metadata-deployable; setup manifest's
-`getRenditionDeleteURL` is a UI URL method, not @AuraEnabled.
-
-The three extractor-emitted steps (list/get/create
-RegeneratePreview Tooling sObject) target a fabricated entity
-that does NOT exist on the live org. Do not call them. Direct
-admins to the Setup page (see navigate_regenerate_previews_setup).
-
-## Critical Constraints
-
-**Preconditions:**
-
-- User has the Customize Application permission and is not in a build-template context. (check: `Customize Application permission`)
-- Org has Content/Files enabled (Content, Files Tab, or Content Distributions). (check: `Salesforce CRM Content enabled || Files tab enabled || Content Deliveries enabled`)
-- Org is not in deck-assembly mode. (check: `!Deck assembly feature`)
-
-## Operations Reference
-
-Operations grouped by purpose. Use these as the building blocks for the workflows above.
-
-### Summary
-
-| Operation | Purpose | Status | Call | Depends on |
-|-----------|---------|--------|------|------------|
-| `list_RegeneratePreview_1` | read | — | `query.RegeneratePreview` | — |
-| `get_RegeneratePreview_1` | read | — | `sobjects/RegeneratePreview/{id}` | — |
-| `create_RegeneratePreview_1` | write | — | `sobjects/RegeneratePreview` | — |
-| `navigate_regenerate_previews_setup` | navigate | — | — | — |
-| `gap_no_api_regenerate_previews` | — | — | — | — |
-
-### Read operations
-
-#### `list_RegeneratePreview_1`
-
-DO NOT CALL. Targets a fabricated `RegeneratePreview` Tooling
-sObject that does not exist on Salesforce: live-org SOQL returns
-400 INVALID_TYPE; tooling describe returns 404. The
-rendition-cache state has no API surface; admins use the Setup
-page at /lightning/setup/RegeneratePreviews/home instead.
-
-**Call:** `query.RegeneratePreview`
-
-#### `get_RegeneratePreview_1`
-
-DO NOT CALL. Targets a fabricated `RegeneratePreview` Tooling
-sObject. Tooling describe returns 404 on
-/sobjects/RegeneratePreview/describe. Use the Setup page at
-/lightning/setup/RegeneratePreviews/home.
-
-**Call:** `sobjects/RegeneratePreview/{id}`
-
-### Write operations
-
-#### `create_RegeneratePreview_1`
-
-DO NOT CALL. Targets a fabricated `RegeneratePreview` Tooling
-sObject; entity does not exist. The underlying admin verb
-(delete cached ContentDocument renditions to force
-regeneration) is exposed only through the Setup UI URL method
-`getRenditionDeleteURL`. Direct admins to
-/lightning/setup/RegeneratePreviews/home.
-
-**Call:** `sobjects/RegeneratePreview`
-
-### Other operations
-
-#### `navigate_regenerate_previews_setup`
-
-Open the Regenerate Previews Setup page. The admin clicks the
-page action there to invalidate cached ContentDocument
-renditions; the platform regenerates them on next access.
-
-#### `gap_no_api_regenerate_previews`

package/skills/experience-sales-cloud-mab-configure/SKILL.md

@@ -1,254 +0,0 @@
----
-name: experience-sales-cloud-mab-configure
-description: "Use this skill when users want to configure the Sales Cloud mobile app builder for the Seller-Focused Experience — list, create, clone, update, and delete app configs and their per-object record home configs, assign profiles, and publish. Trigger when users mention sales, cloud, mab, sales cloud mab."
-metadata:
-  version: "1.0"
-  accessCheck: "MobileBuilder.userCanViewMobileBuilder"
----
-
-# Managing Sales Cloud Mab
-
-## When to Use This Skill
-
-Configure the Sales Cloud mobile app builder for the Seller-Focused Experience — list, create, clone, update, and delete app configs and their per-object record home configs, assign profiles, and publish. Covers only the Seller-Focused operations of this shared builder; CAMA / Agentforce-action operations are explicitly out of scope (they route to a different service and belong to a separate SOR). DESTRUCTIVE: delete-app-config permanently removes an app config and all its record home configs, and delete-record-home-config removes a single object's record home config — both are unrecoverable, so confirm with the admin before invoking.
-
-## Workflow
-
-Typical create flow: get-apps → create-app-config → get-entities → create-sc-record-home-config (one per object; this publishes) → assign-profiles.
-
-Sequencing constraint — assign-profiles: a profile can only be assigned to a published app config, and an app config with zero record home configs is never published. So always create at least one record home config (via create-sc-record-home-config, which publishes internally) before calling assign-profiles. The backend does not enforce this; the agent must, to match what the admin UI allows.
-
-Reuse appId from get-apps output across all downstream steps that need an app reference. For create-sc-record-home-config, source objectApiName (the value) and objectName (the display text) from get-entities. API Name for create/clone is normally derived from the App Name label (no special characters, no whitespace, no consecutive underscores; must be unique among existing app configs) — don't prompt the user for it separately. contentTypeFqn is not used by this builder; omit it.
-
-Reuse experienceContainerId and the other fields from get-profile-assignments output when calling assign-profiles — read existing values and reuse them.
-
-Verify-after-write: after create / clone / delete-app-config → re-read get-apps (presence/absence of the appId); after update-app-config → get-apps and check the label changed (NOT state); after create / delete-sc-record-home-config → get-sc-record-home-config-summary; after assign-profiles → get-profile-assignments; after publish-experience-metadata → get-apps and check lastPublished advanced (NOT state).
-
-Backend mechanics and constraints:
-- Content type: this builder serves the experience__scmabRecordHome content type.
-- Two-stage model: (1) top-level app configuration — an Experience Container created with an App Name and an API Name; a newly created app config is empty and unpublished. (2) per-object record home configurations — within an app config, create one record home page layout per object (e.g. Account, Contact). Creating a record home config publishes the app metadata as a side effect, so publish-experience-metadata is usually redundant in normal flows.
-- appType is constrained to Scma for this SOR — a single valid value, not a multi-option enum.
-- Dispatch: all operations dispatch through a shared internal UI controller via /headless/invoke/platform/sales-cloud-mab/.... This controller is shared across all six Mobile Builder flavors; only the Seller-Focused operations are in scope for this SOR.
-- Operation inventory: list app configs (get-apps), create / clone / update / delete app configs, list / create / delete per-object record home configs, list available objects (get-entities), assign profiles, and publish.
-- Deletion detail: delete-app-config unassigns any assigned profiles first, then permanently removes the app config and all its record home configs; delete-record-home-config removes a single object's record home config. Both are unrecoverable.
-- Do NOT rely on the state field returned by get-apps — it is hardcoded to DRAFT. Determine published status from the lastPublished timestamp instead.
-
-## 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-record-home-config`** — Delete a single object's record home configuration from an app config. Takes appId and contentKey. DESTRUCTIVE and unrecoverable. Confirm with admin before invoking. Verify via get-sc-record-home-config-summary (contentKey should be absent).
-  - Rollback: No automatic rollback.
-- **`delete-app-config`** — Delete a top-level SCMA app and all its record-home configs via the Applications Connect API
-(POST /services/data/v67.0/applications/delete/{appIdOrDevName}). Identify the app by id (8sa...)
-or developerName in the path; appType is NOT in the URL (resolved from the stored container).
-Empty body. DESTRUCTIVE and unrecoverable — confirm with admin before invoking. Returns
-{deletedExperienceContainerId, status:DELETED}. Verify via get-apps (appId absent).
-  - 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/sales-cloud-mab` | — |
-| `get-apps-and-guardrails-info` | read | proposed | `GET /headless/invoke/platform/sales-cloud-mab/get-apps-and-guadrails-info` | — |
-| `get-profile-assignments` | read | proposed | `GET /headless/invoke/platform/sales-cloud-mab/get-profile-assignments` | — |
-| `assign-profiles` | write | proposed | `PATCH /headless/invoke/platform/sales-cloud-mab/assign-profiles` | `create-sc-record-home-config` |
-| `update-app-config` | write | proposed | `POST /services/data/v67.0/applications/update/{appIdOrDevName}/Scma` | — |
-| `get-sc-record-home-config-summary` | read | proposed | `GET /headless/invoke/platform/sales-cloud-mab/get-sc-record-home-config-summary` | — |
-| `delete-record-home-config` | delete | proposed | `DELETE /headless/invoke/platform/sales-cloud-mab/delete-record-home-config` | — |
-| `create-sc-record-home-config` | write | proposed | `PATCH /headless/invoke/platform/sales-cloud-mab/create-sc-record-home-config` | — |
-| `create-app-config` | write | proposed | `POST /services/data/v67.0/applications/create/Scma` | — |
-| `get-variant-id` | read | implemented | `GET /headless/invoke/platform/sales-cloud-mab/get-variant-id` | — |
-| `publish-experience-metadata` | write | proposed | `PATCH /headless/invoke/platform/sales-cloud-mab/publish-experience-metadata` | — |
-| `get-entities` | read | implemented | `GET /headless/invoke/platform/sales-cloud-mab/get-entities` | — |
-| `clone-app-config` | write | proposed | `PATCH /headless/invoke/platform/sales-cloud-mab/clone-app-config` | — |
-| `delete-app-config` | delete | proposed | `POST /services/data/v67.0/applications/delete/{appIdOrDevName}` | — |
-
-### Read operations
-
-#### `get-apps`
-
-List all Seller-Focused app configurations (Experience Containers) of type Scma. Returns appId, apiName, appName (label), state (always DRAFT — ignore it), lastPublished timestamp (the real publish indicator), and profile assignments. Use this to enumerate existing configs or verify create/update/delete operations.
-
-**Call:** `GET /headless/invoke/platform/sales-cloud-mab`   — status: `proposed`
-
-**Inputs:**
-
-- `appType` *(`String`)*
-
-#### `get-apps-and-guardrails-info`
-
-List app configurations with additional guardrails metadata. Returns the same core fields as get-apps plus guardrails-specific info. Most flows use get-apps; use this when you need guardrails context.
-
-**Call:** `GET /headless/invoke/platform/sales-cloud-mab/get-apps-and-guadrails-info`   — status: `proposed`
-
-**Inputs:**
-
-- `appType` *(`String`)*
-
-#### `get-profile-assignments`
-
-List profile assignment possibilities for Seller-Focused apps. Returns all profiles in the org with their current assignment state (experienceContainerProfileAssignmentId is non-null if assigned). Use before assign-profiles to read current state.
-
-**Call:** `GET /headless/invoke/platform/sales-cloud-mab/get-profile-assignments`   — status: `proposed`
-
-**Inputs:**
-
-- `appType` *(`String`)*
-
-#### `get-sc-record-home-config-summary`
-
-List record home configurations within an app config. Takes appId. Returns one entry per object (objectApiName, contentKey, objectName). Use to enumerate existing object configs or verify create/delete-record-home-config.
-
-**Call:** `GET /headless/invoke/platform/sales-cloud-mab/get-sc-record-home-config-summary`   — status: `proposed`
-
-**Inputs:**
-
-- `appId` *(`String`)*
-
-#### `get-variant-id`
-
-Get the variant ID for an app config. Takes appId. Returns the variant identifier. Used internally by the UI; most agent flows don't need this.
-
-**Call:** `GET /headless/invoke/platform/sales-cloud-mab/get-variant-id`   — status: `implemented`
-
-**Inputs:**
-
-- `appId` *(`String`)*
-
-#### `get-entities`
-
-List available objects (entities) that can have record home configurations. Returns value (objectApiName) and text (objectName display label). Use before create-sc-record-home-config to source objectApiName and objectName.
-
-**Call:** `GET /headless/invoke/platform/sales-cloud-mab/get-entities`   — status: `implemented`
-
-### Write operations
-
-#### `assign-profiles`
-
-Assign or unassign profiles to/from an app config. Takes profileAssignments (a list of assignment records with profileId, experienceContainerId, and experienceContainerProfileAssignmentId). Read current state via get-profile-assignments first, modify the list, then send. SEQUENCING: can only assign to a published app config (one with ≥1 record home config).
-
-**Call:** `PATCH /headless/invoke/platform/sales-cloud-mab/assign-profiles`   — status: `proposed`
-
-**Inputs:**
-
-- `profileAssignments` *(`List<Map<String, Object>>`)* — Value for profile assignments.
-
-**Depends on:** `create-sc-record-home-config`
-
-#### `update-app-config`
-
-Update a Seller-Focused (SCMA) app via the Applications Connect API
-(POST /services/data/v67.0/applications/update/{appIdOrDevName}/Scma). STAGE 2 of the two-stage
-model: this is where the per-object record-home layouts are set, via contents.experience__scmabRecordHome
-(a list of per-object entries — objectApiName, objectName, sfdc_cms:title, and an sfdc_cms:block tree).
-Can also update the label. Identify the app by id (8sa...) or developerName in the path. All body
-fields optional; contents items WITH an id are updated, WITHOUT an id are created; deleteResourceIds
-removes resources. Returns 201 {status:DRAFT, created/updated/deletedResourceIds}.
-
-BLOCK-TREE RULES (record-home layout): two parent containers —
-experience/scmabRecordHomeFixedContainer and experience/scmabRecordHomeContainer.
-- FixedContainer allows ONLY: scmabHighlights, scmabActions, scmabStackedTabs — and scmabStackedTabs
-  MUST be last.
-- scmabStackedTabs may instead live in scmabRecordHomeContainer, but there must be NO duplicate (at
-  most one across both containers).
-- RecordHomeContainer allows ONLY: scmabActivityTimeline, scmabPath, scmabRelatedList — in any order.
-
-**Call:** `POST /services/data/v67.0/applications/update/{appIdOrDevName}/Scma`   — 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-sc-record-home-config`
-
-Create a record home page layout for one object within an app config. Takes appId, objectApiName, and objectName (source both from get-entities). PUBLISHES INTERNALLY — after this succeeds, the app's lastPublished timestamp advances. Verify via get-sc-record-home-config-summary (new objectApiName/contentKey present).
-
-**Call:** `PATCH /headless/invoke/platform/sales-cloud-mab/create-sc-record-home-config`   — status: `proposed`
-
-**Inputs:**
-
-- `appId` *(`String`)* — Id of the app.
-- `objectApiName` *(`String`)* — Name of the object api.
-- `objectName` *(`String`)* — Name of the object.
-
-#### `create-app-config`
-
-Create a new top-level Seller-Focused (SCMA) app configuration via the Applications Connect API
-(POST /services/data/v67.0/applications/create/Scma). STAGE 1 of the two-stage model: body is
-developerName + label + minimal contents {experience__scmaECDefinition: [{}]}. Returns 201
-{id, name, type:Scma, isPublished:false}; the id is the experienceContainerId used by the update
-step (STAGE 2, which adds the per-object record-home layouts) and by delete. New configs are empty
-(0 record-home configs) and unpublished. Verify via get-apps (new appId/name present).
-
-**Call:** `POST /services/data/v67.0/applications/create/Scma`   — 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 an app config's metadata. Takes appId. This operation is somewhat redundant in normal flows — create-sc-record-home-config already publishes internally. Use when you need explicit publish without adding an object config. Verify via get-apps (lastPublished timestamp advanced; not state).
-
-**Call:** `PATCH /headless/invoke/platform/sales-cloud-mab/publish-experience-metadata`   — status: `proposed`
-
-**Inputs:**
-
-- `appId` *(`String`)* — Id of the app.
-
-#### `clone-app-config`
-
-Clone an existing app config. Takes appType (Scma), the source appId, new label, and new apiName (derive from label). Creates a new app config with the same record home configs as the source. If the source has ≥1 object config, the clone is published immediately. Verify via get-apps (cloned appId/apiName present).
-
-**Call:** `PATCH /headless/invoke/platform/sales-cloud-mab/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-record-home-config`
-
-Delete a single object's record home configuration from an app config. Takes appId and contentKey. DESTRUCTIVE and unrecoverable. Confirm with admin before invoking. Verify via get-sc-record-home-config-summary (contentKey should be absent).
-
-**Call:** `DELETE /headless/invoke/platform/sales-cloud-mab/delete-record-home-config`   — status: `proposed`
-
-**Inputs:**
-
-- `appId` *(`String`)*
-- `contentKey` *(`String`)*
-
-#### `delete-app-config`
-
-Delete a top-level SCMA app and all its record-home configs via the Applications Connect API
-(POST /services/data/v67.0/applications/delete/{appIdOrDevName}). Identify the app by id (8sa...)
-or developerName in the path; appType is NOT in the URL (resolved from the stored container).
-Empty body. DESTRUCTIVE and unrecoverable — confirm with admin before invoking. Returns
-{deletedExperienceContainerId, status:DELETED}. Verify via get-apps (appId absent).
-
-**Call:** `POST /services/data/v67.0/applications/delete/{appIdOrDevName}`   — status: `proposed`
-
-**Inputs:**
-
-- `appType` *(`String`)*
-- `appId` *(`String`)*

package/skills/experience-schema-builder-open/SKILL.md

@@ -1,38 +0,0 @@
----
-name: experience-schema-builder-open
-description: "Use this skill when users want to schema Builder is a UI-only Setup page that visualizes the org's data model (objects, fields, relationships). Trigger when users mention schema, builder, schema builder."
-metadata:
-  version: "1.0"
----
-
-# Querying Schema Builder
-
-## When to Use This Skill
-
-Schema Builder is a UI-only Setup page that visualizes the org's data model (objects, fields, relationships). No public Connect/Tooling/Metadata API exposes this visualization; the underlying schema CRUD lives in peer SORs (CustomObjects, CustomFields). Open view_url for manual use. Requires Customize Application permission.
-
-## Critical Constraints
-
-**Preconditions:**
-
-- The running user must have the Customize Application permission; Schema Builder access is gated on it. (check: `The running user has the Customize Application permission.`)
-- Setup UI must not be restricted for the running user (a license-restricted Setup UI suppresses Schema Builder). (check: `Setup UI is not restricted for the running user.`)
-- The running user must not be a delegated administrator acting in system-administrator mode; the access gate denies Schema Builder access while that mode is active. (check: `The running user is not a delegated administrator acting in system-administrator mode.`)
-
-## Operations Reference
-
-Operations grouped by purpose. Use these as the building blocks for the workflows above.
-
-### Summary
-
-| Operation | Purpose | Status | Call | Depends on |
-|-----------|---------|--------|------|------------|
-| `view_SchemaBuilder_1` | read | — | `SchemaBuilder.view` | — |
-
-### Read operations
-
-#### `view_SchemaBuilder_1`
-
-Open the Schema Builder app at view_url for manual use. The same URL is also returned by the Aura helper getSchemaBuilderUrl (GET /headless/invoke/platform/objectmanager-setup/schema-builder-link/get-schema-builder-url) — calling it just round-trips the value already in view_url, so this step prefers the static value.
-
-**Call:** `SchemaBuilder.view`