@salesforce/afv-skills 1.65.0 → 1.65.1

package/skills/experience-afv-query/SKILL.md

@@ -1,234 +0,0 @@
----
-name: experience-afv-query
-description: "System-of-record for the public Lightning Instrumentation Headless Connect REST API route that retrieves Agentforce Vibes (AFV) metrics, analytics, data, and adoption/usage insights, including token/LOC, weekly active-user, and per-user activity. Supports local result filtering by period (default current), orgType (default All), recordType, modelName (default All), and other explicitly returned row fields after one parameterless API call."
-metadata:
-  version: "1.0"
----
-
-# Agentforce Vibes metrics
-
-Use this skill when a user asks to retrieve Agentforce Vibes (AFV) usage or
-instrumentation metrics for the current Salesforce org.
-
-This skill describes one public, read-only Connect API operation:
-
-- **Get AFV metrics** — trigger phrases: "get afv metrics", "agentforce vibes metrics", "afv analytics", "fetch agentforce vibes analytics", "headless afv metrics", "afv data", "agentforce vibes data", "get afv adoption usage data", "Vibes adoption", "token/LOC metrics", "weekly active users", "per-user AFV activity", "current or prior AFV metrics", "AFV model metrics", "AFV metrics by org type", and "filter AFV metrics by record type". Primary route: `GET /instrumentation/afv-metrics` (`operationId: getAFVMetrics`).
-
-The route is available at external API version **v68.0 or later**. Use the
-version from `constants.json`; do not infer a lower version from the source
-spec's generic `info.version` or `servers` example. v67.0 returns
-`404 NOT_FOUND`. A version above the org's own maximum also returns `404`;
-that is an org limit, not a reason to call a version below v68.0.
-
-## Workflow
-
-1. Call `GET /services/data/v68.0/instrumentation/afv-metrics`.
-2. Send no path parameters, query parameters, or request body.
-3. Read the returned `AFVMetricsOutputRepresentation`:
-   - `success` — whether the metrics download succeeded.
-   - `message` — an optional status or failure message.
-   - `rows` — an array of metric maps; each map can contain heterogeneous
-     metric names and values.
-4. If `success` is `false`, surface `message` and the raw response. Do not
-   present the rows as a successful metrics result or retry automatically.
-5. If `success` is `true` and `rows` is empty, report the no-data result and
-   stop. Do not retry, treat it as an API error, or fall back to an internal
-   API.
-6. Branch on each row's `recordType` before reading class-specific fields.
-   Do not assume that any particular record class is present. Preserve unknown
-   record types and fields instead of dropping them.
-
-## Optional result filters
-
-Users can narrow the displayed metrics with optional result filters. These
-filters control local processing after the complete response is received; they
-are not Connect API query parameters or `get-afv-metrics` dispatch inputs.
-
-| Filter | Accepted value | Matching rule |
-|---|---|---|
-| `period` | `current` (default) or `prior` | Exact match on `rows[*].period`. Reject another explicit value before calling the API. |
-| `orgType` | `All` (default) or an org-type value returned by the API | Case-insensitive exact match on `rows[*].orgType`. `All` is a literal roll-up value, not a wildcard. |
-| `recordType` | One or more record-type names | Exact match on `rows[*].recordType`. Known values include `aggregate`, `dailyTimeSeries`, `modelMetrics`, `orgBreakdown`, `userMetrics`, and `weeklyActiveUsers`, but accept an exact future value when the user supplies it. |
-| `modelName` | `All` (default) or a model name returned by the API | Case-insensitive exact match on `rows[*].modelName`. `All` is a literal roll-up value, not a wildcard. |
-| Other returned row field | Explicit field name and value supplied by the user | Exact match only when that field is present. Do not invent aliases or assume the field exists on every record type. |
-
-If the user does not supply `period`, apply `period=current`; if the user does
-not supply `orgType`, apply `orgType=All`; if the user does not supply
-`modelName`, apply `modelName=All`. These are default local result filters. An
-explicit value overrides its corresponding default. A request that compares
-the current and prior periods explicitly selects both values and therefore
-overrides the single-period default. Likewise, a request to compare or rank
-models explicitly selects the concrete model names present in the response
-instead of the `All` model roll-up. If the user supplies more than one filter
-name, combine them with AND. If the user supplies multiple values for the same
-field, match any of those values. Each default still applies when the user
-supplies another filter but omits one of these three fields.
-
-Apply filters only after checking HTTP status, `success`, and the unfiltered
-`rows` array:
-
-1. Capture the requested result filters from the user's prompt and add the
-   defaults `period=current`, `orgType=All`, and `modelName=All` when those
-   fields were omitted and the request does not imply a multi-value comparison.
-2. Call `get-afv-metrics` once with no arguments and no query string.
-3. If `success` is `false` or the complete `rows` array is empty, follow the
-   normal response handling without filtering.
-4. Otherwise, filter the returned rows in memory and render the matching rows.
-5. Report the filters applied, the total rows returned by the API, and the
-   number of rows matched.
-
-A successful response with rows but zero filter matches, including when a
-default filter finds no rows, is a successful zero-match view, not an empty
-API response. Report that the complete response
-contained no matching rows. Do not retry, change the request URL, infer zero
-metric values, or report that the API itself returned no data. When the
-requested `recordType` is `userMetrics`, also apply the permission-dependent
-guidance below instead of treating the absence as proof of zero user activity.
-
-## Permission-dependent results
-
-HTTP status is part of the gate and permission contract. Do not treat every
-denial as HTTP `200` with `success: false`.
-
-The route returns a metrics body only when the org gate is enabled and the
-caller passes the user access check. The user access check passes when any
-of these is true:
-
-- the caller has both **Customize Application** and **Modify All Data**, or
-- the caller has **Lifecycle Center Developer-Level Insights**, or
-- the caller has **Lifecycle Center User**.
-
-- **Org gate disabled, or the caller fails the user access check:** the
-  route returns HTTP `403`. Surface the response as an access denial.
-  Recommend verifying that AFV metrics are enabled for the org and that the
-  caller has `Lifecycle Center User`, `Lifecycle Center Developer-Level
-  Insights`, or both Customize Application and Modify All Data. Do not retry,
-  and do not present a `403` as an empty dataset or as `success: false`.
-- **`Lifecycle Center User` only:** the call can return HTTP `200` with
-  `success: true`, but `userMetrics` rows are omitted. The message then
-  includes `Some per-user metrics were omitted because you do not have
-  permission to view them.` Other record classes remain subject to data
-  availability. Absence of `userMetrics` does not prove that no users used
-  AFV.
-- **`Lifecycle Center Developer-Level Insights`, or Customize Application
-  together with Modify All Data:** the caller is eligible to receive rows
-  whose `recordType` is `userMetrics` when that class has data. A populated
-  System Administrator probe returned those rows with message
-  `AFV metrics retrieved successfully.` and no omission sentence.
-
-When the user specifically asks for per-user results and no `userMetrics`
-rows are visible, explain that the class can be absent because
-`Lifecycle Center Developer-Level Insights` is not assigned or because the
-current dataset has no rows of that class. Recommend verifying
-`Lifecycle Center Developer-Level Insights`; do not report zero per-user
-activity from an absent record class.
-
-## Variable record classes
-
-Production exports show that successful populated responses can contain only a
-subset of the known record classes. Treat `aggregate`, `dailyTimeSeries`,
-`modelMetrics`, `orgBreakdown`, `userMetrics`, and `weeklyActiveUsers` as
-independently optional collections. For a requested class that is absent,
-report that the current response contains no rows of that class. Do not infer a
-zero value, fail the whole response, or retry. Row counts are data-dependent.
-
-## Output
-
-On success, report the server message when present, the number of rows, and
-the rows themselves. Preserve the keys returned in each row; the schema
-intentionally permits arbitrary metric-name/value pairs.
-
-```markdown
-## AFV metrics
-
-- Success: `<success>`
-- Message: `<message, when present>`
-- Result filters: `<filters, including period=current, orgType=All, and modelName=All defaults when applicable>`
-- Rows returned by API: `<unfiltered rows.length>`
-- Rows matched: `<filtered rows.length, when filters are present>`
-
-<render the rows without inventing or renaming fields>
-```
-
-For every successful populated response with no user-supplied result filters,
-append a compact filter-discovery block even though the default
-`period=current AND orgType=All AND modelName=All` view was applied. Compute
-distinct values from the full, unfiltered API response and include only fields
-that occur in at least one row. Do not present known-but-absent values as
-available in the current result, and do not make a second API call.
-
-```markdown
-### Available result filters in this response
-
-- `period`: `<distinct rows[*].period values>` (default: `current`)
-- `orgType`: `<distinct rows[*].orgType values>` (default: `All`)
-- `recordType`: `<distinct rows[*].recordType values>`
-- `modelName`: `<distinct rows[*].modelName values>` (default: `All`)
-
-Example: `Get AFV metrics for period=prior, orgType=Sandbox, recordType=modelMetrics, and modelName=<returned model name>.`
-```
-
-When user-supplied filters were provided, show the effective filters in
-`Result filters` and omit the discovery block. The default
-`period=current AND orgType=All AND modelName=All` filters alone do not
-suppress discovery. The filter list and example are part of the same final
-result, not a follow-up question. Available `orgType` and `modelName` values
-are data-dependent; never hardcode values observed in one org.
-
-An empty `rows` array is a valid successful response. The no-data result is
-HTTP `200` with `success: true`, message
-`No AFV metrics are available yet for this org.`, and `rows: []`. Report
-that no metric rows were returned, include the server's message, and stop
-without retrying. Distinguish this from `success: false` with `rows: []`,
-which is a service failure, and from HTTP `403`, which is an access denial.
-
-## Error handling
-
-- `400` — surface the returned AFV result as a bad request.
-- `401` — authentication is missing or invalid; ask the user to reconnect to
-  the org, then retry only when they request it.
-- `403` — the org gate is disabled or the caller fails the user access check.
-  Surface the response and recommend verifying org enablement plus
-  `Lifecycle Center User`, `Lifecycle Center Developer-Level Insights`, or
-  both Customize Application and Modify All Data. Do not retry automatically.
-- `500` — the metrics service failed internally; surface the response and
-  advise retrying later.
-- HTTP `200` with `success: false` — surface `message` and `rows` as returned.
-  The caller-facing service-failure message is
-  `Unable to retrieve AFV metrics at this time. Please try again later.`
-  This is not a permission or gate denial. Do not recommend a permission
-  change for it.
-- HTTP `200` with `success: true` and the per-user omission sentence — follow
-  the permission-dependent guidance. Do not treat the remaining rows as a
-  failure.
-- Route not found at a lower API version — retry at v68.0 or later. v67.0
-  returns `404`. Do not probe a matrix of versions automatically.
-- Rate limiting — the public family enables rate limits. Surface the error and
-  do not auto-retry.
-
-## Constraints
-
-- Read-only and idempotent.
-- Never send result filters to the server: the operation declares
-  `parameters: []`. Apply optional user filters only after the full response is
-  received, including the default
-  `period=current AND orgType=All AND modelName=All` view.
-- Never call the internal Aura-only Lightning Instrumentation Agentforce API;
-  this skill uses the separate public headless Connect API family.
-- Never infer that an absent record class represents zero-valued data. In
-  particular, `userMetrics` can be omitted by permission-based filtering.
-- Do not rely on fixed row counts. Counts observed during validation describe
-  that test dataset, not the API contract.
-- Return one final result. Do not make a follow-up write or verification call.
-
-<!-- skill-validate: ignore-start -->
-<!-- codey:operations start -->
-## Operations Reference
-
-Operations this skill uses — routing and dependency reference.
-
-| Operation | Purpose | Status | Call | Depends on |
-|-----------|---------|--------|------|------------|
-| `get-afv-metrics` | read | — | `GET /services/data/v68.0/instrumentation/afv-metrics` | — |
-<!-- codey:operations end -->
-<!-- skill-validate: ignore-end -->

