@salesforce/afv-skills 1.65.0 → 1.65.1

package/skills/industries-eu-new-connections-configure/SKILL.md

@@ -1,30 +0,0 @@
----
-name: industries-eu-new-connections-configure
-description: "Use this skill when users want to sets up \"New Connection Setup\" (Individual Application milestone + SLA tracking) in an Energy & Utilities Cloud org that has the E&U license provisioned but nothing else configured. Also use when a user says \"set up new connection setup for Energy & Utilities\", \"enable individual application milestone tracking\", or \"stand up SLA milestone tracking for E&U\". Trigger when users mention eu, new, connections, setup, industries, energy, utilities, settings, sla, entitlement, profiles, manage, users, perm, sets, flows, industries energy and utilities settings, sla entitlement settings, manage users, perm sets."
-metadata:
-  version: "1.0"
-  accessCheck: "(IndustriesEnergyAndUtilities.orgHasEnergyUtilities) || (IndustriesEnergyAndUtilities.orgHasIASlaFeatureEnabled)"
----
-
-# Querying Eu New Connections Setup
-
-## When to Use This Skill
-
-Sets up "New Connection Setup" (Individual Application milestone + SLA tracking) in an Energy & Utilities Cloud org that has the E&U license provisioned but nothing else configured. Use when a user says "set up new connection setup for Energy & Utilities", "enable individual application milestone tracking", or "stand up SLA milestone tracking for E&U". This is an ENTRY-POINT SOR: execute phases in declared `phases[]` order, honoring `depends_on` edges. Execute phase-by-phase directly from this recipe: at each phase boundary, RE-READ this SOR's `steps` + `agent_guidance` for the next phase before acting — do not execute from an up-front summarized plan. The per-step guidance carries org-proven gotchas (the Phase 2 profile-fork gate and per-org permission-dependency iteration, the exact Phase 6a FlexiPage Tooling envelope) that a summary silently drops. The headless phases (pref enablement, profile clone, user creation, permission-set assignment, record-page creation) run end-to-end; Phase 7 (the two business flows) is a pure needs-human handoff the agent must surface rather than fake — the flows are managed-package artifacts whose source is not retrievable on a subscriber org. Phase 1 flips both org prefs (euIndvAppEntlFeature then euSimplifiedSlaSetup) via the SAME E&U settings controller (setIndustriesEnergyUtilitiesPref); Phase 2 clones the "New Connection Manager" profile by delegating to the managing-profiles SOR (metadata_api clone via /headless/metadata + a Profile metadata PUT for the role permissions; data-API clone kept as a fallback where Profile.createable is true); Phase 3 OPTIONALLY creates a dedicated connection- manager User via the data API (skip it to let the admin manage connections themselves); Phase 5 assigns the packaged "EAndU Cloud Program Access" permission set via the data API to each recipient — always the running admin, plus the dedicated user if Phase 3 ran, plus any other user the admin names — that permset already carries the Individual Application SLA-field FLS, so there is NO separate FLS phase; Phase 7 is a pure handoff — the two business flows are managed-package artifacts the admin clones/customizes/activates in Flow Builder (not programmatically installable on a subscriber org). PARTIALLY ORG-VALIDATED on an internal test org (Phases 3, 5 mutations confirmed; Phase 1a euIndvAppEntlFeature confirmed; Phase 1b euSimplifiedSlaSetup confirmed 2026-08-09 — write→read-back SUCCESS; the EAndU Cloud Program Access permset's 7-field FLS confirmed 2026-08-07). Phase 1b's FORMER 403 blocker is RESOLVED: the E&U team landed euSimplifiedSlaSetup, a first-class admin-grantable pref that flips the platform Simplified SLA Setup preference without touching the org-provisioned Entitlements gate. It replaces the earlier SLA-management permission path that 403'd. When all phases complete, surface the closing message in Phase 7's agent_guidance verbatim — it lists the two business-specific flows the admin may want to clone, activate, and customize (each backed by a Decision Matrix the admin defines themselves).
-
-## Critical Constraints
-
-**Preconditions:**
-
-- The org must have the Energy & Utilities Cloud license provisioned. The E&U settings controller gates every pref write on "Energy and Utilities settings access"; without the license the euIndvAppEntlFeature toggle is not writable (and getIndustriesEnergyUtilitiesPrefs will not expose it as an enable-able pref). No API provisions a license.
- (check: `IndustriesEnergyAndUtilities.orgHasEnergyUtilities`)
-- The Individual Application Entitlement feature (euIndvAppEntlFeature) must be ON before Phase 1b (euSimplifiedSlaSetup) can be enabled. Simplified SLA Setup's access gate requires the Individual Application Entitlement feature, which is satisfied only once euIndvAppEntlFeature is turned on. Phase 1a satisfies this; the depends_on edge on enable-simplified-sla enforces order. NOTE: this SUPERSEDES the former entitlement-management and ITSM-setup-access preconditions, which gated the retired SLA-management permission path (org-provisioned Entitlements / ITSM-setup-access gates). The E&U pref path does not touch either gate — org-validated on an internal test org 2026-08-09 with no 403.
- (check: `IndustriesEnergyAndUtilities.orgHasIASlaFeatureEnabled`)
-
-## Notes
-
-- **sor_kind:** entry_point
-- **references_sors:** IndustriesEnergyAndUtilitiesSettings, SlaEntitlementSettings, PermSets, MilestoneTypes, managing-profiles
-- **program:** Project Codey — Energy & Utilities New Connection Setup
-- **grounding:** {'date': '2026-07-29', 'method': 'Each of the 7 doc steps was grounded against the corpus via discover + describe. No api path was inferred from the narrative. The E&U Individual App Entitlement pref was additionally confirmed present in the live org pref map (get-industries-energy-utilities-prefs). Nothing else was org-validated at grounding time.\n', 'per_step': [{'step': '1a Individual App Entitlement pref', 'result': 'headless — setIndustriesEnergyUtilitiesPref(euIndvAppEntlFeature)'}, {'step': '1b Simplified SLA / Milestone setup', 'result': "headless — setIndustriesEnergyUtilitiesPref(euSimplifiedSlaSetup) (single-pref write of the platform SimplifiedSLASetup preference; org-validated on an internal test org 2026-08-09). Replaces the retired ITSM setSlaManagementPermission batch path that 403'd on the org-provisioned Entitlements gate.\n"}, {'step': '2 clone profile', 'result': 'headless — EXACT CLONE OF STANDARD USER via metadata deploy, ORG-PROVEN on an internal test org 2026-08-11: READ Standard User\'s Metadata, then POST /headless/metadata {type:"Profile", fullName underscore, xmlRep = custom + userLicense + Standard User\'s full userPermissions + objectPermissions + role closure} → success:true id <new-profile-id>; SOQL confirmed 50 object perms + ApiEnabled=true + 5 role perms. Chosen because it copies Standard User\'s actual baseline rather than a hand-picked subset (a point-in-time snapshot — re-run the clone to pick up later grants). Fallback = data-API recreate (needs Profile.createable). See metadata_clone_org_proven + approach_comparison_note.\n'}, {'step': '3 create user', 'result': 'headless (data API) — POST sobjects/User; needs human identity input. OPTIONAL — skip if the admin will manage connections themselves.\n'}, {'step': '4 field-level security (informational)', 'result': 'NO ACTION — informational phase. The Individual Application SLA-field FLS (plus the EntityMilestone AssignedTo field, plus milestone-related object CRUD) ships with the packaged "EAndU Cloud Program Access" permset, which Phase 5 assigns; a separate FLS grant is redundant (the former phase-4-set-fls step was removed 2026-08-07, org-confirmed). This slot now just explains why there\'s no explicit FLS step and keeps the 1-7 reading order.\n'}, {'step': '5 assign permission set', 'result': "headless (data API) — resolve the packaged EAndU Cloud Program Access permset + the running admin's Id, then POST sobjects/PermissionSetAssignment once per recipient: always the admin, plus the dedicated user if Phase 3 ran, plus any other user the admin names (that permset carries the SLA-field FLS, EntityMilestone.AssignedTo FLS, AND the milestone-related object CRUD perms)\n"}, {'step': '6a place milestoneTracker component as a record-page tab', 'result': 'HEADLESS (tooling_api) — POST a RecordPage FlexiPage on IndividualApplication (or PATCH an existing custom page) with a flexipage:tabset holding Details / Milestone Tracker (the milestoneTracker component) / Related tabs. Org-validated 2026-08-11 (POST 201 / PATCH 204 / GET confirmed). Consultative: admin chooses new page vs. existing page vs. skip. The Salesforce system-default page is not a FlexiPage row and cannot be edited in place — customizing it always creates a new page.\n'}, {'step': '6b activate the record page', 'result': 'NEEDS-HUMAN (manual App Builder step) — applies ONLY when 6a created a NEW page (a new FlexiPage starts inactive). Skipped when 6a added the tab to an existing already-active page (live on PATCH) or was skipped. Activation is NOT headless-callable: page activation is not available through a headless API — it requires the interactive Lightning App Builder UI. The agent MUST tell the admin explicitly to activate it themselves (App Builder → Activation → "Assign as Org Default", or a narrower app/profile/record-type scope). Depends on 6a.\n'}, {'step': '7 hand off the business flows', 'result': 'NO ACTION — pure handoff + completion message. The two flows ("Auto Assign Milestone Owner", "Associate Entitlement with Individual Application") are E&U managed-package artifacts; their source XML is NOT retrievable on a subscriber org (org-proven an internal test org 2026-08-11), so a programmatic clone is not possible, and the required Decision Matrix customization is admin-defined business input. Clone + customize + activate is an admin-only Flow Builder task. An earlier semi-headless /headless/metadata clone + toggleFlowStatus activation proposal was retired 2026-08-11.\n'}]}
-- **headless_coverage:** {'api_driven': ['phase-1-enable-prefs', 'phase-2-clone-profile', 'phase-3-create-user', 'phase-5-assign-permset', 'phase-6a-place-milestone-tracker'], 'needs_human': ['phase-6b-activate-record-page', 'phase-7-milestone-owner-flow'], 'informational': ['phase-4-field-level-security'], 'note': 'The phases are 1/2/3/4/5/6a/6b/7. Phase 4 is INFORMATIONAL (no API, no action): the former phase-4-set-fls step was REMOVED — the SLA-field FLS ships with the packaged "EAndU Cloud Program Access" permset that Phase 5 assigns, so a separate FLS grant is redundant; the Phase 4 slot is retained only to explain that and preserve the sequential reading order; org-confirmed 2026-08-07 that the EAndUCloudProgramPermissionSet permset (resolved by Label/Name — Id is org-specific, don\'t hardcode) carries Read on all 7 IndividualApplication target fields + Edit on the 4 user-writable ones, and it also carries FLS on EntityMilestone.AssignedTo plus milestone-related object CRUD perms; re-confirmed on an internal test org 2026-08-11). Phases 1, 2, 3, 5, 6a are headless end-to-end (Phase 2 delegates to the managing-profiles metadata_api clone; Phase 6a creates the record page + Milestone Tracker tab via the Tooling-API FlexiPage sObject, org-validated 2026-08-11). Phase 6b (activate the page) applies ONLY when 6a creates a NEW page (new FlexiPages start inactive); it is SKIPPED when 6a edits an existing already-active page (live on PATCH) or is skipped. When it runs, 6b is NEEDS-HUMAN — activation is NOT headless-callable — it is not available through a headless API and requires the interactive Lightning App Builder UI. The agent must explicitly hand activation to the admin (App Builder → Activation → "Assign as Org Default"). Phase 7 is a pure needs-human handoff (the two business flows are managed-package artifacts the admin clones/customizes/activates in Flow Builder — not programmatically installable on a subscriber org). 6b depends on 6a. APPROVED by the owning team (EU Cloud - CME - Northern Lights) for Headless 360 serving — see the top-level adoption block. PARTIALLY ORG-VALIDATED on an internal test org: Phases 2, 3, 5 and Phase 1a + 1b mutated + verified, the program permset FLS confirmed (Phase 1b euSimplifiedSlaSetup org-validated 2026-08-09 — the former org-provisioning gap is resolved by the new E&U pref path); Phase 7 performs no automated write (managed-package business-flow handoff). NOTE: Phase 2\'s PRIMARY metadata_api delegation (EXACT CLONE OF STANDARD USER) is now ORG-PROVEN in its own right — the exact-clone metadata deploy was mutation-tested on an internal test org 2026-08-11 (POST /headless/metadata → success:true id <new-profile-id>; SOQL confirmed 50 object perms + ApiEnabled=true + the role-perm closure), on top of managing-profiles\' own prior validation. The data-API path (Profile.createable true on an internal test org 2026-08-04) is the demoted fallback.\n'}

