@salesforce/afv-skills 1.65.0 → 1.66.0

package/skills/dx-devops-work-item-manage/references/commit-api.md

@@ -0,0 +1,116 @@
+# Commit through the DevOps Center API
+
+Request, response and polling were verified live (dev org + Core hub, work item `WI-000001`, status In Progress). Error codes, no-access preflight behaviour and git-path sync behaviour come from source, not live tests. Use this when the user supplies a dev org alias and the changes are already deployed in that org.
+
+## Contents
+
+- Orgs involved
+- Preflight
+- Request
+- Response and errors
+- Polling
+- Confirming on the hub
+- Differences from the git path
+- Known limits
+
+## Orgs involved
+
+| Org | Role | Used for |
+|-----|------|----------|
+| Dev org | Holds the metadata; where DX Inspector runs | `doceConnectionType`, `commitChanges`, `DevopsRequestInfo` polling |
+| Hub org | Holds projects, work items, component lists | `sf devops work-item list`, status checks, confirming the commit |
+
+The dev org reaches the hub server-side through the `ALMDevOpsCenterHub` named credential. The CLI cannot use that credential, so the hub needs its own `sf` login (`--target-org <hub-alias>`).
+
+## Preflight
+
+```bash
+sf api request rest "/services/data/v67.0/connect/devops/doceConnectionType" --target-org <dev-org>
+```
+
+The commit API is used at `v67.0`; the commands are not tied to the skill's `minApiVersion`. Treat a non-zero exit or an error body as failure for every `sf api request rest` call here (the no-access case was not tested live).
+
+- 2xx with `{"isCore": true, "isManagedPackage": false}` — Core hub; proceed. This call itself goes through the hub named credential, so success is evidence the credential works.
+- A failed call (no DX Inspector access, endpoint missing) — fall back to the git path.
+- `isCore` not `true`, or `isManagedPackage: true` — this reference covers the Core path only; use the git path.
+- Optional: `sf data query --target-org <dev-org> -q "SELECT DeveloperName FROM NamedCredential WHERE DeveloperName = 'ALMDevOpsCenterHub'"`.
+
+## Request
+
+`POST /services/data/v67.0/connect/devops/commitChanges` on the **dev org**. The REST body is the input object itself. Wrapping it in `{"commitChanges": {...}}` fails with `JSON_PARSER_ERROR: Unrecognized field "commitChanges"`.
+
+```json
+{
+  "isCommitCore": "true",
+  "workItemId": "<hub work item id>",
+  "projectId": "<hub project id>",
+  "workItemName": "WI-000001",
+  "workItemLink": "<url of the work item in the hub>",
+  "commitMessage": "<message>",
+  "changes": [
+    {"fullName": "MyClass", "type": "ApexClass", "operation": "modify"}
+  ]
+}
+```
+
+- `isCommitCore` is the **string** `"true"`. The Core path needs it together with a non-empty `workItemId`.
+- `operation` is `add`, `modify` or `delete`.
+- Rebuild the request body for **every** commit. Write it to a temp file (`mktemp`) and delete it afterwards, so a later `git add` cannot pick it up.
+- Do not send `dataChanges` or `vcsRepo` (data deployment and the Managed Package path are out of scope).
+
+```bash
+BODY=$(mktemp)   # write the JSON above to "$BODY"; rm "$BODY" when done
+sf api request rest "/services/data/v67.0/connect/devops/commitChanges" \
+  --method POST --body @"$BODY" --target-org <dev-org>
+```
+
+Pass the file with the `@` prefix (`--body @<file>`); without it the CLI treats the path as the literal body.
+
+## Response and errors
+
+Success: `{"reqId": "<uuid>", "status": "SUCCESS"}` — this means the request was accepted, not that the commit finished.
+
+Request-level failures (e.g. `JSON_PARSER_ERROR` from a malformed body) come back as real HTTP errors: surface them and stop. Business failures are returned as HTTP 200 with `status: "ERROR"` and `reqId` holding `CODE:message`. Codes seen in source: `WORKITEM_NEVERED`, `VCS_NOT_AUTHENTICATED`, `COMMIT_API_FAILURE_CORE`, `COMMIT_API_FAILURE_CLIAAS`, `COMMIT_PAYLOAD_ERROR_*`, `COMMIT_DATA_VALIDATION_ERROR`, `COMMIT_FAILED`. Always check `status`, not the exit code alone.
+
+Server-side preconditions: work item not closed (`WORKITEM_NEVERED`); status New, In Progress, In Review or Ready to Promote; the VCS connection is authenticated.
+
+## Polling
+
+There is no status resource. Query the dev org:
+
+```bash
+sf data query --target-org <dev-org> --json \
+  -q "SELECT Status, Message, ErrorDetails, RequestCompletionDate FROM DevopsRequestInfo WHERE RequestToken = '<reqId>'"
+```
+
+- Terminal `Status` values: `SUCCESS` (not `COMPLETED`) and `ERROR`. A loop that waits for `COMPLETED` never exits.
+- The commit observed took about 10 seconds. Poll every 10 seconds, deadline 12 minutes.
+- `IN_PROGRESS` comes first; `RequestToken` equals the POST `reqId`.
+- At the deadline the request is stuck (worker timeout is 10 minutes and the status can stay in progress). Report it and do not retry automatically; a retry is a new request that could race the stuck one.
+- `Message`/`ErrorDetails` carry the failure text when `Status` is `ERROR`.
+
+## Confirming on the hub
+
+```bash
+sf data query --target-org <hub-org> --json \
+  -q "SELECT Name, CommitReference, CreatedDate FROM WorkItemComponentList WHERE WorkItemId = '<id>' ORDER BY CreatedDate"
+```
+
+A new row with a `CommitReference` hash confirms the commit was recorded. A new row with a null `CommitReference` (seen with unchanged components) means the request succeeded but nothing new was committed; report "nothing to commit", not a successful commit. An In Progress work item stays In Progress; a New one is expected to move to In Progress (not tested live).
+
+## Differences from the git path
+
+| | Git path | API path |
+|---|---|---|
+| Committed content | Files on local disk | Components named in `changes`, retrieved from the dev org |
+| Orgs | Hub only | Dev org for the commit, hub for lookup and confirmation |
+| Author | The user's git identity | `DevOps Center <noreply@salesforce.com>` |
+| Branch | Work item `branch` field | The work item name (`WI-000001`); the live test could not distinguish this from `branch` |
+| Hub records | Created when the hub's external-commit sync picks the push up (only for In Progress, In Review, Ready to Promote) | Created immediately |
+| Result tracking | git exit codes | `reqId` plus `DevopsRequestInfo` |
+
+## Known limits
+
+- No rebase before push: a concurrent push to the same branch can make the commit fail as non-fast-forward.
+- An empty change set can finish `SUCCESS` with nothing committed.
+- A failed attempt can leave an orphaned component list on the hub.