package/skills/experience-agentforce-vibes-in-react-configure/SKILL.md

@@ -1,63 +0,0 @@
----
-name: experience-agentforce-vibes-in-react-configure
-description: "Use this skill when users want to toggle the Salesforce App Domain org preference so web applications are served from a dedicated salesforce.app domain. Trigger when users mention agentforce, vibes, react, agentforce vibes in react."
-metadata:
-  version: "1.0"
----
-
-# Managing Agentforce Vibes In React
-
-## When to Use This Skill
-
-Toggle the Salesforce App Domain org preference so web applications are served
-from a dedicated salesforce.app domain. This setup page has a single toggle for
-the SalesforceAppDomain preference (enable or disable via the Setup Connect API).
-The toggle is only visible when the com.salesforce.lwr.salesforceAppDomain gate
-is active for the org — if it is not present, the feature is not yet available.
-
-## Critical Constraints
-
-**Preconditions:**
-
-- The com.salesforce.lwr.salesforceAppDomain gate must be active for the org.
-Without this gate, the SalesforceAppDomain toggle will not appear on the
-Setup page and the preference cannot be set. Verify gate status via
-GET /headless/invoke/platform/webapp/is-salesforce-app-domain-gate-enabled
-before attempting to enable.
-
-## 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_3` | read | — | `GET /services/data/v67.0/setup/org/preferences/SalesforceAppDomain` | — |
-| `setOrgPreferences_1` | write | — | `PATCH /services/data/v67.0/setup/org/preferences/SalesforceAppDomain` | `isOrgPreferenceEnabled_wire_3` |
-
-### Read operations
-
-#### `isOrgPreferenceEnabled_wire_3`
-
-Read the current state of the SalesforceAppDomain org preference via the
-Setup Connect API. Returns {isPreferenceEnabled: boolean}. If the endpoint
-returns 404 'The requested resource does not exist', the preference resource
-is not mounted on this org build. If it returns 404 'Invalid named
-preference', the preference name is not registered on IOrgPreferencesResource
-for this org/version.
-
-**Call:** `GET /services/data/v67.0/setup/org/preferences/SalesforceAppDomain`
-
-### Write operations
-
-#### `setOrgPreferences_1`
-
-Enable the SalesforceAppDomain org preference via the Setup Connect API.
-PATCH the preference resource with body {desiredState: true}. The response
-echoes the persisted state as {isPreferenceEnabled: boolean}. A 403 means the
-running user lacks permission to modify the preference.
-
-**Call:** `PATCH /services/data/v67.0/setup/org/preferences/SalesforceAppDomain`
-
-**Depends on:** `isOrgPreferenceEnabled_wire_3`

