/data360-code-extension-generate

name: data360-code-extension-generate
description: "Create, develop, test, and deploy Data 360 (Data Cloud) Code Extensions with the sf CLI data-code-extension plugin and the salesforce-data-customcode Python SDK. Use this skill when creating or writing a code extension script or function (for example one that reads a DLO and writes a DLO), creating custom PySpark transformations for Data 360, editing an existing code extension payload/entrypoint.py, setting up a local code extension environment, scanning, running locally, deploying, or redeploying code extensions. Supports environment setup, init, scan, run, zip, and deploy for script and function packages."
metadata:
  version: "2.0.0"
  domains: ["Data 360", "Developer Experience"]
  cliTools:
    - tool: ["docker"]
      semver: ">=20.0.0"
    - tool: ["git"]
      semver: ">=2.0.0"
    - tool: ["java"]
      semver: ">=11.0.0"
    - tool: ["jq"]
      semver: ">=1.6.0"
    - tool: ["npm"]
      semver: ">=8.0.0"
    - tool: ["pip", "pip3"]
      semver: ">=23.0.0"
    - tool: ["python3.11", "python3"]
      semver: ">=3.11.0"
    - tool: ["sf"]
      semver: ">=2.0.0"

data360-code-extension-generate

Overview

A Data 360 code extension is customer-owned Python (PySpark) that runs inside Data 360:

| Type | Purpose | Local test | |---|---|---| | **script** | Batch transformation deployed as a **data transform**. Reads and writes DLOs or DMOs. | `script run` against real org data | | **function** | Custom node for **Search Index Chunking** (`--use-in-feature SearchIndexChunking`). | `function run --test-with test.json` |

Workflow: environment check → init → discover schemas → develop → scan → run locally → deploy → run the deployed transform. The skill needs only a shell, file editing, and the ability to ask the user questions. It works with a project venv or with a single system Python 3.11 (cloud workspaces, containers).

Use it to set up a code extension environment, create a script or function package, change `payload/entrypoint.py`, scan, run locally, deploy, redeploy, or clean up.

Agent Rules (apply to every phase)

1. **Pass `--target-org <ORG_ALIAS>` explicitly** to `run`, `deploy` and every `sf org` / `sf api` command, even when it's the CLI default. `init`, `scan` and `zip` reject it (`Nonexistent flag: --target-org`). 2. **Shell state doesn't persist.** Start every block that runs `sf data-code-extension`, `python3` or `pip` with the `<PY_ENV>` line from Phase 0b; other commands don't need it. Write `<ORG_ALIAS>`, `<PROJECT_DIR>`, `<API_VERSION>` and `<package_name>` literally. Never use `$(…)`, backticks or `eval`: some hosts (for example Code Builder) ask for approval on each one. Copy `PY_ENV` and `API_VERSION` exactly as `check_env.sh` prints them. 3. **Check before you install**, and skip anything already present. 4. **Confirm with the user before changing the org**: deploy, delete, or running a deployed transform. 5. **Hand interactive or privileged steps to the user**: `sf org login web`, enabling Code Extension, installing or starting Docker Desktop, `sudo`, installing Homebrew. 6. **Never print secrets** (access tokens, session IDs, OAuth client IDs or consumer keys). 7. **Resolve, print, proceed.** Don't ask for values the environment determines (Phase 0a). Ask only when a value is missing or ambiguous. If your shell can't prompt, ask in the conversation and write the files yourself. 8. **Schema first, then code** (Phase 2). Never write code first and ask the user to check the schema afterwards. 9. **Data 360 MCP server first for org lookups** (schemas, queries, runs, deletes). Do the MCP check (Phase 0b) once per session before the first lookup, even if Phase 0 was skipped. Fall back to `sf api` or the UI only when it isn't connected or a call fails, and say which you used. On `Session not found` (404), retry once before falling back. Details: [references/mcp-integration.md](references/mcp-integration.md). 10. **stderr:** when piping `sf … --json` into `jq`, use `2>/dev/null`, never `2>&1` (warnings break the JSON). Never redirect stderr on `scan`, `run` or `deploy`; their errors and tracebacks go there.

Phase 0: Environment and Org Readiness

0a. Resolve parameters

Take what the user already gave and pass `""` for the rest; `check_env.sh` (0b) resolves it:

| Parameter | Resolution order (first match wins) | |---|---| | `PROJECT_DIR` | User value → `$D360_PROJECT_DIR` → `/home/codebuilder/dx-project` if it exists (Code Builder) → current folder | | `ORG_ALIAS` | User value → `$D360_TARGET_ORG` → CLI default org if Connected → the only Connected org. Alias, or username if there's no alias | | `<package_name>` | User value, else a snake_case name from the request (for example `employee_upper`) |

Tell the user the values in one line and continue without waiting ("Using org `…` and project `…`. Say so if you want different ones."). Stop and ask only if several orgs are Connected with no Connected default (show them), or if none is Connected (ask for the My Domain URL and hand the browser login to the user: environment-setup.md §2).

0b. Run the read-only check

The plugin needs **exactly Python 3.11** and uses whatever `python3` is on `PATH`. The check picks **system mode** (`python3` is 3.11 and pip isn't blocked; `<PY_ENV>` puts the user-base `bin` folder on `PATH`) or **venv mode** (`<PROJECT_DIR>/.venv`; `<PY_ENV>` activates it). An existing `.venv` always means venv mode. Details: [references/environment-setup.md](references/environment-setup.md) §3.

bash <SKILL_DIR>/scripts/check_env.sh "<PROJECT_DIR or empty>" "<ORG_ALIAS or empty>"   # optional 3rd argument: system | venv

It changes nothing. It prints ✅/❌ for `sf` and the plugin, Python 3.11 (after `<PY_ENV>`), pip or venv state, `salesforce-data-customcode` and `pipreqs`, Java, Docker and the org connection, then `PROJECT_DIR=`, `ORG_ALIAS=`, `MODE=`, `PY_ENV=` and `API_VERSION=`. Use the printed `PY_ENV` and `