@salesforce/afv-skills 1.22.0 → 1.24.0

package/skills/platform-agentexchange-partner-offers-enable/SKILL.md

@@ -1,111 +0,0 @@
----
-name: platform-agentexchange-partner-offers-enable
-description: "Enable or disable the org preference that controls whether a Salesforce org can receive partner offers from the Transactable Marketplace. Use this skill when the user wants to turn partner offer reception on or off for an org. TRIGGER when: user asks to enable or disable partner offers, configure TransactableMarketplaceReceivePartnerOffers, configure enableTransactableMarketplaceReceivePartnerOffers, set up marketplace partner offer reception, toggle the TM partner offers setting, edit a TransactableMarketplacePrivateOffer.settings file, or configure org preferences related to transactable marketplace. DO NOT TRIGGER when: user needs to create or manage the partner offer records themselves, configure marketplace listing settings, or work with SfdcPartnerOffer objects (use deploying-metadata or generating-apex instead)."
-metadata:
-  version: "1.0"
-  minApiVersion: "67.0"
----
-
-# Enabling Transactable Marketplace Receive Partner Offers Org Preference
-
-This skill configures the `enableTransactableMarketplaceReceivePartnerOffers` org preference via the `TransactableMarketplacePrivateOfferSettings` Metadata API type, which controls whether a Salesforce org is eligible to receive partner offers through the Transactable Marketplace. It is required for subscriber orgs that participate in the TM partner offer flow.
-
-## Scope
-
-- **In scope**: Reading the current value of the pref, enabling or disabling it via Metadata API (`TransactableMarketplacePrivateOfferSettings`), and verifying the change took effect.
-- **Out of scope**: Creating or managing partner offer records, configuring marketplace listings, or any Apex/trigger changes related to offer processing.
-
----
-
-## Required Inputs
-
-- **Target org alias or username**: The org where the pref should be set. Ask if not provided.
-- **Desired state**: `true` (enable) or `false` (disable). Default: `true`.
-
----
-
-## Workflow
-
-### Phase 1 — Check current state
-
-1. **Query the current preference value** by running:
-   ```bash
-   sf data query -q "SELECT Preference, Value FROM OrgPreference WHERE Preference = 'TransactableMarketplaceReceivePartnerOffers'" --target-org <alias> --use-tooling-api
-   ```
-   If the record exists and `Value = true`, the pref is already enabled — confirm with the user before proceeding.
-   If the query returns no rows, the pref is not yet set (defaults to `false`).
-
-2. **Resolve the org's package directory** to determine where to write metadata. Run this and use its output as `<packageDir>`:
-   ```bash
-   jq -r '.packageDirectories[0].path // "force-app/main/default"' sfdx-project.json
-   ```
-
-### Phase 2 — Apply the preference
-
-3. **Write the TransactableMarketplacePrivateOfferSettings metadata file** — load `assets/org-pref-template.md` for the exact XML structure, then write the file at:
-   ```text
-   <packageDir>/settings/TransactableMarketplacePrivateOffer.settings
-   ```
-   Set `<enableTransactableMarketplaceReceivePartnerOffers>true</enableTransactableMarketplaceReceivePartnerOffers>` (or `false` if disabling).
-
-4. **Deploy the metadata** to the target org. Before running the deploy, confirm with the user:
-   - [ ] Confirmed the target org alias with the user (deploying to the wrong org is not easily reversible)
-   - [ ] Confirmed the desired state (`true`/`false`) matches the user's intent
-   ```bash
-   sf project deploy start --metadata TransactableMarketplacePrivateOfferSettings --target-org <alias>
-   ```
-
-### Phase 3 — Verify
-
-5. **Confirm the change** by re-running the Tooling API query from step 1 and verifying the `Value` column matches the desired state.
-
-6. **Report to the user** — see Output Expectations below.
-
----
-
-## Rules / Constraints
-
-| Rule | Rationale |
-|------|-----------|
-| Always query the current value before writing metadata | Avoids unnecessary deploys and detects conflicting changes |
-| Use `TransactableMarketplacePrivateOfferSettings` as the metadata type | This is the concrete type registered in the platform for this pref, not the generic `OrgPreferenceSettings` |
-| The settings file must be named `TransactableMarketplacePrivateOffer.settings` | Metadata API requires the filename to match the settings node name |
-| Do not hardcode `force-app/main/default/` | Always read `sfdx-project.json` for the actual package directory |
-| Never deploy without confirming the org alias with the user | Deploying to the wrong org is not easily reversible |
-
----
-
-## Gotchas
-
-| Issue | Resolution |
-|-------|------------|
-| Tooling API query returns no rows | Pref is unset (defaults to `false`). Safe to create a new settings file. |
-| Deploy fails with `INVALID_TYPE` | The metadata type name is `TransactableMarketplacePrivateOfferSettings` — check the `--metadata` flag value. |
-| Deploy succeeds but value doesn't change | Another settings file in the project may be overriding this one. Search for other `TransactableMarketplacePrivateOffer.settings` files in the project. |
-| `INSUFFICIENT_ACCESS_OR_READONLY` on deploy | User running the deploy must have the "Modify All Data" or org preference admin permission in the target org. |
-| Pref not visible in UI | `enableTransactableMarketplaceReceivePartnerOffers` is not surfaced in Setup UI — the Tooling API query is the only way to verify it. |
-| Available from API version 67.0+ only | The type is available from API v67.0 — deploying against an older API version will fail. |
-
----
-
-## Output Expectations
-
-After completing all phases, report:
-
-```text
-Org: <alias>
-Preference: enableTransactableMarketplaceReceivePartnerOffers
-Previous value: <true|false|unset>
-New value: <true|false>
-File written: <packageDir>/settings/TransactableMarketplacePrivateOffer.settings
-Deploy status: Success
-```
-
----
-
-## Reference File Index
-
-| File | When to read |
-|------|-------------|
-| `assets/org-pref-template.md` | Phase 2, step 3 — use as the exact XML structure for the settings file |
-| `examples/org-preference-settings.xml` | To verify the generated file matches expected format |