package/skills/experience-apex-components-configure/SKILL.md

@@ -1,69 +0,0 @@
----
-name: experience-apex-components-configure
-description: "Use this skill when users want to manage ApexComponent records (Visualforce custom components) via the Tooling sObject API. Trigger when users mention apex, components, apex components."
-metadata:
-  version: "1.0"
----
-
-# Managing Apex Components
-
-## When to Use This Skill
-
-Manage ApexComponent records (Visualforce custom components) via the Tooling sObject API. Steps cover SOQL list, GET-by-Id, and POST-create against /services/data/v66.0/tooling/sobjects/ApexComponent. Body fields (Name, MasterLabel, ApiVersion, NamespacePrefix, Markup, ControllerType, ControllerKey, Description, IsExplicitImport) match the ApexComponent UDD entity; field set varies by org (managed-package fields), so call /tooling/sobjects/ApexComponent/describe before constructing create payloads. Read requires View Setup + canViewApexPagesSetup; write requires CustomizeApplication. Org must have orgHasApexPagesApi enabled (Visualforce feature gate). No Connect/Metadata/Aura alternative — Metadata API ApexComponent is deploy/retrieve XML, wrong granularity for runtime CRUD.
-
-## Critical Constraints
-
-**Destructive operations — require explicit user confirmation:**
-
-- **`delete_ApexComponent_1`** — Delete a ApexComponent record by Id via the Tooling/sObject API. The {id} path parameter is the record Id.
-  - 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 |
-|-----------|---------|--------|------|------------|
-| `list_ApexComponent_1` | read | — | `query.ApexComponent` | — |
-| `get_ApexComponent_1` | read | — | `sobjects/ApexComponent/{id}` | — |
-| `create_ApexComponent_1` | write | — | `sobjects/ApexComponent` | — |
-| `update_ApexComponent_1` | write | — | `sobjects/ApexComponent/{id}` | — |
-| `delete_ApexComponent_1` | delete | — | `sobjects/ApexComponent/{id}` | — |
-
-### Read operations
-
-#### `list_ApexComponent_1`
-
-SOQL list of ApexComponent records via Tooling API (GET /services/data/v66.0/tooling/query?q=...). The {q} input is the agent-supplied SOQL string — typically `SELECT Id, Name, MasterLabel, ApiVersion FROM ApexComponent`. View Setup + canViewApexPagesSetup gated.
-
-**Call:** `query.ApexComponent`
-
-#### `get_ApexComponent_1`
-
-Fetch a single ApexComponent record by Id via Tooling sObject GET (/services/data/v66.0/tooling/sobjects/ApexComponent/{id}). Returns the full record including Markup. View Setup + canViewApexPagesSetup gated. Common pairing: list_ApexComponent_1 to find the Id, then this step to retrieve the body.
-
-**Call:** `sobjects/ApexComponent/{id}`
-
-### Write operations
-
-#### `create_ApexComponent_1`
-
-Create a new ApexComponent record via Tooling sObject POST (/services/data/v66.0/tooling/sobjects/ApexComponent). Body must include Name (DeveloperName) + MasterLabel + ApiVersion + Markup; optional Description, ControllerType, ControllerKey, IsExplicitImport, NamespacePrefix. CustomizeApplication gated. Returns the new Id; verify by GET on the returned Id.
-
-**Call:** `sobjects/ApexComponent`
-
-#### `update_ApexComponent_1`
-
-Update a ApexComponent record by Id via the Tooling/sObject API. The {id} path parameter is the record Id; body fields replace existing values.
-
-**Call:** `sobjects/ApexComponent/{id}`
-
-### Destructive operations
-
-#### `delete_ApexComponent_1`
-
-Delete a ApexComponent record by Id via the Tooling/sObject API. The {id} path parameter is the record Id.
-
-**Call:** `sobjects/ApexComponent/{id}`