package/skills/industries-explainability-msg-template-configure/SKILL.md

@@ -1,135 +0,0 @@
----
-name: industries-explainability-msg-template-configure
-description: "Use this skill when users want to manage Explainability Msg Template records via standard sObject REST. Trigger when users mention explainability, msg, template, explainability msg template."
-metadata:
-  version: "1.0"
-  accessCheck: "InteractionCalculation.orgHasBREandDESAccess && InteractionCalculation.userHasBREandDESAccess"
----
-
-# Managing Explainability Msg Template
-
-## When to Use This Skill
-
-Manage Explainability Msg Template records via standard sObject REST. Use this to list, retrieve, create, update, or delete Explainability Msg Template entries in Setup.
-
-## Workflow
-
-Standard sObject REST provides full CRUD + describe on ExplainabilityMsgTemplate; no proprietary Aura controller is involved. Fields available at runtime come from /describe — the SOR doesn't enumerate them statically because the shape depends on the org's permission/profile setup. Run /describe first, then construct the payload from the createable fields list.
-
-## Critical Constraints
-
-**Preconditions:**
-
-- User needs access to manage ExplainabilityMsgTemplate (CRUD on the ExplainabilityMsgTemplate sObject). (check: `Business Rules and Decisioning access && Business Rules and Decisioning access`)
-
-## Operations Reference
-
-Operations grouped by purpose. Use these as the building blocks for the workflows above.
-
-### Summary
-
-| Operation | Purpose | Status | Call | Depends on |
-|-----------|---------|--------|------|------------|
-| `describe` | read | — | `GET /services/data/v67.0/sobjects/ExplainabilityMsgTemplate/describe` | — |
-| `list` | read | — | `GET /services/data/v67.0/query` | — |
-| `get-by-id` | read | — | `GET /services/data/v67.0/sobjects/ExplainabilityMsgTemplate/{Id}` | `list` |
-| `create` | write | — | `POST /services/data/v67.0/sobjects/ExplainabilityMsgTemplate` | `describe` |
-| `update` | write | — | `PATCH /services/data/v67.0/sobjects/ExplainabilityMsgTemplate/{Id}` | `get-by-id` |
-| `delete` | write | — | `DELETE /services/data/v67.0/sobjects/ExplainabilityMsgTemplate/{Id}` | `get-by-id` |
-
-### Dependency graph
-
-```mermaid
-graph TD
-  describe["describe (read)"]
-  list["list (read)"]
-  get_by_id["get-by-id (read)"]
-  create["create (write)"]
-  update["update (write)"]
-  delete["delete (write)"]
-  list --> get_by_id
-  describe --> create
-  get_by_id --> update
-  get_by_id --> delete
-```
-
-### Read operations
-
-#### `describe`
-
-Retrieve the ExplainabilityMsgTemplate sObject describe — fields, picklist values, FLS, createable/updateable flags.
-
-**Call:** `GET /services/data/v67.0/sobjects/ExplainabilityMsgTemplate/describe`
-
-**Output:** DescribeSObjectResult for ExplainabilityMsgTemplate — use this to build the field list for list / create / update payloads.
-
-#### `list`
-
-List ExplainabilityMsgTemplate records. Pair this with /describe first to pick field names.
-
-**Call:** `GET /services/data/v67.0/query`
-
-**Inputs:**
-
-- `isDefault` *(`boolean`)* — Filter to the default template only (true) or non-defaults (false). Omit to return both.
-- `messageType` *(`string`)* — Filter by message-type discriminator (matches MessageType field on ExplainabilityMsgTemplate).
-- `searchKey` *(`string`)* — Free-text substring match across template name/message; case-insensitive.
-- `stepType` *(`string`)* — Filter by expression-set step type (matches ExpressionSetStepType on the template).
-- `usageType` *(`string`)* — Filter by emt usage-type discriminator (matches EmtUsageType on the template).
-
-**Output:** Query response with records[] of ExplainabilityMsgTemplate — Id plus any SELECTed fields.
-
-#### `get-by-id`
-
-Retrieve a specific ExplainabilityMsgTemplate record by Id.
-
-**Call:** `GET /services/data/v67.0/sobjects/ExplainabilityMsgTemplate/{Id}`
-
-**Inputs:**
-
-- `messageTemplateId` *(`string`)* — Id of the ExplainabilityMsgTemplate to retrieve. Pattern: ^(8U8)\w* (8U8 prefix per spec).
-
-**Depends on:** `list`
-
-**Output:** Single ExplainabilityMsgTemplate record with all readable fields per user FLS.
-
-### Write operations
-
-#### `create`
-
-Create a new ExplainabilityMsgTemplate record. Run /describe first to learn the required + createable fields.
-
-**Call:** `POST /services/data/v67.0/sobjects/ExplainabilityMsgTemplate`
-
-**Inputs:**
-
-- `body` *(`object`)* — Field/value map for the new ExplainabilityMsgTemplate. Populate from /describe's createableFields list.
-
-**Depends on:** `describe`
-
-**Rollback:** Call delete with the returned Id to undo the create.
-
-#### `update`
-
-Update an existing ExplainabilityMsgTemplate record. Merge-patch semantics.
-
-**Call:** `PATCH /services/data/v67.0/sobjects/ExplainabilityMsgTemplate/{Id}`
-
-**Inputs:**
-
-- `Id` *(`ID`)* — Id of the ExplainabilityMsgTemplate to update.
-- `body` *(`object`)* — Partial field/value map — only include fields you want to change.
-
-**Depends on:** `get-by-id`
-
-#### `delete`
-
-Delete a ExplainabilityMsgTemplate record.
-
-**Call:** `DELETE /services/data/v67.0/sobjects/ExplainabilityMsgTemplate/{Id}`
-
-**Inputs:**
-
-- `Id` *(`ID`)* — Id of the ExplainabilityMsgTemplate to delete.
-
-**Depends on:** `get-by-id`