package/skills/platform-agentexchange-partner-offers-enable/assets/org-pref-template.md

@@ -1,27 +0,0 @@
-# TransactableMarketplacePrivateOfferSettings XML Template
-
-Use this exact structure when writing the settings metadata file.
-
-## File path
-
-```text
-<packageDir>/settings/TransactableMarketplacePrivateOffer.settings
-```
-
-## Template
-
-```xml
-<?xml version="1.0" encoding="UTF-8"?>
-<TransactableMarketplacePrivateOfferSettings xmlns="http://soap.sforce.com/2006/04/metadata">
-    <enableTransactableMarketplaceReceivePartnerOffers>true</enableTransactableMarketplaceReceivePartnerOffers>
-</TransactableMarketplacePrivateOfferSettings>
-```
-
-Replace `true` with `false` to disable.
-
-## Notes
-
-- The metadata type is `TransactableMarketplacePrivateOfferSettings`, available from API version 67.0+.
-- This type is registered with `apiCreateAllowed="false"` and `apiDeleteAllowed="false"` — it can only be updated, not created or deleted via the API. This does NOT mean you should skip writing the file: the preference always exists in the org with a default value, so writing a new local settings file and deploying it is treated as an update by the Metadata API and is always valid.
-- The `xmlns` attribute is required; omitting it causes a deploy parse error.
-- The field name is `enableTransactableMarketplaceReceivePartnerOffers` (note the `enable` prefix).

package/skills/platform-agentexchange-partner-offers-enable/examples/org-preference-settings.xml

@@ -1,4 +0,0 @@
-<?xml version="1.0" encoding="UTF-8"?>
-<TransactableMarketplacePrivateOfferSettings xmlns="http://soap.sforce.com/2006/04/metadata">
-    <enableTransactableMarketplaceReceivePartnerOffers>true</enableTransactableMarketplaceReceivePartnerOffers>
-</TransactableMarketplacePrivateOfferSettings>

package/skills/preparing-datacloud/CREDITS.md

@@ -1,7 +0,0 @@
-# Credits & Acknowledgments
-
-Primary contributor: **Gnanasekaran Thoppae**
-
-This skill is part of the `*-datacloud` family. Shared attribution, upstream source mapping, and maintenance notes live in:
-- [../orchestrating-datacloud/CREDITS.md](../orchestrating-datacloud/CREDITS.md)
-- [../orchestrating-datacloud/UPSTREAM.md](../orchestrating-datacloud/UPSTREAM.md)

package/skills/preparing-datacloud/README.md