package/skills/experience-lwc-widget-assess/SKILL.md

@@ -0,0 +1,79 @@
+---
+name: experience-lwc-widget-assess
+description: "Assess whether a specific Lightning web component can serve its user's purpose as an HXL declarative widget. Use for LWC-to-widget feasibility, portability audits, and candidate screening; use experience-lwc-widget-migrate when the user wants the widget built."
+metadata:
+  version: "1.0"
+  domains: ["Experience", "Platform", "Agentforce"]
+  minApiVersion: "68.0"
+  relatedSkills:
+    - "experience-lwc-widget-migrate"
+    - "platform-widget-generate"
+---
+
+# Assess LWC to widget fit
+
+Answer two questions for each LWC: **Can the current behavior be represented?** If not, **would a feasible widget still accomplish the user's goal?** Assess only; do not create metadata. A widget is its own declarative artifact, distinct from a Lightning Type. Its body renders supplied data with discovered tiles, bindings, formulas, and supported actions. It cannot run arbitrary LWC code, fetch after render, or retain reactive client state.
+
+## Evidence and decision
+
+1. Read the component's JS/TS, template, metadata, and relevant child components. State the user's goal in one sentence. Trace each visible value to its source and identify interactions essential to that goal. An `@api` property proves external input, **not** that an invocable action returns it. A user's explicit statement about action output is evidence for a feasibility assessment; verify the actual action contract and Lightning Type/renderer wiring before claiming a working migration.
+2. Map the **job** of each rendered element and action to the target surface. `platform-widget-generate` explains the discovery procedure; the actual `discoverUiComponents` response and `getUiComponentSchemas` results establish available blocks and attributes. Read its `references/widget-formulas.md` only when a transformation matters. Record the target channel from evidence rather than assuming a fixed channel or tile count. Without discovery, a documented pattern can support a **provisional candidate**, but absence from examples does not prove a block is unavailable. Use `review` when that uncertainty determines the verdict; never invent a tile, action, input submission mechanism, or formula.
+3. Check all dimensions, even after a failure: rendering vocabulary; retained state, imperative effects, and actions; data origin; and transformations. A bounded snapshot or pre-shaped collection can sometimes move into the invocable action's output. Inspect the action implementation before asserting that it can. A formula's scalar `MIN`/`MAX`, date, or regex support does not imply collection sorting or aggregation. Input forms require evidence that the current tiles can collect values **and** pass those values to an action; `sendMessage` alone does not prove that.
+4. Judge the current LWC and a proposed widget separately. A link or `sendMessage` may preserve an intent without preserving the original interaction, if the agent can actually perform the requested work with the required context. A carousel may become a product list; an order builder whose purpose is choosing quantities may not. Treat that change as a rebuild. For the widget candidate, consider a **specified proposed IA contract** when setting `rendersAsWidget`; state the contract change explicitly. If feasibility or purpose remains unresolved, use `review`, not a forced yes/no verdict.
+
+Use these outcomes:
+
+| Outcome | Meaning |
+|---|---|
+| `asIsVerdict: port-declarative` | Current visible behavior and data contract can be represented. |
+| `asIsVerdict: needs-IA-contract-change` | Only a bounded output or pre-shaping change is needed. |
+| `asIsVerdict: not-portable` | Some current behavior or visual has no verified equivalent. |
+| `asIsVerdict: review` | Evidence cannot establish the current fit. |
+| `asDisplayWidget.verdict: viable` | A verified or clearly identified candidate serves the goal, possibly after a stated contract change or rebuild. |
+| `asDisplayWidget.verdict: pointless` | It can render but loses the user's goal. |
+| `asDisplayWidget.verdict: blocked` | The proposed display/action cannot be represented. |
+| `asDisplayWidget.verdict: review` | Capability, data provenance, or purpose is unresolved. |
+
+List **every material blocker** in the report with its gate and evidence, citing a source location or concrete behavior. Gate names are `role`, `rendering vocabulary`, `behavior/interactivity`, `data source`, and `transformation`. Do not stop at the first failed dimension. `contractChange.shapeToAdd` names only fields or pre-shaped values the action could plausibly return; never invent a payload. A viable adaptation may need a contract change even when the current LWC is `not-portable`. If a proposed widget changes the UX, set `isRebuild: true` and name the lost interaction in the report. Mark uncertain conclusions low confidence and explain what would resolve them.
+
+## Output
+
+Produce two artifacts. When an output location is given, write them as `verdict.json` and `report.md`.
+
+**Verdict** — the machine-readable decision that `experience-lwc-widget-migrate` gates on. One JSON object per component; for a folder, an array. Keep exactly these fields:
+
+```json
+{
+  "component": "caseDetailsPanel",
+  "role": "renderer",
+  "asIsVerdict": "port-declarative",
+  "contractChange": {"suggested": false, "shapeToAdd": []},
+  "asDisplayWidget": {"verdict": "viable", "rendersAsWidget": true, "stillServesPurpose": true, "isRebuild": false},
+  "needsHumanReview": false
+}
+```
+
+`role` is `renderer`, `input`, or `interactive`. `stillServesPurpose` is boolean or `"unknown"`; `rendersAsWidget` is boolean or `null` when capability is unresolved. For `viable`, both are true. For `pointless`, rendering is true and purpose false. For `blocked`, rendering is false and purpose is `"unknown"`. For `review`, keep unresolved fields unknown/null. Set `needsHumanReview: true` for either `review` verdict or unknown purpose. Suggest a contract change only when a value the widget displays is **not** already in the action's output (for example, it is fetched after render). Data already in the payload needs no contract change, even when the LWC is `not-portable` or the widget is a rebuild. Any suggested contract change needs a nonempty `shapeToAdd`; `needs-IA-contract-change` requires such a suggestion. `port-declarative` has no contract change.
+
+**Report** — the human-review document. For a folder, one section per component. Use this structure:
+
+```markdown
+# <component>: <one-line conclusion>
+
+**Verdict:** <asIsVerdict> → <asDisplayWidget.verdict> (rebuild or not) · **Confidence:** high | low · **Needs human review:** yes | no
+
+## Why
+The user's goal, what maps cleanly, and what decides the verdict.
+
+## Blockers
+Each material blocker: gate, signal, evidence. "None" for `port-declarative`.
+
+## Suggested contract change
+Each field to add and why it must move into the action output. Omit when none is suggested.
+
+## What the widget keeps / drops
+Kept actions and dropped or replaced interactions.
+
+## Open questions
+What would resolve any low-confidence conclusion.
+```

