@salesforce/afv-skills 1.64.0 → 1.65.0

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

@@ -0,0 +1,227 @@
+---
+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

@@ -0,0 +1,94 @@
+---
+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

@@ -0,0 +1,254 @@
+---
+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

@@ -0,0 +1,38 @@
+---
+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`