@@ -1,51 +0,0 @@
-# preparing-datacloud
-
-Ingestion and lake-preparation workflows for Salesforce Data Cloud.
-
-## Use this skill for
-
-- data streams
-- Data Lake Objects (DLOs)
-- data transforms
-- Document AI setup and extraction
-- unstructured ingestion and re-scan workflows
-- deciding how a source dataset should enter Data Cloud
-- classifying a dataset as `Profile`, `Engagement`, or `Other`
-- using the Ingestion API send-data example after connector setup
-
-## Example requests
-
-```text
-"Create a Data Cloud stream from Contact"
-"Inspect the DLO created by this stream"
-"Help me create a transform for ingested data"
-"Re-run this SharePoint document stream so it picks up new files"
-"Show me how to send records to Data Cloud through the Ingestion API"
-```
-
-## Common commands
-
-```bash
-sf data360 data-stream list -o myorg 2>/dev/null
-sf data360 data-stream create-from-object -o myorg --object Contact --connection SalesforceDotCom_Home 2>/dev/null
-sf data360 data-stream run -o myorg --name Contact_Home 2>/dev/null
-sf data360 dlo get -o myorg --name Contact_Home__dll 2>/dev/null
-sf data360 transform list -o myorg 2>/dev/null
-sf data360 connection run-existing -o myorg --name <connection-id> 2>/dev/null
-```
-
-## Key reminders
-
-- confirm whether a dataset should be treated as `Profile`, `Engagement`, or `Other` before creating the stream
-- `data-stream run` is the preferred re-scan path for unstructured document ingestion
-- `connection run-existing` is a connection-level rerun and is not a full substitute for stream refresh
-- some external database and Ingestion API stream-creation flows still require UI setup
-- initial unstructured DLO setup can be richer in the UI than in a minimal CLI payload
-- use the local [examples/ingestion-api/](examples/ingestion-api/) folder for the send-data flow
-
-## References
-
-- [SKILL.md](SKILL.md)
-- [examples/ingestion-api/README.md](examples/ingestion-api/README.md)
-- [../orchestrating-datacloud/assets/definitions/data-stream.template.json](../orchestrating-datacloud/assets/definitions/data-stream.template.json)
-- [CREDITS.md](CREDITS.md)

package/skills/preparing-datacloud/SKILL.md

