@salesforce/afv-skills 1.7.3 → 1.7.5

package/skills/developing-agentforce/references/production-gotchas.md

@@ -22,13 +22,13 @@ The `before_reasoning:` and `after_reasoning:` lifecycle hooks are validated. Co
 
 ### Cost Optimization Pattern
 
-Fetch data once in `before_reasoning:`, cache in variables, reuse across topics.
+Fetch data once in `before_reasoning:`, cache in variables, reuse across subagents.
 
 ## Lifecycle Hooks
 
 ```yaml
-topic main:
-   description: "Topic with lifecycle hooks"
+subagent main:
+   description: "Subagent with lifecycle hooks"
 
    # BEFORE: Runs deterministically BEFORE LLM sees instructions
    before_reasoning:
@@ -55,7 +55,7 @@ topic main:
 - Reliable primitives: `set`, `if`/`else`, `transition to`. `run` has inconsistent runtime behavior across bundle types — use it in `reasoning.actions:` or `instructions: ->` instead
 - `before_reasoning:` is FREE (no credit cost) - use for data prep
 - `after_reasoning:` is FREE (no credit cost) - use for logging, cleanup
-- `transition to` works in `after_reasoning:` — but if a topic transitions mid-reasoning, the original topic's `after_reasoning:` does NOT run
+- `transition to` works in `after_reasoning:` — but if a subagent transitions mid-reasoning, the original subagent's `after_reasoning:` does NOT run
 
 **❌ WRONG Syntax (causes compile error):**
 ```yaml
@@ -74,19 +74,19 @@ before_reasoning:
 
 | Term | Syntax | Behavior | Use When |
 |------|--------|----------|----------|
-| **Handoff** | `@utils.transition to @topic.X` | Control transfers completely, child generates final response | Checkout, escalation, terminal states |
-| **Supervision** | `@topic.X` (as action reference) | Parent orchestrates, child returns, parent synthesizes | Expert consultation, sub-tasks |
+| **Handoff** | `@utils.transition to @subagent.X` | Control transfers completely, child generates final response | Checkout, escalation, terminal states |
+| **Supervision** | `@subagent.X` (as action reference) | Parent orchestrates, child returns, parent synthesizes | Expert consultation, sub-tasks |
 
 ```yaml
-# HANDOFF - child topic takes over completely:
-checkout: @utils.transition to @topic.order_checkout
+# HANDOFF - child subagent takes over completely:
+checkout: @utils.transition to @subagent.order_checkout
    description: "Proceed to checkout"
-# → @topic.order_checkout generates the user-facing response
+# → @subagent.order_checkout generates the user-facing response
 
 # SUPERVISION - parent remains in control:
-get_advice: @topic.product_expert
+get_advice: @subagent.product_expert
    description: "Consult product expert"
-# → @topic.product_expert returns, parent topic synthesizes final response
+# → @subagent.product_expert returns, parent subagent synthesizes final response
 ```
 
 **KNOWN BUG**: Adding ANY new action in Canvas view may inadvertently change Supervision references to Handoff transitions.
@@ -111,16 +111,16 @@ outputs:
       is_used_by_planner: True    # LLM can use for routing decisions
 
 # In Agent Script - LLM routes but cannot hallucinate:
-topic intent_router:
+subagent intent_router:
    reasoning:
       instructions: ->
          run @actions.classify_intent
          set @variables.intent = @outputs.intent_classification
 
          if @variables.intent == "refund":
-            transition to @topic.refunds
+            transition to @subagent.refunds
          if @variables.intent == "order_status":
-            transition to @topic.orders
+            transition to @subagent.orders
 ```
 
 ## Action I/O Metadata Properties
@@ -187,26 +187,26 @@ KNOWN BUG: Chained actions with Prompt Templates don't properly map inputs using
 
 For prompt template action definitions, input binding syntax, and grounded data patterns, see [Action Prompt Templates](action-prompt-templates.md).
 
-## Latch Variable Pattern for Topic Re-entry
+## Latch Variable Pattern for Subagent Re-entry
 
-Topic selector doesn't properly re-evaluate after user provides missing input. Use a "latch" variable to force re-entry:
+Subagent router doesn't properly re-evaluate after user provides missing input. Use a "latch" variable to force re-entry:
 
 ```yaml
 variables:
    verification_in_progress: mutable boolean = False
 