package/skills/experience-lwc-widget-migrate/SKILL.md

@@ -0,0 +1,50 @@
+---
+name: experience-lwc-widget-migrate
+description: "Convert a specific existing Lightning web component (LWC) into a declarative HXL / Agentforce widget, end to end. Gates on experience-lwc-widget-assess and stops when a widget cannot serve the LWC's purpose; otherwise hands the derived field shape to platform-widget-generate and wires the widget as the Lightning Type renderer. TRIGGER when: the user wants to convert, migrate, port, rebuild, or turn a named LWC into a widget or declarative Agentforce widget, or asks for a widget built from an existing LWC component. DO NOT TRIGGER when: the user only wants to know whether an LWC can become a widget (use experience-lwc-widget-assess), or wants a widget for a data shape, entity, or Lightning Type with no existing LWC (use platform-widget-generate or platform-lightning-type-widget-coordinate)."
+metadata:
+  version: "1.0"
+  domains: ["Experience", "Platform", "Agentforce"]
+  minApiVersion: "68.0"
+  relatedSkills:
+    - "experience-lwc-widget-assess"
+    - "platform-widget-generate"
+    - "platform-custom-lightning-type-generate"
+    - "platform-lightning-type-widget-coordinate"
+  mcpTools:
+    metadata-experts:
+      tools: ["execute_metadata_action"]
+      semver: ">=1.0.0"
+---
+
+# Migrate an LWC to a widget
+
+Use the LWC to recover the **user's goal and data contract**, then build the closest useful widget. A widget is its own declarative artifact. `platform-widget-generate` authors it; a Lightning Type renderer may need separate wiring to make it reachable. This skill owns the comparison, handoff, integration check, and honest final status.
+
+## 1. Decide whether to proceed
+
+Read and apply `experience-lwc-widget-assess` to the component, its action output, and any existing Lightning Type/renderer. Preserve its verdict and the key findings from its report (blockers, contract change, lost interactions) in your report; do not write the assessment's own `verdict.json` or `report.md` files. Stop on `pointless`, `blocked`, `review`, or `needsHumanReview: true`. Proceed on `viable` only when the intended change is explicit:
+
+- For `port-declarative`, preserve the current visible fields and actions.
+- For `needs-IA-contract-change`, identify the exact bounded output fields or pre-shaped values required. A widget against a **proposed** contract is a draft until the action returns that contract; do not call it working.
+- For `not-portable` with a viable adaptation, describe the replacement UX and each lost interaction. Call it a rebuild, not a faithful port.
+
+## 2. Derive the generator handoff
+
+Trace each value the proposed widget displays to the actual or proposed action output. Before authoring, verify the action contract rather than relying only on an assessment prompt's description. Pass `platform-widget-generate` an ordered field shape (`name`, `type`, `required`), nested/list item fields, the intended tile role of each visible element, and supported terminal actions. Preserve render order and field paths. Use its discovery results for tile definitions and attributes, its documented formula catalog for expressions, and its instructions for schema types and bundle layout; do not maintain a second catalog here. A formula can cover supported scalar/date/regex operations, while collection restructuring may require pre-shaped output.
+
+If an LWC fixture or action example contains sample data, it can help infer the shape; sample data is optional and is **not** a documented generator input or a substitute for the action contract. Do not invent sample fields. For an action such as `sendMessage`, verify that the required context reaches the agent and that the agent has a way to perform the requested work. Do not assume a widget input form can submit collected values without a discovered, validated mechanism.
+
+## 3. Generate and connect
+
+Load `platform-widget-generate` and follow its mandatory live `discoverUiComponents` and `getUiComponentSchemas` calls. If the `metadata-experts` MCP or discovery is unavailable, stop before authoring a bundle; report the completed assessment and proposed field shape. The generator owns its three widget files and self-validation. Do not copy its UEM syntax or validation checklist into this skill.
+
+For an Agentforce renderer migration, also establish the Lightning Type that receives the action output. A bundle alone is not connected to the action:
+
+- **Existing compatible Lightning Type:** inspect its schema and current `renderer.json`. After generation, read `platform-custom-lightning-type-generate/references/widget-rendition.md`, wire the widget with field mappings, and follow `platform-lightning-type-widget-coordinate`'s renderer checks. If the existing renderer points to another widget or LWC, surface the replacement/merge decision before changing it.
+- **No compatible Lightning Type:** resolve the action's output class and a Lightning Type name from the project or the user's request. For the coordinator's supported Apex-backed route, use `platform-lightning-type-widget-coordinate` with that type and the assessed output shape; let it own bundle generation and renderer wiring. That coordinator does not cover every type. If the output/type route cannot be established, stop and identify the missing integration step. Do not claim a complete migration.
+
+If the user requested a **bundle only**, report it explicitly as an unconnected bundle. Otherwise, completion requires both the bundle and renderer wiring.
+
+## 4. Check the result
+
+Use the generator's bundle self-validation. Then compare the result to the assessed candidate: every retained visible field has a binding to the real/proposed payload; list item paths and supported actions match; omitted behavior and contract changes are stated; and, for a renderer migration, the Lightning Type points to this widget with matching attributes. Static checks establish structure and mapping, not deployed runtime behavior. Report assessment, created paths, validation results, and one of: `migrated and wired`, `bundle only`, `draft pending IA contract`, or `stopped`, with the reason.