@@ -1,190 +0,0 @@
----
-name: preparing-datacloud
-description: "Salesforce Data Cloud Prepare phase. Use this skill when the user creates or manages Data Cloud data streams, DLOs, transforms, or Document AI configurations. TRIGGER when: user creates or manages Data Cloud data streams, DLOs, transforms, or Document AI configurations, or asks about ingestion into Data Cloud. DO NOT TRIGGER when: the task is connection setup only (use connecting-datacloud), DMOs and identity resolution (use harmonizing-datacloud), or query/search work (use retrieving-datacloud)."
-compatibility: "Requires an external community sf data360 CLI plugin and a Data Cloud-enabled org"
-metadata:
-  version: "1.0"
----
-
-# preparing-datacloud: Data Cloud Prepare Phase
-
-Use this skill when the user needs **ingestion and lake preparation work**: data streams, Data Lake Objects (DLOs), transforms, Document AI, unstructured ingestion, or the handoff from connector setup into a live stream.
-
-## When This Skill Owns the Task
-
-Use `preparing-datacloud` when the work involves:
-- `sf data360 data-stream *`
-- `sf data360 dlo *`
-- `sf data360 transform *`
-- `sf data360 docai *`
-- choosing how data should enter Data Cloud
-- rerunning or rescanning ingestion after a source update
-- preparing Ingestion API-backed streams after connector setup is complete
-
-Delegate elsewhere when the user is:
-- still creating/testing source connections → [connecting-datacloud](../connecting-datacloud/SKILL.md)
-- mapping to DMOs or designing IR/data graphs → [harmonizing-datacloud](../harmonizing-datacloud/SKILL.md)
-- querying ingested data → [retrieving-datacloud](../retrieving-datacloud/SKILL.md)
-
----
-
-## Required Context to Gather First
-
-Ask for or infer:
-- target org alias
-- source connection name
-- source object / dataset / document source
-- desired stream type
-- DLO naming expectations
-- whether the user is creating, updating, running, or deleting a stream
-- whether the source is CRM, a database connector, an unstructured file source, or an Ingestion API feed
-
----
-
-## Core Operating Rules
-
-- Verify the external plugin runtime before running Data Cloud commands.
-- Run the shared readiness classifier before mutating ingestion assets: `node ../orchestrating-datacloud/scripts/diagnose-org.mjs -o <org> --phase prepare --json`.
-- Prefer inspecting existing streams and DLOs before creating new ingestion assets.
-- Suppress linked-plugin warning noise with `2>/dev/null` for normal usage.
-- Treat DLO naming and field naming as Data Cloud-specific, not CRM-native.
-- Confirm whether each dataset should be treated as `Profile`, `Engagement`, or `Other` before creating the stream.
-- Distinguish stream-level refresh from connection-level reruns when working with unstructured sources.
-- Use UI setup intentionally when initial stream or unstructured asset creation is platform-gated.
-- Hand off to Harmonize only after ingestion assets are clearly healthy.
-
----
-
-## Recommended Workflow
-
-### 1. Classify readiness for prepare work
-```bash
-node ../orchestrating-datacloud/scripts/diagnose-org.mjs -o <org> --phase prepare --json
-```
-
-### 2. Inspect existing ingestion assets
-```bash
-sf data360 data-stream list -o <org> 2>/dev/null
-sf data360 dlo list -o <org> 2>/dev/null
-```
-
-### 3. Confirm the stream category before creation
-Use these rules when suggesting categories:
-
-| Category | Use for | Typical requirement |
-|---|---|---|
-| `Profile` | person/entity records | primary key |
-| `Engagement` | time-based events or interactions | primary key + event time field |
-| `Other` | reference/configuration/supporting datasets | primary key |
-
-When the source is ambiguous, ask the user explicitly whether the dataset should be treated as `Profile`, `Engagement`, or `Other`.
-
-### 4. Create or inspect streams intentionally
-```bash
-sf data360 data-stream get -o <org> --name <stream> 2>/dev/null
-sf data360 data-stream create-from-object -o <org> --object Contact --connection SalesforceDotCom_Home 2>/dev/null
-sf data360 data-stream create -o <org> -f stream.json 2>/dev/null
-sf data360 data-stream run -o <org> --name <stream> 2>/dev/null
-```
-
-### 5. Check DLO shape
-```bash
-sf data360 dlo get -o <org> --name Contact_Home__dll 2>/dev/null
-```
-
-### 6. Choose the right refresh mechanism
-Use the smaller refresh scope that matches the user goal:
-
-```bash
-sf data360 data-stream run -o <org> --name <stream> 2>/dev/null
-sf data360 connection run-existing -o <org> --name <connection-id> 2>/dev/null
-```
-
-- `data-stream run` is the closest match to a stream-level refresh or re-scan.
-- `connection run-existing` runs at the connection level and can be useful for some connector workflows, but it is not a reliable replacement for stream refresh on unstructured sources.
-- For unstructured document connectors, prefer `data-stream run` when the goal is to re-scan newly added or changed files.
-
-### 7. Handle unstructured sources deliberately
-For SharePoint-style document ingestion, a minimal unstructured DLO payload can look like:
-
-```json
-{
-  "name": "my_udlo",
-  "label": "My UDLO",
-  "category": "Directory_Table",
-  "dataSource": {
-    "sourceType": "SF_DRIVE",
-    "directoryAndFilesDetails": [
-      {
-        "dirName": "SPUnstructuredDocument/<CONNECTION_ID>/<SITE_ID>",
-        "fileName": "*"
-      }
-    ],
-    "sourceConfig": {
-      "reservedPrefix": "$dcf_content$"
-    }
-  }
-}
-```
-
-Use the UI for the first-time unstructured setup when the user needs the richer end-to-end pipeline. The UI path can seed additional document metadata fields and downstream assets that a bare CLI DLO create flow may not provision automatically.
-
-### 8. Use the local Ingestion API example for send-data workflows
-For external systems pushing records into Data Cloud:
-
-1. create the connector in [connecting-datacloud](../connecting-datacloud/SKILL.md)
-2. upload the schema with `sf data360 connection schema-upsert`
-3. create the stream in the UI when required
-4. send records with the local example in `examples/ingestion-api/`
-
-```bash
-cd examples/ingestion-api
-cp .env.example .env
-python3 send-data.py
-```
-
-Key details:
-- auth is a staged flow: JWT → Salesforce token → Data Cloud token
-- the ingestion endpoint uses the tenant URL, not the Salesforce instance URL
-- `202` means the payload was accepted for processing, not that records are queryable immediately
-- validation failures often surface in the Problem Records DLO family
-
-### 9. Only then move into harmonization
-Once the stream and DLO are healthy, hand off to [harmonizing-datacloud](../harmonizing-datacloud/SKILL.md).
-
----
-
-## High-Signal Gotchas
-
-- CRM-backed stream behavior is not the same as fully custom connector-framework ingestion.
-- `sf data360 data-stream run` and `sf data360 connection run-existing` are not interchangeable; prefer stream-level refresh for unstructured rescans.
-- `SFDC` streams sync on a platform-managed schedule; `data-stream run` is not the general control path for CRM connector refresh.
-- Some external database connectors can be created via API while stream creation still requires UI flow or org-specific browser automation. Do not promise a pure CLI stream-creation path for every connector type.
-- Initial SharePoint-style unstructured setup can be richer in the UI than in a minimal CLI DLO create flow.
-- Stream deletion can also delete the associated DLO unless the delete mode says otherwise.
-- DLO field naming differs from CRM field naming, including `__c` → `_c` transformations.
-- Query DLO record counts with Data Cloud SQL instead of assuming list output is sufficient.
-- `CdpDataStreams` means the stream module is gated for the current org/user; guide the user to provisioning/permissions review instead of retrying blindly.
-
----
-
-## Output Format
-
-```text
-Prepare task: <stream / dlo / transform / docai>
-Source: <connection + object>
-Target org: <alias>
-Artifacts: <stream names / dlo names / json definitions>
-Verification: <passed / partial / blocked>
-Next step: <harmonize or retrieve>
-```
-
----
-
-## References
-
-- [README.md](README.md)
-- [examples/ingestion-api/README.md](examples/ingestion-api/README.md)
-- [../orchestrating-datacloud/assets/definitions/data-stream.template.json](../orchestrating-datacloud/assets/definitions/data-stream.template.json)
-- [../orchestrating-datacloud/references/plugin-setup.md](../orchestrating-datacloud/references/plugin-setup.md)
-- [../orchestrating-datacloud/references/feature-readiness.md](../orchestrating-datacloud/references/feature-readiness.md)