package/skills/industries-expression-set-message-token-configure/SKILL.md

@@ -1,135 +0,0 @@
----
-name: industries-expression-set-message-token-configure
-description: "Use this skill when users want to registry of named tokens used by the Decision Explainability Service (DES) inside Business Rules Engine expression sets. Trigger when users mention expression, set, message, token, expression set message token."
-metadata:
-  version: "1.0"
-  accessCheck: "InteractionCalculation.orgHasBREandDESAccess && InteractionCalculation.userHasBREandDESAccess"
----
-
-# Managing Expression Set Message Token
-
-## When to Use This Skill
-
-Registry of named tokens used by the Decision Explainability Service (DES) inside Business Rules Engine expression sets. Records here store token names referenced by name from expression-set step token-mapping payloads (`passedMessageTokenMappings` / `failedMessageTokenMappings` / `noResultMessageTokenMappings` arrays on calculation-procedure-step and expression-set-step inputs in industries-interaction-rule-connect-api). Tokens get substituted into Explainability Message Template message bodies at rule evaluation. No proprietary Aura controller and no per-record Connect/Tooling alternative — sObject REST is canonical. Run /describe first to discover the org's createable fields; the entity is gated by the BRE + DES feature flags.
-
-## Workflow
-
-Standard sObject REST provides full CRUD + describe on ExpressionSetMessageToken; no proprietary Aura controller is involved. Fields available at runtime come from /describe — the SOR doesn't enumerate them statically because the shape depends on the org's permission/profile setup. Run /describe first, then construct the payload from the createable fields list.
-
-## Critical Constraints
-
-**Preconditions:**
-
-- User needs CRUD access to ExpressionSetMessageToken (check: `<udd:crud:ExpressionSetMessageToken>`)
-- BRE (Business Rules Engine) and DES (Decision Explainability Service) features must be enabled at the org level AND for the running user — both gates are required for the setup page to render and for the sObject surface to behave. (check: `Business Rules and Decisioning access && Business Rules and Decisioning access`)
-- User needs access to manage ExpressionSetMessageToken (CRUD on the ExpressionSetMessageToken sObject). (check: `Business Rules and Decisioning access && Business Rules and Decisioning access`)
-
-## Operations Reference
-
-Operations grouped by purpose. Use these as the building blocks for the workflows above.
-
-### Summary
-
-| Operation | Purpose | Status | Call | Depends on |
-|-----------|---------|--------|------|------------|
-| `describe` | read | — | `GET /services/data/v67.0/sobjects/ExpressionSetMessageToken/describe` | — |
-| `list` | read | — | `GET /services/data/v67.0/query` | — |
-| `get-by-id` | read | — | `GET /services/data/v67.0/sobjects/ExpressionSetMessageToken/{Id}` | `list` |
-| `create` | write | — | `POST /services/data/v67.0/sobjects/ExpressionSetMessageToken` | `describe` |
-| `update` | write | — | `PATCH /services/data/v67.0/sobjects/ExpressionSetMessageToken/{Id}` | `get-by-id` |
-| `delete` | write | — | `DELETE /services/data/v67.0/sobjects/ExpressionSetMessageToken/{Id}` | `get-by-id` |
-
-### Dependency graph
-
-```mermaid
-graph TD
-  describe["describe (read)"]
-  list["list (read)"]
-  get_by_id["get-by-id (read)"]
-  create["create (write)"]
-  update["update (write)"]
-  delete["delete (write)"]
-  list --> get_by_id
-  describe --> create
-  get_by_id --> update
-  get_by_id --> delete
-```
-
-### Read operations
-
-#### `describe`
-
-Retrieve the ExpressionSetMessageToken sObject describe — fields, picklist values, FLS, createable/updateable flags.
-
-**Call:** `GET /services/data/v67.0/sobjects/ExpressionSetMessageToken/describe`
-
-**Output:** DescribeSObjectResult for ExpressionSetMessageToken — use this to build the field list for list / create / update payloads.
-
-#### `list`
-
-List ExpressionSetMessageToken records (the DES token-name registry). Pair with /describe first to pick field names. Token names returned here are the values referenced from expression-set step token-mapping payloads.
-
-**Call:** `GET /services/data/v67.0/query`
-
-**Inputs:**
-
-- `where` *(`String`)* — Optional SOQL WHERE clause to filter Expression Set Message Token records.
-- `limit` *(`int`)* — Optional SOQL LIMIT value.
-- `q` *(`string`)*
-
-**Output:** Query response with records[] of ExpressionSetMessageToken — Id plus any SELECTed fields.
-
-#### `get-by-id`
-
-Retrieve a specific ExpressionSetMessageToken record by Id.
-
-**Call:** `GET /services/data/v67.0/sobjects/ExpressionSetMessageToken/{Id}`
-
-**Inputs:**
-
-- `Id` *(`ID`)* — Id of the ExpressionSetMessageToken record to fetch.
-
-**Depends on:** `list`
-
-**Output:** Single ExpressionSetMessageToken record with all readable fields per user FLS.
-
-### Write operations
-
-#### `create`
-
-Create a new ExpressionSetMessageToken record. Run /describe first to learn the required + createable fields.
-
-**Call:** `POST /services/data/v67.0/sobjects/ExpressionSetMessageToken`
-
-**Inputs:**
-
-- `body` *(`object`)* — Field/value map for the new ExpressionSetMessageToken. Populate from /describe's createableFields list.
-
-**Depends on:** `describe`
-
-**Rollback:** Call delete with the returned Id to undo the create.
-
-#### `update`
-
-Update an existing ExpressionSetMessageToken record. Merge-patch semantics.
-
-**Call:** `PATCH /services/data/v67.0/sobjects/ExpressionSetMessageToken/{Id}`
-
-**Inputs:**
-
-- `Id` *(`ID`)* — Id of the ExpressionSetMessageToken to update.
-- `body` *(`object`)* — Partial field/value map — only include fields you want to change.
-
-**Depends on:** `get-by-id`
-
-#### `delete`
-
-Delete a ExpressionSetMessageToken record.
-
-**Call:** `DELETE /services/data/v67.0/sobjects/ExpressionSetMessageToken/{Id}`
-
-**Inputs:**
-
-- `Id` *(`ID`)* — Id of the ExpressionSetMessageToken to delete.
-
-**Depends on:** `get-by-id`