package/skills/field-service-data-capture-form-deployer-configure/SKILL.md

@@ -1,8 +1,10 @@
 ---
 name: field-service-data-capture-form-deployer-configure
 description: "Assemble a Data Capture Flow from a JSON spec and deploy it to a connected Field Service org via the Tooling Flow sObject (JSON Metadata, no XML). Use when given a data-capture spec JSON and asked to build or deploy a DataCaptureFlow."
+user-invocable: false
 metadata:
   version: "1.0"
+  domains: ["Field Service"]
 ---
 
 # Build a Data Capture Form (Field Service Mobile)
@@ -176,26 +178,3 @@ This skill has **no executable scripts**. Auth checks, record reads, the `Dynami
 - **`fs-data-capture-reference`** (sibling library skill) — reference manual for hand-authoring patterns, prohibited patterns + exact deploy errors, visual polish HTML, supporting CustomObject/PermissionSet/CustomTab deploy. Read this when diagnosing a deploy error or extending the JSON field mappings.
 - **`fs-data-capture-form-designer`** — produces the spec this skill consumes (from prose or an image/PDF).
 - **`fs-data-capture-form-editor`** — patches an already-deployed flow in the org. Uses the same Tooling `Flow` JSON round-trip (GET Metadata → edit → PATCH) this skill uses to create.
-
-<!-- skill-validate: ignore-start -->
-<!-- codey:operations start -->
-## Operations Reference
-
-Operations this skill uses — routing and dependency reference.
-
-| Operation | Purpose | Status | Call | Depends on |
-|-----------|---------|--------|------|------------|
-| `check-org-auth` | verify | — | `GET /services/data/v67.0/query` | — |
-| `check-flow-name-collision` | read | — | `GET /services/data/v67.0/tooling/query` | `check-org-auth` |
-| `verify-flow-deployed` | verify | — | `GET /services/data/v67.0/tooling/query` | `deploy-flow-metadata-json` |
-| `attach-ddc-to-parent` | write | — | `POST /services/data/v67.0/sobjects/DynamicDataCapture` | `verify-flow-deployed` |
-| `verify-ddc-attached` | verify | — | `GET /services/data/v67.0/query` | `attach-ddc-to-parent` |
-| `verify-parent-object-sharing-model` | verify | — | `GET /services/data/v67.0/tooling/query` | `verify-ddc-attached` |
-| `toggle-fss-sharing-flags` | write | — | `PATCH /headless/invoke/platform/field-service-operations-setup-page/save-field-service-settings-config` | `verify-parent-object-sharing-model` |
-| `verify-fss-sharing-flags` | verify | — | `GET /services/data/v67.0/tooling/query` | `toggle-fss-sharing-flags` |
-| `list-workorder-layouts-by-profile` | read | — | `GET /services/data/v67.0/tooling/query` | `verify-fss-sharing-flags` |
-| `rollback-detach-ddc` | write | — | `DELETE /services/data/v67.0/sobjects/DynamicDataCapture/{id}` | — |
-| `deploy-flow-metadata-json` | write | — | `POST /services/data/v67.0/tooling/sobjects/Flow` | `check-flow-name-collision` |
-| `patch-layout-add-ddc-related-list` | read | — | `GET /services/data/v67.0/tooling/sobjects/Layout/{id}` | `list-workorder-layouts-by-profile` |
-<!-- codey:operations end -->
-<!-- skill-validate: ignore-end -->

package/skills/field-service-data-capture-form-designer-configure/SKILL.md

@@ -1,8 +1,10 @@
 ---
 name: field-service-data-capture-form-designer-configure
-description: "Design a Field Service Mobile Data Capture Flow from either a natural-language description OR a PDF/image of an existing paper form. Extracts field labels, types, required-state, and section structure into an intermediate JSON spec, confirms the plan with the user, then hands off to `fs-data-capture-form-deployer` for compile + deploy. Handles both input modes in one skill — prose (\"build a Field Service form for asset inspection that captures…\", \"make a DataCaptureFlow that asks the technician to…\", \"create an inventory transfer form with…\") and visual sources (\"convert this PDF to a Data Capture Flow\", \"make a Field Service form from this image\", \"turn this paper form into a DataCaptureFlow\"). Detects the input mode automatically: if the user supplies a `.pdf`, `.png`, `.jpg`, or `.jpeg` path, extract from the visual source; otherwise extract from the prose. Do NOT use this skill to patch an already-deployed flow — that's `fs-data-capture-form-editor`."
+description: "Design a Field Service Mobile Data Capture Flow from either a natural-language description OR a PDF/image of an existing paper form. Extracts field labels, types, required-state, and section structure into an intermediate JSON spec, confirms the plan with the user, then hands off to fs-data-capture-form-deployer for compile + deploy. Handles both input modes in one skill — prose ('build a Field Service form for asset inspection', 'make a DataCaptureFlow that asks the technician to…', 'create an inventory transfer form') and visual sources ('convert this PDF to a Data Capture Flow', 'make a Field Service form from this image', 'turn this paper form into a DataCaptureFlow'). Detects the input mode automatically from a .pdf/.png/.jpg/.jpeg path, else extracts from the prose. Do NOT use this skill to patch an already-deployed flow — that's fs-data-capture-form-editor."
+user-invocable: false
 metadata:
   version: "1.0"
+  domains: ["Field Service"]
 ---
 
 # Design a Data Capture Form (from prose or from an image / PDF)
@@ -106,15 +108,3 @@ After a successful deploy, the flow exists but is invisible from the Forms tab o
 
 - `reference/extraction-from-prompt.md` — prose-evidence rules for picking field types from user descriptions, screen grouping, visibility rules, outcome-elicitation, validation checklist. Used in **prose mode**.
 - `reference/extraction-from-image.md` — control-evidence rules for picking field types from rendered widgets, repeater extraction rules, screen grouping, visibility rules, outcome-elicitation, validation checklist. Used in **image / PDF mode**.
-
-<!-- skill-validate: ignore-start -->
-<!-- codey:operations start -->
-## Operations Reference
-
-Operations this skill uses — routing and dependency reference.
-
-| Operation | Purpose | Status | Call | Depends on |
-|-----------|---------|--------|------|------------|
-| `handoff-to-deployer` | write | — | → `sfs-mobile-core-experience/fs-data-capture-form-deployer` | — |
-<!-- codey:operations end -->
-<!-- skill-validate: ignore-end -->

package/skills/field-service-mobile-branding-configure/SKILL.md

@@ -1,8 +1,10 @@
 ---
 name: field-service-mobile-branding-configure
-description: "Derive a Field Service mobile app color scheme from a brand source (URL, hex codes, brand-guide paste, or color description), validate WCAG AA contrast in both light and dark mode, and apply the 14-field scheme to the org-default `FieldServiceMobileSettings` record. Trigger phrases include \"brand the mobile app\", \"apply branding to Field Service mobile\", \"update the mobile app colors\", \"use this brand guide for the app\", \"set the color scheme for the mobile app\". Do NOT use this skill for Dispatcher console / Gantt branding (`FSLQA__GanttPalette__c`), Experience Cloud `BrandingSet` records, or scheduling policy colors — out of scope."
+description: "Derive a Field Service mobile app color scheme from a brand source (URL, hex codes, brand-guide paste, or color description), validate WCAG AA contrast in both light and dark mode, and apply the 14-field scheme to the org-default FieldServiceMobileSettings record. Trigger phrases include 'brand the mobile app', 'apply branding to Field Service mobile', 'update the mobile app colors', 'use this brand guide for the app', 'set the color scheme for the mobile app'. Do NOT use this skill for Dispatcher console / Gantt branding, Experience Cloud BrandingSet records, or scheduling policy colors — out of scope."
+user-invocable: false
 metadata:
   version: "1.0"
+  domains: ["Field Service"]
 ---
 
 # Field Service Mobile Branding
@@ -129,19 +131,3 @@ Contrast validation and scheme derivation are performed by the agent inline (see
 
 - `configure-field-service-mobile` — page layouts, permissions, and `FieldServiceSettings` toggles. This skill defers branding to here, and this skill defers structural mobile config to it.
 - `fs-data-capture-form-deployer` — generates and deploys Data Capture Flow metadata.
-
-<!-- skill-validate: ignore-start -->
-<!-- codey:operations start -->
-## Operations Reference
-
-Operations this skill uses — routing and dependency reference.
-
-| Operation | Purpose | Status | Call | Depends on |
-|-----------|---------|--------|------|------------|
-| `check-org-auth` | verify | — | `GET /services/data/v63.0/query` | — |
-| `describe-fsms-object` | verify | — | `GET /services/data/v63.0/sobjects/FieldServiceMobileSettings/describe` | `check-org-auth` |
-| `query-default-fsms-record` | read | — | `GET /services/data/v63.0/query` | `describe-fsms-object` |
-| `apply-fsms-scheme` | write | — | `PATCH /services/data/v63.0/sobjects/FieldServiceMobileSettings/{id}` | `query-default-fsms-record` |
-| `verify-fsms-scheme` | verify | — | `GET /services/data/v63.0/sobjects/FieldServiceMobileSettings/{id}` | `apply-fsms-scheme` |
-<!-- codey:operations end -->
-<!-- skill-validate: ignore-end -->