package/skills/preparing-datacloud/examples/ingestion-api/.env.example

@@ -1,8 +0,0 @@
-CONSUMER_KEY=<your consumer key from External Client App>
-CONSUMER_SECRET=<your consumer secret>
-SF_USERNAME=<your salesforce username>
-SF_LOGIN_URL=https://login.salesforce.com
-TENANT_URL=https://<tenant-id>.c360a.salesforce.com
-PRIVATE_KEY_FILE=/path/to/server.key
-CONNECTOR_NAME=Badge_Scanner
-OBJECT_NAME=Badge_Scan

package/skills/preparing-datacloud/examples/ingestion-api/README.md

@@ -1,48 +0,0 @@
-# Ingestion API example
-
-This folder contains a minimal, public-safe example for sending records into Salesforce Data Cloud through the Ingestion API.
-
-## What this example assumes
-
-Before running `send-data.py`, complete the connect/prepare setup steps:
-
-1. create an Ingestion API connector
-2. upload the schema with `sf data360 connection schema-upsert`
-3. create the corresponding data stream in the UI if your org requires that step
-
-Related connector definitions live in:
-- [../../../connecting-datacloud/examples/connections/ingest-api-connection.json](../../../connecting-datacloud/examples/connections/ingest-api-connection.json)
-- [../../../connecting-datacloud/examples/connections/ingest-api-schema.json](../../../connecting-datacloud/examples/connections/ingest-api-schema.json)
-
-## Prerequisites
-
-```bash
-pip install PyJWT cryptography requests
-```
-
-## Setup
-
-```bash
-cd skills/preparing-datacloud/examples/ingestion-api
-cp .env.example .env
-# edit .env with your values
-python3 send-data.py
-```
-
-## Environment variables
-
-- `CONSUMER_KEY` — external client app consumer key
-- `CONSUMER_SECRET` — external client app consumer secret if your auth flow needs it
-- `SF_USERNAME` — Salesforce username used for JWT auth
-- `SF_LOGIN_URL` — login host such as `https://login.salesforce.com`
-- `TENANT_URL` — Data Cloud tenant URL such as `https://<tenant>.c360a.salesforce.com`
-- `PRIVATE_KEY_FILE` — path to the JWT private key
-- `CONNECTOR_NAME` — Ingestion API connector name
-- `OBJECT_NAME` — uploaded schema object name
-
-## Notes
-
-- auth is a staged flow: JWT → Salesforce token → Data Cloud token
-- the ingestion endpoint uses the Data Cloud tenant URL, not the Salesforce instance URL
-- `202` means the payload was accepted for processing
-- validation failures often appear in the Problem Records DLO family