package/skills/industries-field-service-settings-configure/SKILL.md

@@ -1,82 +0,0 @@
----
-name: industries-field-service-settings-configure
-description: "Use this skill when users want to two org-level boolean toggles on Metadata type IndustriesFieldServiceSettings (singleton, fullName='IndustriesFieldServiceSettings'): enableIndustriesFieldService (Asset Service Lifecycle / IFS master, persists to ORG_PREFERENCE_INDUSTRIES_FIELD_SERVICE_ON, gated on the Industrie. Trigger when users mention industries, field, service, settings, industries field service settings."
-metadata:
-  version: "1.0"
-  accessCheck: "(ApiOrgPermissionsBit.apiEnabled) || (IndustriesFieldServiceSettingAccessCheck.ORG_PERMISSION_INDUSTRIES_FIELD_SERVICE) || (OldAccessCheck.USER_HAS_CUSTOMIZE_APPLICATION_OR_SYS_ADMIN)"
----
-
-# Managing Industries Field Service Settings
-
-## When to Use This Skill
-
-Two org-level boolean toggles on Metadata type IndustriesFieldServiceSettings (singleton, fullName='IndustriesFieldServiceSettings'): enableIndustriesFieldService (Asset Service Lifecycle / IFS master, persists to ORG_PREFERENCE_INDUSTRIES_FIELD_SERVICE_ON, gated on the IndustriesFieldService org perm) and enableAutomotiveServiceCampaignManagement (Product Service Campaign Mgmt, persists to ORG_PREFERENCE_PRODUCT_SVC_CAMPAIGN_MGMT_ENABLED, gated on the IndustriesServiceCampaignManagement org perm). Read returns both fields in one record; each write is a single-field updateMetadata. Field-name mismatch with legacy Aura: setProductSvcCampaignPref maps to enableAutomotiveServiceCampaignManagement.
-
-## Workflow
-
-Read via readMetadata on type IndustriesFieldServiceSettings; writes are single-field updateMetadata bodies (wrap <enableIndustriesFieldService>{bool}</enableIndustriesFieldService> or <enableAutomotiveServiceCampaignManagement>{bool}</enableAutomotiveServiceCampaignManagement> in <IndustriesFieldServiceSettings>). Verify re-reads. Two prefs independent; partial body accepted.
-
-## Critical Constraints
-
-**Preconditions:**
-
-- Caller must have Customize Application OR System Administrator user permission. Aura controller checkAccess gates on USER_HAS_CUSTOMIZE_APPLICATION_OR_SYS_ADMIN; Metadata API requires customizeApplication for settings-type writes. (check: `OldAccessCheck.USER_HAS_CUSTOMIZE_APPLICATION_OR_SYS_ADMIN`)
-- Org has IndustriesFieldService org permission enabled (ORG_PERMISSION_INDUSTRIES_FIELD_SERVICE). Required for the IFS-pref read/write path on both surfaces; Metadata API mirrors this via mdApiAccess=Field Service feature on field enableIndustriesFieldService. (check: `IndustriesFieldServiceSettingAccessCheck.ORG_PERMISSION_INDUSTRIES_FIELD_SERVICE`)
-- Org has IndustriesServiceCampaignManagement org permission enabled. Gates the Product Service Campaign toggle on the Metadata API path (mdApiAccess=Service Campaign Management enabled on field enableAutomotiveServiceCampaignManagement). Aura controller bundles this under the IFS perm; Metadata API enforces per-field. (check: `Service Campaign Management enabled`)
-- Org has API access enabled (apiEnabled). Required for any Metadata API call. (check: `ApiOrgPermissionsBit.apiEnabled`)
-
-## Operations Reference
-
-Operations grouped by purpose. Use these as the building blocks for the workflows above.
-
-### Summary
-
-| Operation | Purpose | Status | Call | Depends on |
-|-----------|---------|--------|------|------------|
-| `set-industries-field-service-pref` | write | implemented | `/headless/metadata` | — |
-| `set-product-svc-campaign-pref` | write | implemented | `/headless/metadata` | — |
-
-### Write operations
-
-#### `set-industries-field-service-pref`
-
-updateMetadata on type IndustriesFieldServiceSettings with body <IndustriesFieldServiceSettings><enableIndustriesFieldService>{bool}</enableIndustriesFieldService></IndustriesFieldServiceSettings>. Persists ORG_PREFERENCE_INDUSTRIES_FIELD_SERVICE_ON. Gates Customize Application + IndustriesFieldService org perm.
-
-**Call:** `/headless/metadata`   — status: `implemented`
-
-**Inputs:**
-
-- `enable` *(`boolean`)* — Toggle the enable preference on or off.
-
-**Output:** Metadata API SaveResult — {success: <bool>, fullName: 'IndustriesFieldServiceSettings', errors: [{statusCode, message, fields}...]}. success=true means the org-pref persisted; success=false carries errors[] (e.g. INSUFFICIENT_ACCESS when the IndustriesFieldService org perm is off).
-
-**Notes:** verification_note: Metadata WRITE (updateMetadata) is the canonical customer-facing write surface. Corpus precedent confirms the identical field `enableIndustriesFieldService` is written on the identical singleton via the identical path. Success signal is the SaveResult `success: true` returned inline; a subsequent readback returns 400 UNSUPPORTED_OPERATION on some orgs so it is NOT a reliable secondary check.; wire_contract: Request body MUST target the fully-qualified path `/services/data/v<apiVersion>/headless/metadata` (a bare `/headless/metadata` mis-routes into the reflective-invoke envelope). Body MUST include three top-level string fields: `type` = "IndustriesFieldServiceSettings", `fullName` = "IndustriesFieldServiceSettings" (singleton — the fullName equals the type), and `xmlRep` — an XML string of the form `<?xml version="1.0" encoding="UTF-8"?><IndustriesFieldServiceSettings xmlns="http://soap.sforce.com/2006/04/metadata"><enableIndustriesFieldService>true</enableIndustriesFieldService></IndustriesFieldServiceSettings>`. Do NOT use a `{Metadata: {...}}` shorthand — that shape 400s. Full-record replace semantics apply: agents that need to change only one field should read-merge-write when the READ surface is available.; error_contracts: Observed error shapes on `/services/data/v<apiVersion>/headless/metadata` (2026-09-01):
-(a) Missing any of `type` | `fullName` | `xmlRep` (or `xmlRep=""`): 400 INVALID_INPUT `{errorCode: "INVALID_INPUT", message: "Fields 'type', 'fullName', and 'xmlRep' are required"}`. All three are mandatory; an empty-string xmlRep is treated as missing.
-(b) Well-formed body on an org where the type is not yet mounted: 400 UNSUPPORTED_OPERATION `{errorCode: "UNSUPPORTED_OPERATION", message: "MetadataCrud does not support UPDATE on type: IndustriesFieldServiceSettings"}`. This is an org-rollout condition (see /notes/known_issues/metadata_write_org_rollout_gap), NOT a signal that the substitution is wrong.
-(c) Well-formed body on a properly-entitled org: 200 with SaveResult body `{success: true, fullName: "IndustriesFieldServiceSettings", errors: []}`.
-
-#### `set-product-svc-campaign-pref`
-
-updateMetadata on type IndustriesFieldServiceSettings with body <IndustriesFieldServiceSettings><enableAutomotiveServiceCampaignManagement>{bool}</enableAutomotiveServiceCampaignManagement></IndustriesFieldServiceSettings>. Persists ORG_PREFERENCE_PRODUCT_SVC_CAMPAIGN_MGMT_ENABLED. Gates Customize Application + IndustriesServiceCampaignManagement org perm.
-
-**Call:** `/headless/metadata`   — status: `implemented`
-
-**Inputs:**
-
-- `enable` *(`boolean`)* — Toggle the enable preference on or off.
-
-**Output:** Metadata API SaveResult — {success: <bool>, fullName: 'IndustriesFieldServiceSettings', errors: [{statusCode, message, fields}...]}. success=true means the campaign org-pref persisted; success=false carries errors[].
-
-**Notes:** verification_note: Metadata WRITE (updateMetadata) targets field `enableAutomotiveServiceCampaignManagement` on singleton IndustriesFieldServiceSettings. Note the field name differs from the Aura setter name (`setProductSvcCampaignPref`) — do not derive the Metadata field name from the operation id. Success signal is the SaveResult; the parent org-pref `enableIndustriesFieldService` may need to be true first (feature ordering).; wire_contract: Same wire contract as set-industries-field-service-pref, targeting the sibling field. Fully-qualified path `/services/data/v<apiVersion>/headless/metadata`; body `{type: "IndustriesFieldServiceSettings", fullName: "IndustriesFieldServiceSettings", xmlRep: "<?xml version=\"1.0\" encoding=\"UTF-8\"?><IndustriesFieldServiceSettings xmlns=\"http://soap.sforce.com/2006/04/metadata\"><enableAutomotiveServiceCampaignManagement>true</enableAutomotiveServiceCampaignManagement></IndustriesFieldServiceSettings>"}`. Full-record replace semantics: an agent editing only this field on an org where the sibling `enableIndustriesFieldService` is already true should read-merge-write to preserve the sibling; if the READ is unavailable (see known_issues), the agent SHOULD include both fields in the xmlRep with their intended target state rather than a single-field write.; error_contracts: Identical error surface to set-industries-field-service-pref: (a) missing/empty `type` | `fullName` | `xmlRep` -> 400 INVALID_INPUT with the "Fields 'type', 'fullName', and 'xmlRep' are required" message; (b) well-formed body on a not-yet-mounted org -> 400 UNSUPPORTED_OPERATION UPDATE; (c) well-formed body on an entitled org -> 200 SaveResult. Both writes share the same MetadataCrud handler, so the error taxonomy is identical.
-
-## Notes
-
-- **known_issues:** {'metadata_read_unreliable': 'Metadata READ on IndustriesFieldServiceSettings is org-dependent as of 2026-09-01. Observed 400 UNSUPPORTED_OPERATION on some orgs and 200 with EMPTY xmlRep on others. No Tooling sObject alternative (404). No Organization sObject column. Verification of writes must rely on the SaveResult (success:true) returned by the updateMetadata call itself. Read/verify steps are marked `pending: true` in this SOR until a reliable read surface is available. When a caller reports "write succeeded but the setting is not active", the most likely cause is the `IndustriesFieldServiceAddOn` PSL not being provisioned (or the sibling automotive-service-campaign parent perm for the child pref).', 'metadata_write_org_rollout_gap': 'Direct probe (2026-09-01) returned 400 UNSUPPORTED_OPERATION UPDATE on the well-formed metadata write to type `IndustriesFieldServiceSettings` — both the parent field (`enableIndustriesFieldService`) and the child field (`enableAutomotiveServiceCampaignManagement`) surface the same error. The same UNSUPPORTED_OPERATION UPDATE appears for other Metadata Settings types on an unentitled org, while the identical wire pattern invokes successfully on a properly-entitled org — this is an org-level entitlement/rollout gap for MetadataCrud on Settings types, NOT a substitution error. The served SOR keeps `/headless/metadata` as the canonical write surface because hosted-MCP customers on properly-entitled orgs can invoke it today, and every entitlement expansion widens the served surface at zero SOR-authoring cost. When an agent hits UNSUPPORTED_OPERATION UPDATE from this SOR: report it to the customer as an org-provisioning gap on their target org (contact their Salesforce provisioning team to enable Metadata CRUD for Settings types), NOT as a broken SOR.', 'metadata_delete_pending': 'DELETE on `/headless/metadata` for `IndustriesFieldServiceSettings` returns a dispatch-server `pending_implementation` marker as of 2026-09-01 — the Core Metadata DELETE verb is not yet wired for a REAL delete (an interim no-op that deletes nothing is planned; real delete has no committed ETA). This SOR carries no delete step because `IndustriesFieldServiceSettings` is a Metadata singleton (delete is not a supported customer operation on Settings types anyway — you disable the org-prefs via update, not delete). Documented here for agents that speculatively try DELETE.'}
-- **verification_signal:** For both write steps, the primary verification signal is the SaveResult (`success: true`) returned inline by the updateMetadata call. Do NOT chain a metadata READ as a secondary verify — on this type it returns 400 UNSUPPORTED_OPERATION on some orgs. If a downstream workflow needs to confirm active state, surface the SaveResult back to the caller and instruct them to re-open the Setup page (Setup > Feature Settings > Industries Field Service Settings) to inspect the toggles in the UI.
-- **wire_contract_summary:** Canonical wire pattern for both writes on this SOR:
-Path: `/services/data/v<apiVersion>/headless/metadata` (must be fully-qualified — a bare `/headless/metadata` mis-routes into the reflective-invoke envelope and 400s with "Request body is required").
-Method: PUT (updateMetadata semantics).
-Body: `{"type": "IndustriesFieldServiceSettings", "fullName": "IndustriesFieldServiceSettings", "xmlRep": "<?xml version=\"1.0\" encoding=\"UTF-8\"?><IndustriesFieldServiceSettings xmlns=\"http://soap.sforce.com/2006/04/metadata\"><enableIndustriesFieldService>true</enableIndustriesFieldService></IndustriesFieldServiceSettings>"}`.
-All three body fields (`type`, `fullName`, `xmlRep`) are required; an empty-string `xmlRep` is treated as missing.
-Semantics: full-record replace. To flip only one field, either (a) include both fields in the xmlRep at their intended target state, or (b) read-merge-write when the READ surface is available (see /notes/known_issues/metadata_read_unreliable).
-Success: 200 with body `{"success": true, "fullName": "IndustriesFieldServiceSettings", "errors": []}` — the SaveResult is the authoritative verification signal (see /notes/verification_signal).