-start_agent topic_selector:
+start_agent agent_router:
    reasoning:
       instructions: ->
          if @variables.verification_in_progress == True:
-            transition to @topic.verification
+            transition to @subagent.verification
          | How can I help you today?
       actions:
-         start_verify: @topic.verification
+         start_verify: @subagent.verification
             description: "Start identity verification"
             set @variables.verification_in_progress = True
 
-topic verification:
+subagent verification:
    reasoning:
       instructions: ->
          | Please provide your email to verify your identity.
@@ -219,9 +219,9 @@ topic verification:
 
 ## Loop Protection Guardrail
 
-Agent Scripts have a built-in guardrail that limits iterations to approximately **3-4 loops** before breaking out and returning to the Topic Selector.
+Agent Scripts have a built-in guardrail that limits iterations to approximately **3-4 loops** before breaking out and returning to the Subagent Router.
 
-**Best Practice**: Map out your execution paths and test for unintended circular references between topics.
+**Best Practice**: Map out your execution paths and test for unintended circular references between subagents.
 
 ## Token & Size Limits
 

package/skills/developing-agentforce/references/safety-review-reference.md

@@ -78,8 +78,8 @@ For each finding, assign severity: **BLOCK** (stops pipeline), **WARN** (flags f
 | Check | Severity | What to Look For |
 |-------|----------|------------------|
 | Missing scope definition | WARN | No "do not" or "only handle" clause |
-| Overly broad scope | WARN | No topic boundaries, no escalation path |
-| Missing escalation | WARN | Complex/sensitive topics without human transfer |
+| Overly broad scope | WARN | No subagent boundaries, no escalation path |
+| Missing escalation | WARN | Complex/sensitive subagents without human transfer |
 | Missing error handling | INFO | No instructions for when agent can't help |
 
 ## Output Format

package/skills/developing-agentforce/references/scoring-rubric.md

@@ -6,11 +6,11 @@ Score every generated agent against this rubric before presenting to the user.
 
 | Category | Points | Key Criteria |
 |----------|--------|--------------|
-| Structure & Syntax | 15 | All required blocks present (`system`, `config`, `start_agent`, at least one `topic`). Correct block order (`system` → `config` → `variables` → ...). Proper nesting. Consistent 4-space indentation. Valid field names. All string values double-quoted. |
+| Structure & Syntax | 15 | All required blocks present (`system`, `config`, `start_agent`, at least one `subagent`). Correct block order (`system` → `config` → `variables` → ...). Proper nesting. Consistent 4-space indentation. Valid field names. All string values double-quoted. |
 | Safety & Responsible AI | 15 | Evaluated via safety review (7 categories): AI disclosure present, no impersonation/deception/manipulation, responsible data handling, no harmful content (including euphemisms), no discrimination (direct or proxy), clear scope boundaries, escalation paths for sensitive topics. Deduct 15 for any BLOCK finding, 5 per WARN finding. |
-| Deterministic Logic | 20 | `after_reasoning` patterns for post-action routing. FSM transitions with no dead-end topics. `available when` guards for security-sensitive actions. Post-action checks at TOP of `instructions: ->`. |
+| Deterministic Logic | 20 | `after_reasoning` patterns for post-action routing. FSM transitions with no dead-end subagents. `available when` guards for security-sensitive actions. Post-action checks at TOP of `instructions: ->`. |
 | Instruction Resolution | 20 | Clear, actionable instructions. Procedural mode (`->`) where conditionals are needed. Literal mode (`\|`) where static text suffices. Variable injection where dynamic. Conditional instructions based on state. |
-| FSM Architecture | 10 | Hub-and-spoke or verification gate pattern. Every topic reachable. Every topic has an exit (transition or escalation). No orphan topics. Start topic routes correctly. |
+| FSM Architecture | 10 | Hub-and-spoke or verification gate pattern. Every subagent reachable. Every subagent has an exit (transition or escalation). No orphan subagents. Start subagent routes correctly. |
 | Action Configuration | 10 | Proper Level 1 definitions with targets and I/O schemas. Correct Level 2 invocations with `with`/`set`. Slot-filling (`...`) for conversational inputs. Output capture into variables. Correct type mapping for action I/O (use `object` + `complex_data_type_name` for SObjects and custom Lightning types). |
 | Deployment Readiness | 10 | Valid `default_agent_user`. `developer_name` matches folder. `bundle-meta.xml` present with `<bundleType>AGENT</bundleType>`. Linked variables for service agents (`EndUserId`, `RoutableId`, `ContactId`). |
 

package/skills/developing-datacloud-code-extension/SKILL.md

@@ -0,0 +1,321 @@
+---
+name: developing-datacloud-code-extension
+description: "Develop and deploy Data Cloud Code Extensions using SF CLI plugin. Use this skill when creating custom Python transformations for Data Cloud, deploying code extensions, or testing data transformations. Supports init, run, scan, and deploy operations."
+metadata:
+  version: "1.0"
+---
+
+# developing-datacloud-code-extension Skill
+
+## Overview
+
+This skill provides a complete workflow for developing, testing, and deploying custom Python code extensions to Salesforce Data Cloud. Code extensions allow you to write Python transformations that read from and write to Data Lake Objects (DLOs) and Data Model Objects (DMOs).
+
+## When to Use
+
+- User wants to create a new code extension project
+- User needs to test a code extension locally
+- User wants to scan code for required permissions
+- User needs to deploy a code extension to Data Cloud
+- User is working with Data Cloud transformations
+- User wants to read/write DLO or DMO data programmatically
+
+## Prerequisites Check
+
+Before executing any code extension commands, verify prerequisites:
+
+1. **SF CLI with plugin installed**
+   ```bash
+   sf plugins --core | grep data-code-extension
+   ```
+   If not installed:
+   ```bash
+   sf plugins install @salesforce/plugin-data-codeextension
+   ```
+
+2. **Python 3.11**
+   ```bash
+   python --version  # Should show 3.11.x
+   ```
+
+3. **Data Cloud Custom Code SDK**
+   ```bash
+   pip list | grep salesforce-data-customcode
+   ```
+   If not installed:
+   ```bash
+   pip install salesforce-data-customcode
+   ```
+
+4. **Docker running** (for deploy only)
+   ```bash
+   docker ps
+   ```
+
+5. **Authenticated org**
+   ```bash
+   sf org display --target-org <org_alias> --json
+   ```
+
+## Skill Workflow
+
+### Phase 1: Initialize Project
+
+Create a new code extension project with scaffolding.
+
+**Commands:**
+
+For **script-based** code extensions (batch transformations):
+```bash
+sf data-code-extension script init --package-dir <directory>
+```
+
+For **function-based** code extensions (real-time):
+```bash
+sf data-code-extension function init --package-dir <directory>
+```
+
+**Required Option:**
+- `--package-dir, -p` - Directory path where the package will be created
+
+**What it creates:**
+```
+my-transform/              # Project root
+├── payload/               # CRITICAL: This is what --package-dir must point to for deploy
+│   ├── entrypoint.py      # Main transformation code
+│   └── config.json        # Code extension configuration
+├── requirements.txt       # Python dependencies
+└── README.md
+```
+
+## Directory Context During Workflow
+
+**IMPORTANT:** Understanding the directory structure is critical for successful deployment.
+
+**Commands and their directory requirements:**
+
+| Command | Run From | Path/File Argument |
+|---------|----------|-------------------|
+| `init` | Parent directory | `<project-name>` or `.` |
+| `scan` | Project root | `./payload/entrypoint.py` |
+| `run` | Project root | `./payload/entrypoint.py` |
+| `deploy` | Project root | `--package-dir ./payload` (**REQUIRED**) |
+
+**CRITICAL: The `--package-dir` argument in deploy command MUST point to the `payload` directory, not the project root.**
+
+### Phase 2: Develop Transformation
+
+Edit `payload/entrypoint.py` with transformation logic.
+
+**Script Example (Batch):**
+```python
+from datacustomcode import Client
+
+client = Client()
+
+# Read from DLO
+df = client.read_dlo('Employee__dll')
+
+# Transform data (uppercase position field)
+df['position_upper'] = df['position'].str.upper()
+
+# Write to output DLO
+client.write_to_dlo('Employee_Upper__dll', df, 'overwrite')
+```
+
+**Function Example (Real-time):**
+```python
+from datacustomcode import FunctionClient
+
+def transform(event, context):
+    client = FunctionClient(context)
+    input_data = event['data']
+    output = {
+        'name': input_data['name'].upper(),
+        'status': 'processed'
+    }
+    return output
+```
+
+**Common Operations:**
+- `client.read_dlo('DLO_Name__dll')` - Read from DLO
+- `client.read_dmo('DMO_Name')` - Read from DMO
+- `client.write_to_dlo('DLO_Name__dll', df, 'overwrite')` - Write to DLO
+- `client.write_to_dmo('DMO_Name', df, 'upsert')` - Write to DMO
+
+### Phase 3: Scan for Permissions
+
+Scan the entrypoint file to detect required permissions and generate config.json.
+
+**Command:**
+```bash
+sf data-code-extension script scan --entrypoint ./payload/entrypoint.py
+```
+
+**What it detects:**
+- Read permissions for DLOs/DMOs
+- Write permissions for DLOs/DMOs
+- Python package dependencies
+- Updates `config.json` and `requirements.txt`
+
+### Phase 4: Validate DLO Schema (Pre-Test Check)
+
+**CRITICAL: Before running tests locally, validate that all DLOs used in your code exist and have the expected fields.**
+
+#### Step 4a: Extract DLOs from config.json
+
+After scanning, review the generated `config.json` to identify all DLOs:
+
+```bash
+cat payload/config.json
+```
+
+#### Step 4b: Validate Each DLO Schema
+
+**Use the `getting-datacloud-schema` skill to verify DLOs exist and check field names.**
+
+For each DLO referenced in your code:
+
+1. **Verify DLO exists:**
+   ```bash
+   python3 scripts/get_dlo_schema.py <org_alias> <dlo_name>
+   ```
+
+2. **Verify field names match** — compare fields used in your `entrypoint.py` against the DLO schema.
+
+3. **Check all DLOs:**
+   - Validate all DLOs in `read` permissions
+   - Validate all DLOs in `write` permissions
+   - Check field names match exactly (case-sensitive)
+   - Verify data types are compatible with operations
+
+#### Step 4c: Validation Checklist
+
+Before proceeding to run, ensure:
+
+- [ ] All DLOs in config.json exist in target org
+- [ ] All field names used in code exist in DLO schemas
+- [ ] Field data types match your transformation logic
+- [ ] Primary key fields are correctly identified
+- [ ] Write target DLOs are created and accessible
+
+### Phase 5: Test Locally
+
+After validating DLO schemas, run the code extension locally against your Data Cloud org.
+
+**Command:**
+```bash
+sf data-code-extension script run --entrypoint <entrypoint_file> --target-org <org_alias> [options]
+```
+
+**Options:**
+- `--target-org, -o` - SF CLI org alias (required)
+- `--config-file, -c` - Custom config file path
+
+**If you get errors:**
+- Re-validate DLO schemas
+- Check field names are exact matches
+- Verify data types are compatible
+- Review error messages for field/DLO issues
+
+### Phase 6: Deploy to Data Cloud
+
+Deploy the code extension to Data Cloud for scheduled or on-demand execution.
+
+**CRITICAL: You MUST specify `--package-dir ./payload` to point to the payload directory created by init.**
+
+**Command:**
+```bash
+sf data-code-extension script deploy --target-org <org_alias> --name <name> --package-dir ./payload --package-version <version> --description <description> [options]
+```
+
+**Required Options:**
+- `--target-org, -o` - SF CLI org alias
+- `--name, -n` - Name for code extension deployment
+- `--package-dir` - Path to payload directory (**REQUIRED** - must be `./payload` when running from project root)
+- `--package-version` - Version string (default: 0.0.1)
+- `--description` - Description of code extension
+
+**Optional Options:**
+- `--cpu-size` - CPU size: CPU_L, CPU_XL, CPU_2XL (default), CPU_4XL
+- `--function-invoke-opt` - Function invoke options (for function type)
+- `--network` - Docker network (default: default)
+
+**After deployment:**
+- Navigate to Data Cloud in Salesforce UI
+- Go to Data Transforms section
+- Find your deployment by name
+- Click "Run Now" to execute
+- Schedule for recurring execution
+
+## Error Handling
+
+### Common Issues and Solutions
+
+| Error | Solution |
+|-------|----------|
+| `command data-code-extension not found` | `sf plugins install @salesforce/plugin-data-codeextension` |
+| `datacustomcode CLI not found` | `pip install salesforce-data-customcode` |
+| `Python version mismatch` | Use pyenv: `pyenv install 3.11.0 && pyenv local 3.11.0` |
+| `Cannot connect to Docker daemon` | Start Docker Desktop |
+| `No org found for alias` | `sf org login web --alias <org_alias>` |
+| `config.json not found` | `sf data-code-extension script scan --entrypoint ./payload/entrypoint.py` |
+| `DLO not found` | Verify DLO exists (use getting-datacloud-schema skill), check spelling and `__dll` suffix |
+| `Permission denied writing` | Re-run scan, verify target DLO exists and is writable |
+| `Deploy fails - wrong directory` | Ensure `--package-dir` points to `payload/` directory, not project root |
+
+## Best Practices
+
+### Development
+1. Always scan before testing — run scan after code changes
+2. Test locally first — use `run` command before deploying
+3. Use version control — git commit after each successful test
+4. Version your deployments — use semantic versioning (1.0.0, 1.1.0, etc.)
+5. Deploy from project root with `--package-dir ./payload`
+
+### Performance
+- **CPU_L**: Small datasets (< 1M records)
+- **CPU_2XL**: Medium datasets (1M-10M records)
+- **CPU_4XL**: Large datasets (> 10M records)
+
+### Security
+1. No hardcoded credentials — use SF CLI authentication only
+2. Validate input data — check for nulls and data types
+3. Limit write permissions — only grant necessary DLO/DMO access
+
+## Integration with Other Skills
+
+**Use with getting-datacloud-schema skill (CRITICAL for validation):**
+
+The `getting-datacloud-schema` skill is **required** for validating DLOs before testing code extensions.
+
+**Use with Datakit Workflow:**
+1. Create DLO via code extension
+2. Map DLO to DMO using datakit workflow
+3. Use DMO in segments and activations
+
+## Command Reference
+
+| Command | Purpose | Required Args |
+|---------|---------|---------------|
+| `script init` | Create new script project | --package-dir |
+| `function init` | Create new function project | --package-dir |
+| `script scan` | Generate config | entrypoint file |
+| `script run` | Test locally | entrypoint file, --target-org |
+| `script deploy` | Deploy to Data Cloud | --target-org, --name, --package-dir, --package-version, --description |
+
+## Resources
+
+- SF CLI Plugin: https://github.com/salesforcecli/plugin-data-code-extension
+- Python SDK: https://github.com/forcedotcom/datacloud-customcode-python-sdk
+- Data Cloud Docs: https://help.salesforce.com/s/articleView?id=sf.c360_a_intro.htm
+- Python SDK PyPI: https://pypi.org/project/salesforce-data-customcode/
+
+## Notes
+
+- Code extensions run in isolated Python 3.11 environment
+- Docker is required only for deployment, not for local testing
+- Use SF CLI authentication only (no separate credential files)
+- Scan command auto-detects permissions from code
+- Local run uses actual Data Cloud data (not mocked)
+- Deployments are versioned and can be rolled back in UI

package/skills/developing-datacloud-code-extension/references/README.md

@@ -0,0 +1,193 @@
+# developing-datacloud-code-extension Skill
+
+## Overview
+
+A skill that provides a complete workflow for developing, testing, and deploying custom Python code extensions to Salesforce Data Cloud using the SF CLI plugin.
+
+## What It Does
+
+This skill helps you create Data Cloud Code Extensions through a complete workflow:
+
+1. **Init** - Create new code extension project with scaffolding
+2. **Develop** - Write Python transformation logic
+3. **Scan** - Auto-detect permissions and generate config
+4. **Run** - Test locally against Data Cloud org
+5. **Deploy** - Package and deploy to Data Cloud
+
+## Usage
+
+**Initialize a project:**
+```
+"Create a new Data Cloud code extension project called employee-transform"
+"Initialize a code extension to transform employee data"
+```
+
+**Test locally:**
+```
+"Run the code extension in my-transform directory against afvibe org"
+"Test the entrypoint.py file locally"
+```
+
+**Scan for permissions:**
+```
+"Scan the entrypoint.py to generate config"
+"Update permissions in config.json"
+```
+
+**Deploy:**
+```
+"Deploy Employee_Upper code extension to afvibe"
+"Deploy this transform with package-version 1.0.0"
+```
+
+### Direct Command Usage
+
+```bash
+# Initialize project
+sf data-code-extension script init --package-dir <directory>
+
+# Scan for permissions
+sf data-code-extension script scan --entrypoint ./payload/entrypoint.py
+
+# Test locally
+sf data-code-extension script run --entrypoint ./payload/entrypoint.py --target-org <org_alias>
+
+# Deploy
+sf data-code-extension script deploy --target-org <org_alias> --name <name> --package-version <version> --description <description> --package-dir ./payload
+```
+
+## Prerequisites
+
+1. **SF CLI with Plugin**
+   ```bash
+   sf plugins install @salesforce/plugin-data-codeextension
+   ```
+
+2. **Python 3.11**
+   ```bash
+   python --version  # Must be 3.11.x
+   ```
+
+3. **Data Cloud Custom Code SDK**
+   ```bash
+   pip install salesforce-data-customcode
+   ```
+
+4. **Docker** (for deploy only)
+   - Docker Desktop or equivalent
+
+5. **Authenticated Org**
+   ```bash
+   sf org login web --alias <org_alias>
+   ```
+
+## Quick Start
+
+### Complete End-to-End Example
+
+```bash
+# 1. Create project
+mkdir employee-transform && cd employee-transform
+sf data-code-extension script init --package-dir .
+
+# 2. Edit payload/entrypoint.py with your transformation
+
+# 3. Scan for permissions
+sf data-code-extension script scan --entrypoint ./payload/entrypoint.py
+
+# 4. Test locally
+sf data-code-extension script run --entrypoint ./payload/entrypoint.py --target-org afvibe
+
+# 5. Deploy (MUST include --package-dir ./payload)
+sf data-code-extension script deploy \
+  --target-org afvibe \
+  --name Employee_Upper \
+  --package-version 1.0.0 \
+  --description "Uppercase employee positions" \
+  --package-dir ./payload
+```
+
+## Example Transformation
+
+**Read from DLO, transform, write to DLO:**
+
+```python
+from datacustomcode import Client
+
+client = Client()
+
+# Read employee data from DLO
+employees = client.read_dlo('Employee__dll')
+
+# Transform - uppercase position field
+employees['position_upper'] = employees['position'].str.upper()
+
+# Select output columns
+output = employees[['id', 'name', 'position_upper']]
+
+# Write to output DLO
+client.write_to_dlo('Employee_Upper__dll', output, 'overwrite')
+
+print(f"Processed {len(output)} employee records")
+```
+
+## Project Structure
+
+After `init`, you'll have:
+
+```
+my-transform/
+├── payload/
+│   ├── entrypoint.py      # Your transformation code
+│   └── config.json        # Permissions and configuration
+├── requirements.txt       # Python dependencies
+└── README.md
+```
+
+## Common Operations
+
+### Read/Write DLOs
+```python
+# Read
+df = client.read_dlo('Employee__dll')
+
+# Write (modes: 'overwrite', 'append')
+client.write_to_dlo('Employee_Upper__dll', df, 'overwrite')
+```
+
+### Read/Write DMOs
+```python
+# Read
+df = client.read_dmo('EmployeeDMO')
+
+# Write (modes: 'upsert', 'insert')
+client.write_to_dmo('EmployeeDMO', df, 'upsert')
+```
+
+## Troubleshooting
+
+| Error | Quick Fix |
+|-------|-----------|
+| Plugin not found | `sf plugins install @salesforce/plugin-data-codeextension` |
+| Python SDK missing | `pip install salesforce-data-customcode` |
+| Wrong Python version | Use pyenv to install 3.11.0 |
+| Org not connected | `sf org login web --alias <alias>` |
+| Config missing | Run scan command |
+| DLO not found | Check DLO name, use getting-datacloud-schema skill |
+| Docker error | Start Docker Desktop |
+
+## CPU Size Selection
+
+| CPU Size | Use Case | Data Volume |
+|----------|----------|-------------|
+| CPU_L | Small datasets | < 1M records |
+| CPU_XL | Medium datasets | 1M-5M records |
+| CPU_2XL | Large datasets (default) | 5M-10M records |
+| CPU_4XL | Very large datasets | > 10M records |
+
+## Resources
+
+- **SF CLI Plugin**: https://github.com/salesforcecli/plugin-data-code-extension
+- **Python SDK**: https://github.com/forcedotcom/datacloud-customcode-python-sdk
+- **Data Cloud Docs**: https://help.salesforce.com/s/articleView?id=sf.c360_a_intro.htm
+- **SDK on PyPI**: https://pypi.org/project/salesforce-data-customcode/