package/skills/preparing-datacloud/examples/ingestion-api/send-data.py

@@ -1,144 +0,0 @@
-#!/usr/bin/env python3
-"""
-Send data to Data Cloud through the Ingestion API.
-
-Prerequisites:
-  pip install PyJWT cryptography requests
-
-Usage:
-  1. Copy .env.example to .env and fill in your values
-  2. python3 send-data.py
-
-See README.md in this folder for setup notes.
-"""
-
-from __future__ import annotations
-
-import os
-import time
-import uuid
-from datetime import datetime, timezone
-from pathlib import Path
-
-import jwt
-import requests
-
-
-def load_env_file() -> None:
-    env_file = Path(__file__).parent / ".env"
-    if not env_file.exists():
-        return
-
-    for line in env_file.read_text().splitlines():
-        if "=" in line and not line.startswith("#"):
-            key, val = line.split("=", 1)
-            os.environ.setdefault(key.strip(), val.strip())
-
-
-load_env_file()
-
-CONSUMER_KEY = os.environ["CONSUMER_KEY"]
-SF_USERNAME = os.environ["SF_USERNAME"]
-SF_LOGIN_URL = os.environ.get("SF_LOGIN_URL", "https://login.salesforce.com")
-TENANT_URL = os.environ["TENANT_URL"]
-PRIVATE_KEY_FILE = os.environ["PRIVATE_KEY_FILE"]
-CONNECTOR_NAME = os.environ["CONNECTOR_NAME"]
-OBJECT_NAME = os.environ["OBJECT_NAME"]
-
-
-def get_cdp_token() -> str:
-    """Authenticate: JWT -> Salesforce access token -> Data Cloud token."""
-    private_key = Path(PRIVATE_KEY_FILE).read_text()
-
-    claim = {
-        "iss": CONSUMER_KEY,
-        "sub": SF_USERNAME,
-        "aud": SF_LOGIN_URL,
-        "exp": int(time.time()) + 300,
-    }
-    assertion = jwt.encode(claim, private_key, algorithm="RS256")
-
-    token_data = requests.post(
-        f"{SF_LOGIN_URL}/services/oauth2/token",
-        data={
-            "grant_type": "urn:ietf:params:oauth:grant-type:jwt-bearer",
-            "assertion": assertion,
-        },
-        timeout=60,
-    ).json()
-
-    if "access_token" not in token_data:
-        raise RuntimeError(f"Salesforce auth failed: {token_data}")
-
-    cdp_data = requests.post(
-        f"{token_data['instance_url']}/services/a360/token",
-        headers={"Content-Type": "application/x-www-form-urlencoded"},
-        data={
-            "grant_type": "urn:salesforce:grant-type:external:cdp",
-            "subject_token": token_data["access_token"],
-            "subject_token_type": "urn:ietf:params:oauth:token-type:access_token",
-        },
-        timeout=60,
-    ).json()
-
-    if "access_token" not in cdp_data:
-        raise RuntimeError(f"Data Cloud token exchange failed: {cdp_data}")
-
-    return cdp_data["access_token"]
-
-
-def send_records(cdp_token: str, records: list[dict[str, str]]) -> tuple[int, str]:
-    """Send records to the Ingestion API."""
-    url = f"{TENANT_URL}/api/v1/ingest/sources/{CONNECTOR_NAME}/{OBJECT_NAME}"
-    response = requests.post(
-        url,
-        headers={
-            "Authorization": f"Bearer {cdp_token}",
-            "Content-Type": "application/json",
-        },
-        json={"data": records},
-        timeout=60,
-    )
-    return response.status_code, response.text
-
-
-if __name__ == "__main__":
-    print("Authenticating...")
-    token = get_cdp_token()
-    print("Data Cloud token acquired")
-
-    records = [
-        {
-            "ScanId": str(uuid.uuid4()),
-            "EventId": "EVT-001",
-            "AttendeeId": "ATT-001",
-            "Scantime": datetime.now(timezone.utc).isoformat(),
-            "Room": "Main Hall",
-        },
-        {
-            "ScanId": str(uuid.uuid4()),
-            "EventId": "EVT-001",
-            "AttendeeId": "ATT-002",
-            "Scantime": datetime.now(timezone.utc).isoformat(),
-            "Room": "Workshop A",
-        },
-        {
-            "ScanId": str(uuid.uuid4()),
-            "EventId": "EVT-001",
-            "AttendeeId": "ATT-003",
-            "Scantime": datetime.now(timezone.utc).isoformat(),
-            "Room": "Workshop B",
-        },
-    ]
-
-    print(f"Sending {len(records)} records to {CONNECTOR_NAME}/{OBJECT_NAME}...")
-    status, body = send_records(token, records)
-    print(f"Response: {status} {body}")
-
-    if status == 202:
-        print("\nData accepted. Records typically appear in Data Cloud within a few minutes.")
-        print(
-            "Query with: sf data360 query sql -o <org> --sql 'SELECT * FROM \"<DLO_NAME>__dll\" LIMIT 10'"
-        )
-    else:
-        print("\nIngestion failed. Check the response above for details.")

