@salesforce/afv-skills 1.65.0 → 1.66.0

package/skills/crm-analytics-tableau-next-datacloud-validate/SKILL.md

@@ -1,83 +0,0 @@
----
-name: crm-analytics-tableau-next-datacloud-validate
-description: "Generic preflight check for Tableau Next / App-Framework template installs — verify Data Cloud is provisioned on the org and resolve the target data space apiName BEFORE a readiness/create call. Returns a PROCEED verdict (exporting the resolved $DATA_SPACE_NAME) or a STOP verdict with an actionable \"enable Data Cloud / create a data space\" message. Invoked by tableau-next-app-install's preflight — it turns the opaque late-stage `TEMPLATEPARSEERROR: Data space [X] is unknown` / `CDP not enabled` failures into an early, clear gate. Not user-invocable; this is a reusable building-block check, not a standalone workflow."
-metadata:
-  version: "1.0"
-  cliTools:
-  - tool:
-    - "jq"
-    semver: ">=1.6"
-  - tool:
-    - "sf"
-    semver: ">=2.0.0"
----
-
-# tableau-next-datacloud-readiness
-
-## What this does
-
-A single **generic preflight check** any App-Framework template install can run: *is Data Cloud usable on this org, and what is the real data space apiName?*
-
-App-Framework readiness/create bodies bind any `DataSpaceType` (or data-space-carrying `StringType`) variable to an **existing** data space name. A missing/invalid data space does NOT surface as a clean readiness `FailedStatus` — it fails variable-definition parsing FIRST, so the readiness POST returns an opaque `HTTP 400 TEMPLATEPARSEERROR: Data space [<X>] ... is unknown` (wire-verified 2026-08-19), or `HTTP 400 CDP not enabled` when Data Cloud is off entirely. Running this check up front converts that late, cryptic failure into an early, actionable STOP.
-
-This is the executable form of the caller skill's **precondition 4** and **wire rule G**.
-
-## Contract
-
-**Inputs (must be set by the caller before invoking):**
-
-| Var | Meaning |
-|---|---|
-| `$ORG_ALIAS` | sf-CLI alias of the target org |
-| `$API_VERSION` | resolved API version, e.g. `v69.0` (from the caller's "Discover API version" step) |
-
-**Outputs (exported back to the caller on PROCEED):**
-
-| Var | Meaning |
-|---|---|
-| `$DATA_SPACE_NAME` | the resolved data space apiName to bind into every `DataSpaceType` / data-space-carrier variable — NEVER the literal `"default"` unless the org's data space is genuinely named `default` |
-| `$DC_READINESS_VERDICT` | `PROCEED` or `STOP` |
-
-**Verdict:**
-- **PROCEED** — Data Cloud is provisioned and at least one data space exists; `$DATA_SPACE_NAME` is set. The caller may continue to variable-build / readiness / create.
-- **STOP** — Data Cloud is off (403 / `CDP not enabled`) or no data space exists. The caller MUST halt the install and route the user to enablement. Do not attempt readiness/create — it will 400.
-
-## Check
-
-```bash
-# Precondition: $ORG_ALIAS and $API_VERSION are set by the caller.
-: "${ORG_ALIAS:?tableau-next-datacloud-readiness needs ORG_ALIAS}"
-: "${API_VERSION:?tableau-next-datacloud-readiness needs API_VERSION}"
-
-# Probe the data spaces endpoint. Capture body AND distinguish a Data-Cloud-off
-# org (403 / empty) from a provisioned one. `2>/dev/null` drops the sf beta banner.
-DS_JSON=$(sf api request rest "/services/data/$API_VERSION/ssot/data-spaces" \
-  --target-org "$ORG_ALIAS" --method GET 2>/dev/null)
-
-DS_COUNT=$(echo "$DS_JSON" | jq -r '(.dataSpaces // []) | length' 2>/dev/null)
-DATA_SPACE_NAME=$(echo "$DS_JSON" | jq -r '(.dataSpaces // [] | .[0].name) // empty' 2>/dev/null)
-
-if [ -n "$DATA_SPACE_NAME" ]; then
-  DC_READINESS_VERDICT="PROCEED"
-  echo "[tableau-next-datacloud-readiness] PROCEED — $DS_COUNT data space(s); using \"$DATA_SPACE_NAME\""
-else
-  DC_READINESS_VERDICT="STOP"
-  cat >&2 <<'MSG'
-[tableau-next-datacloud-readiness] STOP — Data Cloud is not usable on this org.
-Either Data Cloud (CDP) is not provisioned, or no data space exists.
-A template install that binds a DataSpaceType variable WILL fail on the readiness
-POST with `TEMPLATEPARSEERROR: Data space [...] is unknown` or `CDP not enabled`.
-
-Fix: have an admin enable Data Cloud and create/confirm a data space, then retry.
-This check will not attempt the install.
-MSG
-fi
-
-export DATA_SPACE_NAME DC_READINESS_VERDICT
-```
-
-## Notes
-
-- **Never hardcode `"default"`.** Some orgs' sole data space is `Corp_Ds`, `Sales_Ds`, `Foundations_Corp_Ds`, etc. Posting `"default"` on such an org 400s with `TEMPLATEPARSEERROR: Data space [default] ... unknown`. The caller's Step-2 builder substitutes `$DATA_SPACE_NAME` (this check's output) into every data-space variable.
-- **Idempotent + read-only.** This check makes exactly one `GET /ssot/data-spaces` call and mutates nothing. Safe to run standalone or as a preflight gate.
-- **Scope.** This check answers "is Data Cloud usable + which data space." It does NOT validate that a specific template's DMOs are mapped/populated — that is the template `readiness.json` chain's job (the caller's Step 3), a separate concern.

package/skills/crm-analytics-tableau-next-provisioning-validate/SKILL.md

@@ -1,81 +0,0 @@
----
-name: crm-analytics-tableau-next-provisioning-validate
-description: "Generic preflight check for Tableau Next / App-Framework template installs — verify Tableau Next / App-Framework is provisioned and reachable on the org BEFORE attempting an install. Confirms `GET /app-framework/templates` returns a non-empty list (not empty, not a 403 INSUFFICIENT_ACCESS on the endpoint itself, not NOT_FOUND). Returns a PROCEED verdict (exporting the fetched $TEMPLATES_JSON so the caller need not re-fetch) or a STOP verdict routing the user to Tableau Next enablement. Not user-invocable; this is a reusable building-block check, not a standalone workflow."
-metadata:
-  version: "1.0"
-  cliTools:
-  - tool:
-    - "jq"
-    semver: ">=1.6"
-  - tool:
-    - "sf"
-    semver: ">=2.0.0"
----
-
-# tableau-next-readiness
-
-## What this does
-
-A single **generic preflight check** any App-Framework template install can run: *is Tableau Next / App-Framework actually provisioned on this org?*
-
-If `GET $API_BASE/templates` returns an empty list, an `INSUFFICIENT_ACCESS` on the endpoint itself (not the caller's row-level access), or `NOT_FOUND`, then Tableau Next / App-Framework is not provisioned — no template install can succeed and this is not something an install skill can fix. Running this check up front produces a clear "enable Tableau Next" STOP instead of a confusing empty-templates or 403 mid-flow.
-
-This is the executable form of the caller skill's **precondition 3**.
-
-## Contract
-
-**Inputs (must be set by the caller before invoking):**
-
-| Var | Meaning |
-|---|---|
-| `$ORG_ALIAS` | sf-CLI alias of the target org |
-| `$API_BASE` | resolved App-Framework base, e.g. `/services/data/v69.0/app-framework` (from the caller's "Discover API version" step) |
-
-**Outputs (exported back to the caller on PROCEED):**
-
-| Var | Meaning |
-|---|---|
-| `$TEMPLATES_JSON` | the full `GET $API_BASE/templates` payload — the caller reuses it in Step 1 (allowlist re-check + presence check) rather than re-fetching |
-| `$TN_READINESS_VERDICT` | `PROCEED` or `STOP` |
-
-**Verdict:**
-- **PROCEED** — the templates endpoint returned a non-empty list; `$TEMPLATES_JSON` is populated. The caller may continue to enumerate/allowlist.
-- **STOP** — empty list, 403 on the endpoint, or NOT_FOUND. Tableau Next / App-Framework isn't provisioned (or the caller lacks visibility). The caller MUST halt and route the user to Tableau Next enablement (out of scope for an install skill).
-
-## Check
-
-```bash
-# Precondition: $ORG_ALIAS and $API_BASE are set by the caller.
-: "${ORG_ALIAS:?tableau-next-readiness needs ORG_ALIAS}"
-: "${API_BASE:?tableau-next-readiness needs API_BASE}"
-
-# Probe the templates endpoint. `2>/dev/null` drops the sf beta banner; a 403 /
-# NOT_FOUND surfaces as an error payload that yields count 0 below.
-TEMPLATES_JSON=$(sf api request rest "$API_BASE/templates" \
-  --target-org "$ORG_ALIAS" --method GET 2>/dev/null)
-
-TPL_COUNT=$(echo "$TEMPLATES_JSON" | jq -r '(.templates // []) | length' 2>/dev/null)
-
-if [ -n "$TPL_COUNT" ] && [ "$TPL_COUNT" -gt 0 ] 2>/dev/null; then
-  TN_READINESS_VERDICT="PROCEED"
-  echo "[tableau-next-readiness] PROCEED — $TPL_COUNT templates visible on this org."
-else
-  TN_READINESS_VERDICT="STOP"
-  cat >&2 <<'MSG'
-[tableau-next-readiness] STOP — Tableau Next / App-Framework is not provisioned
-on this org (the templates endpoint returned an empty list, a 403 on the endpoint
-itself, or NOT_FOUND).
-
-No App-Framework template can install here. Fix: route the user to Tableau Next
-enablement (out of scope for the install skill). This check will not proceed.
-MSG
-fi
-
-export TEMPLATES_JSON TN_READINESS_VERDICT
-```
-
-## Notes
-
-- **Distinguish the two 403s.** An empty list / 403 *on the templates endpoint itself* is a feature gate (Tableau Next not provisioned) — that's what this check catches. A 403 `ACCESS_DENIED` / `INSUFFICIENT_ACCESS` on readiness/create with the endpoint resolving is instead a missing `AppFrameworkManageTemplate` user permission (the caller's precondition 2) — a different remediation, out of this check's scope.
-- **Idempotent + read-only.** One `GET /templates` call, mutates nothing. The caller reuses `$TEMPLATES_JSON` so the normal split path makes this call exactly once.
-- **Scope.** This check answers "is Tableau Next provisioned + reachable." It does NOT check whether a specific template is on the allowlist or present — that is the caller's Step 1.

package/skills/data360-activation-create/SKILL.md

@@ -1,104 +0,0 @@
----
-name: data360-activation-create
-description: "Use this skill when users want to execute Data Cloud Activation operations via the Data 360 MCP facade. Trigger when users mention data360/activation, shared, cdp, mcp, connect, api, shared-cdp-mcp-connect-api."
-metadata:
-  version: "1.0"
----
-
-# Managing Data360/activation
-
-## When to Use This Skill
-
-Execute Data Cloud Activation operations via the Data 360 MCP facade.
-
-## Workflow
-
-Each step lists an `operation` id. Call describe(<operation>) BEFORE dispatching to get that tool's parameter schema and, where available, a worked example. `paramsJson` decodes to the operation's requestBody schema VERBATIM, including its top-level key (e.g. `input`, `dataTransform`) — do not unwrap or omit it. The only envelope the step handles for you is `{toolName, paramsJson}` (its `invocation` already wraps it); do not POST the operation path directly. If the tool's error suggests `payload_examples`, ignore it — that tool isn't available here; call describe(<operation>) instead.
-
-## Critical Constraints
-
-**Destructive operations — require explicit user confirmation:**
-
-- **`activation-delete`** — Delete an activation by 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 |
-|-----------|---------|--------|------|------------|
-| `activation-create` | write | implemented | `execute_activation-create` | — |
-| `activation-delete` | delete | implemented | `execute_activation-delete` | — |
-| `activation-get` | read | implemented | `execute_activation-get` | — |
-| `activation-list` | read | implemented | `execute_activation-list` | — |
-| `activation-publish` | write | implemented | `execute_activation-publish` | — |
-| `activation-update` | write | implemented | `execute_activation-update` | — |
-
-### Read operations
-
-#### `activation-get`
-
-Get the details of a specific activation by ID.
-
-**Call:** `execute_activation-get`   — status: `implemented`
-
-**Inputs:**
-
-- `paramsJson` *(`string`)* — JSON-encoded params for d360_activation_get (a STRING, double-encoded). Serialize the operation's requestBody schema VERBATIM including its top-level key (e.g. `input`, `dataTransform`) — do not unwrap it. Call describe(execute_activation-get) for the param schema and, where available, a worked example.
-
-#### `activation-list`
-
-List all activations. Optionally paginate with batchSize and offset, filter with filters, and sort with orderBy.
-
-**Call:** `execute_activation-list`   — status: `implemented`
-
-**Inputs:**
-
-- `paramsJson` *(`string`)* — JSON-encoded params for d360_activation_list (a STRING, double-encoded). Serialize the operation's requestBody schema VERBATIM including its top-level key (e.g. `input`, `dataTransform`) — do not unwrap it. Call describe(execute_activation-list) for the param schema and, where available, a worked example.
-
-### Write operations
-
-#### `activation-create`
-
-Create an activation. Required fields: name, refreshType (exactly FULL_REFRESH or 
-
-**Call:** `execute_activation-create`   — status: `implemented`
-
-**Inputs:**
-
-- `paramsJson` *(`string`)* — JSON-encoded params for d360_activation_create (a STRING, double-encoded). Serialize the operation's requestBody schema VERBATIM including its top-level key (e.g. `input`, `dataTransform`) — do not unwrap it. Call describe(execute_activation-create) for the param schema and, where available, a worked example.
-
-#### `activation-publish`
-
-Publish an activation on-demand by activation ID. Triggers immediate ad-hoc execution of the activation, 
-
-**Call:** `execute_activation-publish`   — status: `implemented`
-
-**Inputs:**
-
-- `paramsJson` *(`string`)* — JSON-encoded params for d360_activation_publish (a STRING, double-encoded). Serialize the operation's requestBody schema VERBATIM including its top-level key (e.g. `input`, `dataTransform`) — do not unwrap it. Call describe(execute_activation-publish) for the param schema and, where available, a worked example.
-
-#### `activation-update`
-
-Update an activation by ID. Replaces the activation definition with the provided input.
-
-**Call:** `execute_activation-update`   — status: `implemented`
-
-**Inputs:**
-
-- `paramsJson` *(`string`)* — JSON-encoded params for d360_activation_update (a STRING, double-encoded). Serialize the operation's requestBody schema VERBATIM including its top-level key (e.g. `input`, `dataTransform`) — do not unwrap it. Call describe(execute_activation-update) for the param schema and, where available, a worked example.
-
-### Destructive operations
-
-#### `activation-delete`
-
-Delete an activation by ID.
-
-**Call:** `execute_activation-delete`   — status: `implemented`
-
-**Inputs:**
-
-- `paramsJson` *(`string`)* — JSON-encoded params for d360_activation_delete (a STRING, double-encoded). Serialize the operation's requestBody schema VERBATIM including its top-level key (e.g. `input`, `dataTransform`) — do not unwrap it. Call describe(execute_activation-delete) for the param schema and, where available, a worked example.

package/skills/data360-activation-external-platform-get/SKILL.md

@@ -1,49 +0,0 @@
----
-name: data360-activation-external-platform-get
-description: "Use this skill when users want to execute Data Cloud ActivationExternalPlatform operations via the Data 360 MCP facade. Trigger when users mention data360/activation, external, platform, shared, cdp, mcp, connect, api, shared-cdp-mcp-connect-api."
-metadata:
-  version: "1.0"
----
-
-# Querying Data360/activation External Platform
-
-## When to Use This Skill
-
-Execute Data Cloud ActivationExternalPlatform operations via the Data 360 MCP facade.
-
-## Workflow
-
-Each step lists an `operation` id. Call describe(<operation>) BEFORE dispatching to get that tool's parameter schema and, where available, a worked example. `paramsJson` decodes to the operation's requestBody schema VERBATIM, including its top-level key (e.g. `input`, `dataTransform`) — do not unwrap or omit it. The only envelope the step handles for you is `{toolName, paramsJson}` (its `invocation` already wraps it); do not POST the operation path directly. If the tool's error suggests `payload_examples`, ignore it — that tool isn't available here; call describe(<operation>) instead.
-
-## Operations Reference
-
-Operations grouped by purpose. Use these as the building blocks for the workflows above.
-
-### Summary
-
-| Operation | Purpose | Status | Call | Depends on |
-|-----------|---------|--------|------|------------|
-| `activation-external-platform-get` | read | implemented | `execute_activation-external-platform-get` | — |
-| `activation-external-platforms-list` | read | implemented | `execute_activation-external-platforms-list` | — |
-
-### Read operations
-
-#### `activation-external-platform-get`
-
-Get a specific activation external platform by record Id or developer name. Optionally scope the returned attribute configuration to a standard event / action source.
-
-**Call:** `execute_activation-external-platform-get`   — status: `implemented`
-
-**Inputs:**
-
-- `paramsJson` *(`string`)* — JSON-encoded params for d360_activation_external_platform_get (a STRING, double-encoded). Serialize the operation's requestBody schema VERBATIM including its top-level key (e.g. `input`, `dataTransform`) — do not unwrap it. Call describe(execute_activation-external-platform-get) for the param schema and, where available, a worked example.
-
-#### `activation-external-platforms-list`
-
-List all available activation external platforms (destination systems for data activation). 
-
-**Call:** `execute_activation-external-platforms-list`   — status: `implemented`
-
-**Inputs:**
-
-- `paramsJson` *(`string`)* — JSON-encoded params for d360_activation_external_platforms_list (a STRING, double-encoded). Serialize the operation's requestBody schema VERBATIM including its top-level key (e.g. `input`, `dataTransform`) — do not unwrap it. Call describe(execute_activation-external-platforms-list) for the param schema and, where available, a worked example.

package/skills/data360-activation-target-create/SKILL.md

@@ -1,93 +0,0 @@
----
-name: data360-activation-target-create
-description: "Use this skill when users want to execute Data Cloud ActivationTarget operations via the Data 360 MCP facade. Trigger when users mention data360/activation, target, shared, cdp, mcp, connect, api, shared-cdp-mcp-connect-api."
-metadata:
-  version: "1.0"
----
-
-# Managing Data360/activation Target
-
-## When to Use This Skill
-
-Execute Data Cloud ActivationTarget operations via the Data 360 MCP facade.
-
-## Workflow
-
-Each step lists an `operation` id. Call describe(<operation>) BEFORE dispatching to get that tool's parameter schema and, where available, a worked example. `paramsJson` decodes to the operation's requestBody schema VERBATIM, including its top-level key (e.g. `input`, `dataTransform`) — do not unwrap or omit it. The only envelope the step handles for you is `{toolName, paramsJson}` (its `invocation` already wraps it); do not POST the operation path directly. If the tool's error suggests `payload_examples`, ignore it — that tool isn't available here; call describe(<operation>) instead.
-
-## Critical Constraints
-
-**Destructive operations — require explicit user confirmation:**
-
-- **`activation-target-delete`** — Delete an activation target by 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 |
-|-----------|---------|--------|------|------------|
-| `activation-target-create` | write | implemented | `execute_activation-target-create` | — |
-| `activation-target-delete` | delete | implemented | `execute_activation-target-delete` | — |
-| `activation-target-get` | read | implemented | `execute_activation-target-get` | — |
-| `activation-target-list` | read | implemented | `execute_activation-target-list` | — |
-| `activation-target-update` | write | implemented | `execute_activation-target-update` | — |
-
-### Read operations
-
-#### `activation-target-get`
-
-Get an activation target by ID.
-
-**Call:** `execute_activation-target-get`   — status: `implemented`
-
-**Inputs:**
-
-- `paramsJson` *(`string`)* — JSON-encoded params for d360_activation_target_get (a STRING, double-encoded). Serialize the operation's requestBody schema VERBATIM including its top-level key (e.g. `input`, `dataTransform`) — do not unwrap it. Call describe(execute_activation-target-get) for the param schema and, where available, a worked example.
-
-#### `activation-target-list`
-
-List activation targets. Optionally paginate with batchSize and offset, filter with filters, and sort with orderBy.
-
-**Call:** `execute_activation-target-list`   — status: `implemented`
-
-**Inputs:**
-
-- `paramsJson` *(`string`)* — JSON-encoded params for d360_activation_target_list (a STRING, double-encoded). Serialize the operation's requestBody schema VERBATIM including its top-level key (e.g. `input`, `dataTransform`) — do not unwrap it. Call describe(execute_activation-target-list) for the param schema and, where available, a worked example.
-
-### Write operations
-
-#### `activation-target-create`
-
-Create an activation target. connector binds polymorphically on platformType and must 
-
-**Call:** `execute_activation-target-create`   — status: `implemented`
-
-**Inputs:**
-
-- `paramsJson` *(`string`)* — JSON-encoded params for d360_activation_target_create (a STRING, double-encoded). Serialize the operation's requestBody schema VERBATIM including its top-level key (e.g. `input`, `dataTransform`) — do not unwrap it. Call describe(execute_activation-target-create) for the param schema and, where available, a worked example.
-
-#### `activation-target-update`
-
-Update an activation target by ID with partial fields.
-
-**Call:** `execute_activation-target-update`   — status: `implemented`
-
-**Inputs:**
-
-- `paramsJson` *(`string`)* — JSON-encoded params for d360_activation_target_update (a STRING, double-encoded). Serialize the operation's requestBody schema VERBATIM including its top-level key (e.g. `input`, `dataTransform`) — do not unwrap it. Call describe(execute_activation-target-update) for the param schema and, where available, a worked example.
-
-### Destructive operations
-
-#### `activation-target-delete`
-
-Delete an activation target by ID.
-
-**Call:** `execute_activation-target-delete`   — status: `implemented`
-
-**Inputs:**
-
-- `paramsJson` *(`string`)* — JSON-encoded params for d360_activation_target_delete (a STRING, double-encoded). Serialize the operation's requestBody schema VERBATIM including its top-level key (e.g. `input`, `dataTransform`) — do not unwrap it. Call describe(execute_activation-target-delete) for the param schema and, where available, a worked example.