package/skills/industries-form-framework-settings-configure/SKILL.md

@@ -1,30 +0,0 @@
----
-name: industries-form-framework-settings-configure
-description: "Use this skill when users want to toggle the FormFramework org preference (Industries Form Framework). Trigger when users mention form, framework, settings, form framework settings."
-metadata:
-  version: "1.0"
----
-
-# Querying Form Framework Settings
-
-## When to Use This Skill
-
-Toggle the FormFramework org preference (Industries Form Framework). Read state via Setup-Connect checkPreference (GET /services/data/v63.0/setup/org/preferences/FormFramework). Enable via updatePreference (PATCH same path, body PreferenceCheckInputRepresentation{desiredState:true}). Both return PreferenceCheckOutputRepresentation{isPreferenceEnabled:boolean}. One-way enable: once enabled, the preference cannot be disabled — API calls attempting to disable it (desiredState=false) will fail with an error. The setup-page UI wraps updatePreference in a confirmation modal; programmatic agents call it directly. Editing requires Customize Application permission.
-
-## 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_1` | read | — | `checkPreference` | — |
-
-### Read operations
-
-#### `isOrgPreferenceEnabled_wire_1`
-
-Fetch the current enabled/disabled state of the "FormFramework" org preference via the isOrgPreferenceEnabled wire adapter. The result drives the toggle's checked state on the settings page.
-
-**Call:** `checkPreference`