package/skills/querying-soql/CREDITS.md

@@ -1,21 +0,0 @@
-# Credits & Acknowledgments
-
-This skill integrates concepts and patterns from the Salesforce developer community and official Salesforce documentation. The goal is to teach Apex developers how to write efficient, maintainable SOQL using vanilla Apex patterns that don't require external package installation.
-
----
-
-## Key Patterns Integrated
-
-| Pattern | Integration |
-|---------|-------------|
-| Selector Layer architecture | `references/selector-patterns.md` |
-| Bulkification and Map-based lookup | `assets/bulkified-query-pattern.cls` |
-| SOQL anti-patterns catalog | `references/anti-patterns.md` |
-| Query Plan analysis | `SKILL.md`, `assets/optimization-patterns.soql` |
-| Field coverage validation | `references/field-coverage-rules.md` |
-
----
-
-## Philosophy
-
-This skill integrates **concepts and patterns** from community resources, not specific libraries as dependencies. All patterns produce vanilla Apex code that works in any Salesforce org without additional package installation.

package/skills/querying-soql/README.md

@@ -1,41 +0,0 @@
-# querying-soql
-
-Salesforce SOQL query generation, optimization, and analysis skill with 100-point scoring. Convert natural language into performant SOQL and validate queries for security, selectivity, and governor-limit awareness.
-
-## Features
-
-- **Natural Language to SOQL**: Convert requests into executable queries
-- **Query Optimization**: Improve selectivity, LIMIT usage, and field selection
-- **Relationship Queries**: Parent-child, child-parent, and polymorphic patterns
-- **Security Guidance**: `WITH USER_MODE`, `WITH SECURITY_ENFORCED`, and Apex-safe usage
-- **100-Point Scoring**: Performance, correctness, security, and readability checks
-
-## Quick Start
-
-### 1. Invoke the skill
-
-```
-Skill: querying-soql
-Request: "Find Accounts with open Opportunities created this quarter"
-```
-
-### 2. Typical use cases
-
-- Generate SOQL from plain-English requirements
-- Optimize slow or non-selective queries
-- Build aggregates and relationship queries
-- Validate queries before using them in Apex or CLI workflows
-
-## Documentation
-
-- [SKILL.md](SKILL.md) - Core workflow and optimization guidance
-- [references/query-optimization.md](references/query-optimization.md) - Selectivity and performance tuning
-- [references/soql-syntax-reference.md](references/soql-syntax-reference.md) - Syntax, relationships, and aggregates
-- [references/selector-patterns.md](references/selector-patterns.md) - Reusable Apex selector patterns
-- [references/cli-commands.md](references/cli-commands.md) - sf CLI query execution examples
-
-## Related Skills
-
-- `handling-sf-data` - For data creation/import/export workflows
-- `generating-apex` - For inline SOQL inside Apex code
-- `running-apex-tests` - For validating query behavior in tests