package/skills/experience-apex-pages-configure/SKILL.md

@@ -1,107 +0,0 @@
----
-name: experience-apex-pages-configure
-description: "Use this skill when users want to manage Visualforce Apex Pages (key prefix `066`) via the Tooling sObject API. Trigger when users mention apex, pages, apex pages."
-metadata:
-  version: "1.0"
-  accessCheck: "UserPermissions.ViewSetup"
----
-
-# Managing Apex Pages
-
-## When to Use This Skill
-
-Manage Visualforce Apex Pages (key prefix `066`) via the Tooling sObject API. UDD
-`sobjectFamily="TOOLING"` blocks standard sObject CRUD; Metadata API CRUD is
-documented-broken on FullName (BI-EDS udd/216/ApexPage.entity.xml line 22). Tooling
-sObject is the only working programmatic surface.
-
-- List: `GET /services/data/v66.0/tooling/query?q=SELECT ... FROM ApexPage` —
-  filterable on Name, MasterLabel, NamespacePrefix, ApiVersion, ControllerType.
-- Read one: `GET /services/data/v66.0/tooling/sobjects/ApexPage/{id}` — returns
-  full record incl. Markup, Metadata (ApexPageDescriptor), NamespacePrefix.
-- Create: `POST /services/data/v66.0/tooling/sobjects/ApexPage` with required
-  body `{Name, MasterLabel, ApiVersion, Markup}`.
-
-Required-on-create: `Name` (DeveloperName, ≤80), `MasterLabel` (≤80), `ApiVersion`
-(DOUBLE, scale=1), `Markup` (CLOB, ≤1,048,576 chars). `ControllerType` is the
-`ApexPageControllerType` enum (Standard | Custom | Extension) — first-class on
-create when binding the page to a controller. Update (PATCH) and delete
-(DELETE) on `/sobjects/ApexPage/{id}` exist in the Tooling REST contract but
-are dropped from this SOR by the producer-merge layer; see `notes.coverage_gap`.
-
-## Workflow
-
-Workflow: list_ApexPage_1 (SOQL filter to find a page by Name / MasterLabel /
-ControllerType) → get_ApexPage_1 by Id (returns full Markup + Metadata) →
-create_ApexPage_1 with required `{Name, MasterLabel, ApiVersion, Markup}`.
-Read steps are independent — call get_ApexPage_1 directly when the Id is
-already known.
-
-## Critical Constraints
-
-**Preconditions:**
-
-- Org must have Apex Pages enabled (`Apex Pages enabled` feature gate). Without this org-level setting the Tooling REST surface returns no rows / refuses writes regardless of user permissions. (check: `Apex Pages enabled`)
-- Read access requires `OrgPermissions.AuthorApexPages` plus `UserPermissions.ViewSetup` (the Tooling per-API-access tuple on the ApexPage entity). (check: `UserPermissions.ViewSetup`)
-- Create / update / delete requires `Customize Application permission` (entity `editAccess` on ApexPage). (check: `Customize Application permission`)
-
-**Destructive operations — require explicit user confirmation:**
-
-- **`delete_ApexPage_1`** — Delete a ApexPage record by Id via the Tooling/sObject API. The {id} path parameter is the record Id.
-  - 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 |
-|-----------|---------|--------|------|------------|
-| `list_ApexPage_1` | read | — | `query.ApexPage` | — |
-| `get_ApexPage_1` | read | — | `sobjects/ApexPage/{id}` | — |
-| `create_ApexPage_1` | write | — | `sobjects/ApexPage` | — |
-| `update_ApexPage_1` | write | — | `sobjects/ApexPage/{id}` | — |
-| `delete_ApexPage_1` | delete | — | `sobjects/ApexPage/{id}` | — |
-
-### Read operations
-
-#### `list_ApexPage_1`
-
-SOQL over ApexPage via Tooling. Filter on Name (DeveloperName), MasterLabel, NamespacePrefix, ApiVersion, ControllerType. Markup is large (≤1MB) — project explicitly when needed. Paginate via nextRecordsUrl when totalSize > 2000.
-
-**Call:** `query.ApexPage`
-
-**Output:** Tooling QueryResult: {totalSize: int, done: bool, nextRecordsUrl: string|null, records: [{Id (066…), Name, MasterLabel, ApiVersion, ControllerType, NamespacePrefix, ManageableState, CreatedDate, LastModifiedDate, ...projected}]}. done=false → call nextRecordsUrl to continue paging.
-
-#### `get_ApexPage_1`
-
-Get one ApexPage by Id (key prefix 066). Returns the full record including Markup (≤1MB CLOB), MasterLabel, ApiVersion (DOUBLE), ControllerType (`ApexPageControllerType` enum: Standard | Custom | Extension), Metadata (ApexPageDescriptor), NamespacePrefix. 404 NOT_FOUND when the Id is unknown.
-
-**Call:** `sobjects/ApexPage/{id}`
-
-**Output:** Full ApexPage record: {Id (066…), Name (DeveloperName, ≤80), MasterLabel (≤80), ApiVersion (DOUBLE), Markup (CLOB ≤1,048,576 chars), ControllerType (ApexPageControllerType enum: Standard|Custom|Extension), ControllerKey, NamespacePrefix, ManageableState, IsAvailableInTouch (bool), CreatedDate, LastModifiedDate, SystemModstamp, Metadata (ApexPageDescriptor — Tooling-only), FullName (Tooling-only)}.
-
-### Write operations
-
-#### `create_ApexPage_1`
-
-POST a new ApexPage. Required body fields: `Name` (DeveloperName, ≤80), `MasterLabel` (≤80), `ApiVersion` (DOUBLE), `Markup` (CLOB ≤1,048,576). Optional: `ControllerType` (ApexPageControllerType enum), `ControllerKey`, `Description`. Returns Tooling SaveResult `{id, success, errors[]}` plus a Location header pointing at `/sobjects/ApexPage/{id}`.
-
-**Call:** `sobjects/ApexPage`
-
-**Output:** Tooling SaveResult: {id: string (066…, the new ApexPage Id), success: bool, errors: [{statusCode, message, fields[]}]}. On success the response Location header carries `/services/data/v66.0/tooling/sobjects/ApexPage/{id}`. On REQUIRED_FIELD_MISSING / DUPLICATE_DEVELOPER_NAME / INVALID_FIELD, errors[] is populated and success=false.
-
-#### `update_ApexPage_1`
-
-Update a ApexPage record by Id via the Tooling/sObject API. The {id} path parameter is the record Id; body fields replace existing values.
-
-**Call:** `sobjects/ApexPage/{id}`
-
-### Destructive operations
-
-#### `delete_ApexPage_1`
-
-Delete a ApexPage record by Id via the Tooling/sObject API. The {id} path parameter is the record Id.
-
-**Call:** `sobjects/ApexPage/{id}`