package/skills/industries-fsc-ai-settings-configure/SKILL.md

@@ -1,57 +0,0 @@
----
-name: industries-fsc-ai-settings-configure
-description: "Use this skill when users want to toggle Financial Services Cloud AI org preferences. Trigger when users mention fsc, aisettings, fsc aisettings."
-metadata:
-  version: "1.0"
----
-
-# Managing Fsc Ai Settings
-
-## When to Use This Skill
-
-Toggle Financial Services Cloud AI org preferences. Requires Setup admin plus Financial Services AI settings access. Only these four pref keys are valid: dispute_mgmt_generative_ai, wealth_management_ai, b2b_einstein_ai, auto_complaint_summary; any other key is rejected. Each pref exposes a current-state flag and an accessibility flag (from per-feature access checks).
-
-## Critical Constraints
-
-**Preconditions:**
-
-- Caller must be a Setup admin AND have Financial Services AI settings access. Both are enforced; missing either denies the call. (check: `Financial Services AI settings access`)
-- Per-pref accessibility is gated by per-feature access flags: DisputeAI requires dispute-AI-pref access; WealthManagementAI requires wealth-management-AI org access; FSCB2BEinstein requires sales-Einstein org access; AutoComplaintSummary requires both complaint-management access and service-Einstein access. A pref whose gate is off surfaces its accessibility flag as false.
-
-## Operations Reference
-
-Operations grouped by purpose. Use these as the building blocks for the workflows above.
-
-### Summary
-
-| Operation | Purpose | Status | Call | Depends on |
-|-----------|---------|--------|------|------------|
-| `getFSCAISettings_1` | read | implemented | `GET /headless/invoke/industries/industries-dispute-management/fsc-aisettings/get-fscaisettings` | — |
-| `savePreference_2` | write | implemented | `PATCH /headless/invoke/industries/industries-dispute-management/fsc-aisettings/save-preference` | `getFSCAISettings_1` |
-
-### Read operations
-
-#### `getFSCAISettings_1`
-
-Returns 8-key Map<String,Boolean>: 4 `is<X>PrefSettingsAccessible` (DisputeAI / WealthManagementAI / FSCB2BEinstein / AutoComplaintSummary — AutoComplaintSummary needs ComplaintMgmt+ServiceEinstein, others single-perm) and 4 `is<X>PrefEnabled`. AURA-IS-CANONICAL: Tooling/Metadata can't reconstruct multi-perm accessibility.
-
-**Call:** `GET /headless/invoke/industries/industries-dispute-management/fsc-aisettings/get-fscaisettings`   — status: `implemented`
-
-**Output:** Map<String,Boolean> with exactly these 8 keys: isDisputeAIPrefSettingsAccessible, isDisputeMgmtGenerativeAIPrefEnabled, isWealthManagementAIPrefSettingsAccessible, isWealthManagementAIPrefEnabled, isFSCB2BEinsteinPrefSettingsAccessible, isFSCB2BEinsteinPrefEnabled, isAutoComplaintSummaryPrefSettingsAccessible, isAutoComplaintSummaryPrefEnabled.
-
-### Write operations
-
-#### `savePreference_2`
-
-PATCH one preference. `pref` MUST be `dispute_mgmt_generative_ai` | `wealth_management_ai` | `b2b_einstein_ai` | `auto_complaint_summary` (any other key is rejected). `enabled` = target boolean. AURA-IS-CANONICAL: substituting bypasses the server-enforced 4-key allowlist.
-
-**Call:** `PATCH /headless/invoke/industries/industries-dispute-management/fsc-aisettings/save-preference`   — status: `implemented`
-
-**Inputs:**
-
-- `pref` *(`String`)*
-- `enabled` *(`boolean`)*
-
-**Depends on:** `getFSCAISettings_1`
-
-**Rollback:** Re-invoke savePreference_2 with the same `pref` and the inverted `enabled` (or the value captured from a pre-write getFSCAISettings_1 read).