package/skills/experience-app-home-configure/SKILL.md

@@ -1,76 +0,0 @@
----
-name: experience-app-home-configure
-description: "Use this skill when users want to app Manager Setup page. Trigger when users mention app, home, app home."
-metadata:
-  version: "1.0"
----
-
-# Managing App Home
-
-## When to Use This Skill
-
-App Manager Setup page. Three operations against CustomApplication Tooling records: list the App Manager picker categories (TabSetType API name to display label), delete a CustomApplication (logs an AppManagerListView audit record; returns null when caller lacks Customize Application), and upgrade a Classic CustomApplication to Lightning (clones plus optionally copies per-profile ProfileActionOverride rows). All steps AURA-IS-CANONICAL: no public Connect, Tooling, or Metadata equivalent reproduces the audit side-effect, permission-aware return, or the composite clone-plus-profile-copy.
-
-## Workflow
-
-Three independent steps; no required ordering. get-list-views returns picker labels (no caller input). delete-app and upgrade-app each take a CustomApplication id sourced externally (Tooling SOQL on CustomApplication, or the page's loaded row set). All require Customize Application user permission.
-
-## Critical Constraints
-
-**Destructive operations — require explicit user confirmation:**
-
-- **`delete-app`** — Delete the CustomApplication identified by id. Logs an AppManagerListView audit record on success; returns null instead of the id when caller lacks Customize Application. AURA-IS-CANONICAL: raw Tooling DELETE loses the audit side-effect and the permission-aware null return.
-  - 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-list-views` | read | implemented | `GET /headless/invoke/platform/app-home` | — |
-| `delete-app` | delete | implemented | `DELETE /headless/invoke/platform/app-home/delete-app` | — |
-| `upgrade-app` | write | implemented | `PATCH /headless/invoke/platform/app-home/upgrade-app` | — |
-
-### Read operations
-
-#### `get-list-views`
-
-Return the App Manager list-view picker as a map of TabSetType API name to display label (e.g. AllApps, Classic, Lightning) that scopes which CustomApplication rows the page renders.
-
-**Call:** `GET /headless/invoke/platform/app-home`   — status: `implemented`
-
-**Notes:** adoption_note: Approved for agent serving. Returns the App Manager list-view picker as a map of TabSetType API name to display label (no caller input, no side effects), and carries a correct, unmasked permission gate that rejects unauthorized callers outright. The endpoint contract is sound and functional; approved for serving so it lands in the routes-jar regen.
-
-### Write operations
-
-#### `upgrade-app`
-
-Clone the source Classic CustomApplication (id) to a new Lightning CustomApplication with the supplied label/developerName; asserts source UiType is not already Lightning. When preserveProfileSetting=true, copies per-profile ProfileActionOverride entries. AURA-IS-CANONICAL: composite clone-plus-profile-copy has no public equivalent.
-
-**Call:** `PATCH /headless/invoke/platform/app-home/upgrade-app`   — status: `implemented`
-
-**Inputs:**
-
-- `id` *(`String`)* — Value for the id field.
-- `label` *(`String`)* — Value for the label field.
-- `developerName` *(`String`)* — Name of the developer.
-- `preserveProfileSetting` *(`boolean`)* — Toggle the preserve profile setting preference on or off.
-
-**Notes:** reject_on_attestation: Two-sided mutation: creates a new app cloned from the source app's metadata AND mutates the old app in place, plus copies permission-set assignments to the new app. Its only guard against a malformed invocation is not reliably enforced at runtime, so it cannot be relied on to reject one. Permission-gated but never live-validated for this node, with no natural way to read back and confirm the result afterward. Identical implementation independently gated to reject_on_attestation for the sibling NavigationMenus node on the same grounds. Too high-blast-radius and hard-to-reverse for autonomous invocation without human attestation.; masking_bug_pointer: Same pattern as delete-app: on any failure — a permission denial or any other error — this step returns a generic, uninformative error rather than one identifying the real problem. A headless caller cannot distinguish "access denied" from "clone failed" from any other failure via the error message alone.
-
-### Destructive operations
-
-#### `delete-app`
-
-Delete the CustomApplication identified by id. Logs an AppManagerListView audit record on success; returns null instead of the id when caller lacks Customize Application. AURA-IS-CANONICAL: raw Tooling DELETE loses the audit side-effect and the permission-aware null return.
-
-**Call:** `DELETE /headless/invoke/platform/app-home/delete-app`   — status: `implemented`
-
-**Inputs:**
-
-- `id` *(`String`)*
-
-**Notes:** reject_on_attestation: Irreversible delete that also removes the app's per-profile visibility and its utility-bar and icon configuration, with no natural way to read back and confirm the result afterward. Permission-gated, but never live-validated for this node. Identical implementation independently gated to reject_on_attestation for the sibling NavigationMenus node on the same grounds. Do not auto-invoke; require explicit human attestation per invocation pending live E2E confirmation.; masking_bug_pointer: On any failure — including a permission denial — this step returns a generic, uninformative error rather than one identifying the real problem, so a caller cannot tell an access-denial apart from any other failure. The served description's claim that this step "returns null" on a permission failure is also inaccurate: null is returned only when the target app record is not found, never on permission denial.

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

@@ -1,58 +0,0 @@
----
-name: experience-aura-lightning-out-access-configure
-description: "Use this skill when users want to manage the AuraLightningOutAccess org preference, which gates whether Aura components can be served through Lightning Out (the cross-org embed surface for Aura). Trigger when users mention aura, lightning, out, access, aura lightning out access."
-metadata:
-  version: "1.0"
-  accessCheck: "OrgPermissions.AuraLightningOutPermission"
----
-
-# Managing Aura Lightning Out Access
-
-## When to Use This Skill
-
-Manage the AuraLightningOutAccess org preference, which gates whether Aura components can be served through Lightning Out (the cross-org embed surface for Aura). Two operations: read the current boolean state, then flip it on/off. The PATCH response echoes the new state, so the caller does not need a follow-up read to confirm persistence. Caller must hold the AuraLightningOutPermission org permission (UDD access check Lightning Out settings access).
-
-## Workflow
-
-Org-wide preference gating whether Aura components can be served through Lightning Out (the cross-org Aura embed surface). Canonical flow: read the current boolean via the GET step, then PATCH the desired value; the write response echoes the post-update isPreferenceEnabled, so no follow-up read is needed. Writes require the AuraLightningOutPermission org permission — without it the PATCH returns 401 INSUFFICIENT_ACCESS "Cannot update preference value!" (distinct from an OAuth/token failure, which differs by errorCode). Reads are ungated. Send desiredState as the boolean; an empty body returns 400 "Invalid desiredState passed!".
-
-## Critical Constraints
-
-**Preconditions:**
-
-- Caller must hold the AuraLightningOutPermission org permission; the setup page's UDD access check userCanAccessAuraLightningOutSettings gates read/write of this preference. (check: `OrgPermissions.AuraLightningOutPermission`)
-
-## Operations Reference
-
-Operations grouped by purpose. Use these as the building blocks for the workflows above.
-
-### Summary
-
-| Operation | Purpose | Status | Call | Depends on |
-|-----------|---------|--------|------|------------|
-| `isOrgPreferenceEnabled_wire_2` | read | — | `checkPreference` | — |
-| `setOrgPreferences_1` | write | — | `updatePreference` | `isOrgPreferenceEnabled_wire_2` |
-
-### Read operations
-
-#### `isOrgPreferenceEnabled_wire_2`
-
-Read whether the AuraLightningOutAccess org preference is currently enabled. Response field isPreferenceEnabled is the boolean.
-
-**Call:** `checkPreference`
-
-**Output:** PreferenceCheckOutputRepresentation with one field: isPreferenceEnabled (boolean) — true when AuraLightningOutAccess is currently enabled for the org, false otherwise.
-
-### Write operations
-
-#### `setOrgPreferences_1`
-
-Set the AuraLightningOutAccess org preference to the new boolean value. Response echoes the post-update isPreferenceEnabled, confirming persistence without an extra read.
-
-**Call:** `updatePreference`
-
-**Depends on:** `isOrgPreferenceEnabled_wire_2`
-
-**Output:** PreferenceCheckOutputRepresentation echoing the new state: isPreferenceEnabled (boolean) is the value of AuraLightningOutAccess after the update — equals desiredState on success.
-
-**Notes:** error_contracts: [{'status': 400, 'errorCode': 'BAD_REQUEST', 'message_pattern': 'Invalid desiredState passed!', 'when': 'Request body is empty or omits the desiredState field.', 'body_shape': '[{"errorCode":"BAD_REQUEST","message":"Invalid desiredState passed!"}]'}, {'status': 401, 'errorCode': 'INSUFFICIENT_ACCESS', 'message_pattern': 'Cannot update preference value!', 'when': 'Caller lacks the AuraLightningOutPermission org permission. Distinguish from an OAuth-token failure by the errorCode + message combination (a bad token would return AUTH_ERROR or 401 with a different message).', 'body_shape': '[{"errorCode":"INSUFFICIENT_ACCESS","message":"Cannot update preference value!"}]'}, {'status': 405, 'errorCode': 'METHOD_NOT_ALLOWED', 'when': 'A verb other than GET, HEAD, or PATCH is used against this path.', 'body_shape': '[{"errorCode":"METHOD_NOT_ALLOWED","message":"HTTP Method ... not allowed. Allowed are GET,HEAD,PATCH"}]'}]