@elevasis/sdk 0.4.6 → 0.4.7

package/reference/getting-started/index.mdx

@@ -1,6 +1,7 @@
 ---
 title: Getting Started
 description: Install the Elevasis SDK, scaffold a project, and run your first deployment
+loadWhen: "Setting up a new project or onboarding"
 ---
 
 This guide takes you from a fresh install to a running deployment in four steps: install, scaffold, deploy, and execute.
@@ -28,33 +29,49 @@ elevasis init my-project
 cd my-project
 ```
 
-The command scaffolds 18 files covering configuration, source, documentation, and Claude Code integration:
+The command scaffolds 23 files covering configuration, source, documentation, and Claude Code integration:
 
 ```
 my-project/
 ├── CLAUDE.md                       # Project instructions for Claude Code
 ├── .claude/
 │   ├── settings.json               # autoCompact: false
-│   ├── profile.json                # Created on first session (gitignored)
 │   └── commands/
-│       ├── docs.md                 # Documentation assistant
+│       ├── docs.md                 # Documentation lifecycle
 │       ├── resource.md             # Resource scaffolding
-│       ├── deploy.md               # Deployment assistant
-│       ├── inspect.md              # Deployment health + execution debugging
-│       └── env.md                  # Platform env var management
+│       ├── meta.md                 # Project lifecycle (init, deploy, health, develop)
+│       ├── help.md                 # Command tree and navigation
+│       ├── database.md             # Database setup and management
+│       ├── agent.md                # Agent development
+│       ├── templates.md            # Workflow templates
+│       ├── tutorial.md             # Progressive learning
+│       └── profile.md              # View and update user profile
 ├── src/
-│   └── index.ts                    # Echo workflow starter
+│   ├── index.ts                    # Registry entry point
+│   └── workflows/
+│       └── echo.ts                 # Starter workflow
 ├── docs/
-│   └── index.mdx                   # Starter documentation page
-├── elevasis.config.ts              # Config with commented-out options
+│   ├── index.mdx                   # Starter documentation page
+│   └── in-progress/
+│       └── .gitkeep                # Work-in-progress docs directory
+├── elevasis.config.ts              # Config with templateVersion and options
 ├── package.json                    # check-types + deploy scripts
 ├── tsconfig.json                   # TypeScript config (app-focused)
 ├── pnpm-workspace.yaml             # Standalone project workspace
 ├── .env                            # API key only
 ├── .env.example                    # Git-safe template
 ├── .npmrc                          # auto-install-peers
-├── .gitignore                      # Excludes worker temp file, claude files
-└── README.md                       # Setup and CLI reference
+└── .gitignore                      # Excludes worker temp file, claude files
+```
+
+The scaffolded `elevasis.config.ts` includes a `templateVersion` field that tracks which template generation your project uses. Leave it as-is -- it is managed automatically by `elevasis update`:
+
+```ts
+import type { ElevasConfig } from '@elevasis/sdk'
+
+export default {
+  templateVersion: 4,
+} satisfies ElevasConfig
 ```
 
 ### Set Up Your API Key
@@ -69,6 +86,10 @@ The `.env.example` file provides the same template and is safe to commit. The ac
 
 **Note:** Do not add `NODE_ENV` to your `.env`. The SDK treats `undefined` as production by default, which means your project connects to the hosted Elevasis API. Adding `NODE_ENV=development` is the most common setup mistake.
 
+### Guided Setup with Claude Code
+
+After scaffolding, open the project in Claude Code and run `/meta init`. This command installs dependencies, walks you through `.env` setup, creates your developer profile in `.claude/memory/`, and optionally runs your first deploy -- all in one guided flow.
+
 ---
 
 ## First Deployment
@@ -98,14 +119,14 @@ elevasis deployments     # Show deployment history
 Execute the scaffolded echo workflow to verify end-to-end connectivity:
 
 ```bash
-elevasis exec echo-workflow --input '{"message": "hello"}'
+elevasis exec echo --input '{"message": "hello"}'
 ```
 
 View the execution result:
 
 ```bash
-elevasis executions echo-workflow    # Execution history
-elevasis execution echo-workflow \<execution-id\>  # Full detail for one execution
+elevasis executions echo    # Execution history
+elevasis execution echo \<execution-id\>  # Full detail for one execution
 ```
 
 Replace `<execution-id>` with the ID returned from the executions list.
@@ -114,11 +135,14 @@ Replace `<execution-id>` with the ID returned from the executions list.
 
 ## Next Steps
 
-- [Project Structure](project-structure.mdx) -- Understand each scaffolded file
+- **Run `/meta init` in Claude Code** -- Guided setup that installs deps, configures `.env`, and creates your developer profile in `.claude/memory/`
+- [Development Framework](../framework/index.mdx) -- How Claude Code helps you build
 - [Resources](../resources/index.mdx) -- Define workflows and agents
 - [CLI Reference](../cli/index.mdx) -- Full command reference with flags
 - [Deployment](../deployment/index.mdx) -- Deployment lifecycle and environment variables
 
+When a new SDK version is released, run `elevasis update` to bring your project's managed files (CLAUDE.md, slash commands, `.gitignore`) up to date. The command adds missing files and flags any files that differ from the new template for agent-assisted review.
+
 ---
 
 **Last Updated:** 2026-02-25

package/reference/index.mdx

@@ -1,6 +1,7 @@
 ---
 title: Elevasis SDK
 description: Build and deploy workflows, agents, and resources with the Elevasis SDK
+loadWhen: "First session or new to the SDK"
 ---
 
 `@elevasis/sdk` lets you build workflows, agents, and resources in TypeScript and deploy them to the Elevasis platform with a single command. The developer experience is Vercel-style: write TypeScript, validate locally, deploy -- the platform handles execution, tool access, and observability. You never manage infrastructure. Zod 4.1 is the only peer dependency.
@@ -69,7 +70,7 @@ const result = await platform.call({
 });
 ```
 
-The platform exposes 70+ tools across 12 integration adapters -- Gmail, Slack, HubSpot, Notion, and more. Credentials are managed server-side; API keys never cross the execution boundary. LLM calls are also available via `platform.call({ tool: 'llm', ... })` with API keys resolved from platform environment variables.
+The platform exposes 70+ tools across 13 integration adapters -- Gmail, Stripe, Google Sheets, Notion, and more. Credentials are managed server-side; API keys never cross the execution boundary. LLM calls are also available via `platform.call({ tool: 'llm', ... })` with API keys resolved from platform environment variables.
 
 See [Platform Tools](platform-tools/index.mdx) for the full catalog.
 
@@ -88,16 +89,23 @@ See [Platform Tools](platform-tools/index.mdx) for the full catalog.
 
 - [Resources](resources/index.mdx) - Workflow and agent definition patterns, Zod schemas, step types, and routing
 - [Platform Tools](platform-tools/index.mdx) - Full catalog of 70+ tools, integration adapters, and credential management
+- [Security](security/credentials.mdx) - Three-layer credential model, HTTP tool patterns, and credential management
 
 ### Reference
 
+- [Concepts](concepts/index.mdx) - Plain-English concept explanations, glossary, Zod guide, execution model, and common errors
+- [Templates](templates/index.mdx) - 7 workflow templates: web-scraper, data-enrichment, email-sender, lead-scorer, and more
 - [CLI Reference](cli/index.mdx) - All CLI commands: check, deploy, exec, resources, executions, env, and more
 - [Deployment](deployment/index.mdx) - Deploy pipeline, versioning, bundle upload, and registry registration
 - [Runtime](runtime/index.mdx) - Worker execution model, concurrency, timeouts, cancellation, and resource limits
 
+### Framework
+
+- [Development Framework](framework/index.mdx) - How Claude Code helps you build: project structure, agent integration, memory, and documentation
+
 ### Developer Tools
 
-- [Documentation](documentation/index.mdx) - Writing and deploying MDX documentation alongside your resources
+- [Documentation](framework/documentation.mdx) - Writing and deploying MDX documentation alongside your resources
 - [Roadmap](roadmap/index.mdx) - Planned features including agent execution, streaming logs, and SDK testing utilities
 
 ---

package/reference/platform-tools/examples.mdx

@@ -1,6 +1,7 @@
 ---
 title: Integration Examples
 description: Common platform.call() patterns for email, CRM, PDF, LLM inference, resource triggering, and storage
+loadWhen: "Implementing a platform tool call in a workflow step"
 ---
 
 Common `platform.call()` patterns ready to use in your SDK workflows. Each example shows the complete invocation including tool name, method, params, and credential (where required).

package/reference/platform-tools/index.mdx

@@ -1,6 +1,7 @@
 ---
 title: Platform Tools
-description: Access 70+ integration adapters and platform services from your SDK workflows via platform.call()
+description: Access 70+ tools across integration adapters and platform services from your SDK workflows via platform.call()
+loadWhen: "Connecting to external services"
 ---
 
 `platform.call()` gives your SDK workflows access to the same 70+ tools that internal Elevasis agents use -- Gmail, Stripe, Google Sheets, PDF generation, human-in-the-loop approvals, storage, scheduling, and more. Credentials are managed server-side and never appear in your code. You pass a tool name, method, and parameters; Elevasis handles credential lookup, rate limiting, and retry transparently.
@@ -22,7 +23,7 @@ const result = await platform.call({
 
 ## Integration Adapters
 
-Twelve integration adapters give you access to roughly 50 tool factories covering third-party APIs. Pass the `credential` field with the name of the stored credential for that service.
+Thirteen integration adapters give you access to 70+ tool methods covering third-party APIs. Pass the `credential` field with the name of the stored credential for that service.
 
 | Adapter | Tools | Credential Shape |
 | --- | --- | --- |
@@ -38,6 +39,7 @@ Twelve integration adapters give you access to roughly 50 tool factories coverin
 | Dropbox | 2 (upload/folder) | `{ accessToken }` |
 | Apify | 1 (run actor) | `{ token }` |
 | Mailso | 1 (verify email) | `{ apiKey }` |
+| Supabase | 7 (insert/select/update/delete/upsert/rpc/count) | `{ url, serviceRoleKey }` |
 
 Credentials are stored in the Elevasis credentials table and injected server-side. The credential name you pass in `credential` must match the name you set when storing the credential.
 
@@ -132,6 +134,45 @@ elevasis env remove KEY
 
 Environment variables set this way are injected into your worker process at startup and are available via `process.env`.
 
+## Database Access
+
+Supabase is a first-class integration adapter that gives your workflows persistent storage using the same `platform.call()` interface as every other tool. Pass the `credential` field with the name of your stored Supabase credential.
+
+**Methods:** `insert`, `select`, `update`, `delete`, `upsert`, `rpc`, `count`
+
+```typescript
+// Select rows with filters
+const qualified = await platform.call({
+  tool: 'supabase',
+  credential: 'my-database',
+  method: 'select',
+  params: {
+    table: 'leads',
+    filter: { status: 'eq.qualified', score: 'gte.80' },
+    order: { column: 'score', ascending: false },
+    limit: 50,
+  },
+})
+// Returns: [{ id: '...', name: 'Jane Doe', score: 92, ... }, ...]
+```
+
+**Filter syntax** uses PostgREST string format (`operator.value`):
+
+| Filter | Example | Meaning |
+| --- | --- | --- |
+| `eq` | `{ status: 'eq.qualified' }` | Equals |
+| `neq` | `{ status: 'neq.lost' }` | Not equals |
+| `gt`, `gte`, `lt`, `lte` | `{ score: 'gte.80' }` | Comparisons |
+| `like`, `ilike` | `{ name: 'ilike.%jane%' }` | Pattern match |
+| `in` | `{ status: 'in.(new,contacted)' }` | In set |
+| `is` | `{ deleted_at: 'is.null' }` | Null check |
+
+**Credential setup:** Create a credential with provider `supabase` in the command center. The config fields are `url` (your Supabase project URL) and `serviceRoleKey` (the service role key from Settings > API). Workflows always use the service role key -- server-side execution, no RLS.
+
+**`/database init`:** A guided setup command that stores your Supabase credential, generates `data/schema.ts`, and creates `docs/database.mdx`.
+
+**`data/schema.ts`:** An agent-readable Zod schema that documents your table structure. It is NOT deployed and NOT executed -- the agent reads it to understand your data model when writing workflow steps or generating queries.
+
 ## Documentation
 
 - [Integration Examples](examples.mdx) - Common `platform.call()` patterns with working code for email, CRM, PDF, LLM, and more

package/reference/resources/index.mdx

@@ -1,6 +1,7 @@
 ---
 title: Writing Resources
 description: Guide to creating workflows and agents using WorkflowDefinition, AgentDefinition, and OrganizationResources with the Elevasis SDK
+loadWhen: "Building or modifying a workflow"
 ---
 
 Resources are the building blocks of your Elevasis project. A resource is a workflow or agent definition that the platform can execute on your behalf. You define them in TypeScript, export them from a single entry point, and the platform handles scheduling, retries, logging, and execution.

package/reference/resources/patterns.mdx

@@ -1,6 +1,7 @@
 ---
 title: Common Patterns
 description: Common resource patterns for Elevasis SDK developers -- sequential steps, conditional branching, platform tools, error handling, and resource status management
+loadWhen: "Building or modifying a workflow"
 ---
 
 This page collects the patterns you will reach for most often when writing resources. Each pattern is self-contained and can be adapted directly into your project.
@@ -117,7 +118,7 @@ const sendEmailStep: WorkflowStep = {
         subject: input.subject,
         body: input.body,
       },
-      credential: 'SENDGRID_API_KEY', // references a platform env var
+      credential: 'sendgrid',          // name of the stored credential
     });
 
     context.logger.info('Email sent', { messageId: result.messageId });

package/reference/resources/types.mdx

@@ -1,6 +1,7 @@
 ---
 title: SDK Types
 description: Complete type reference for @elevasis/sdk -- package exports, re-exported platform types, ElevasConfig interface, StepHandler context, and runtime values
+loadWhen: "Looking up type signatures or SDK exports"
 ---
 
 `@elevasis/sdk` is published to the public npm registry. It bundles all platform types from `@repo/core` into a single self-contained type declaration file with zero internal monorepo references. External developers install the package and get full TypeScript support without any monorepo tooling.

package/reference/roadmap/index.mdx

@@ -1,6 +1,7 @@
 ---
 title: Roadmap
 description: Planned SDK features -- error taxonomy, retry semantics, circuit breaker, metrics, alerting, and resource lifecycle extensions
+loadWhen: "Asking about future features or planned capabilities"
 ---
 
 **Status:** Planned -- none of these features are implemented yet.

package/reference/runtime/index.mdx

@@ -1,6 +1,7 @@
 ---
 title: Execution Runtime
 description: How your code runs on the Elevasis platform -- execution lifecycle, concurrency, timeouts, cancellation, error handling, and observability
+loadWhen: "Debugging execution behavior or understanding the runtime model"
 ---
 
 This page covers everything that happens after you deploy -- how resources execute as managed processes, how failures surface to you, and what observability data you can access. For resource limits and quotas, see [Resource Limits & Quotas](limits.mdx).

package/reference/runtime/limits.mdx

@@ -1,6 +1,7 @@
 ---
 title: Resource Limits & Quotas
 description: Memory limits, execution timeouts, scale quotas, networking constraints, and v1 platform limitations for SDK resources
+loadWhen: "Hitting resource limits or planning for scale"
 ---
 
 This page documents the hard limits enforced on all SDK resources running on the Elevasis platform. These limits exist to ensure platform stability and fair resource usage across all organizations.

package/reference/security/credentials.mdx

@@ -0,0 +1,141 @@
+---
+title: "Credential Security"
+description: "Three-layer credential model: platform tools (server-side injection), http tool (arbitrary APIs), getCredential() (explicit opt-in raw access) -- .env scope and security boundaries"
+loadWhen: "Setting up integrations or configuring tool access"
+---
+
+This reference covers the Elevasis credential security model. Read it when helping a user connect to an external service, set up platform tools, or understand why environment variables are not used in workflows.
+
+---
+
+## The Core Rule
+
+Integration credentials are never stored in `.env` and never available via `process.env` inside worker threads.
+
+Credentials live in the platform credential system, created via the command center UI. Worker threads access credentials only through controlled channels: `platform.call()` (server-side injection) or `platform.getCredential()` (explicit opt-in).
+
+`.env` contains only `ELEVASIS_API_KEY`, used by the CLI for authentication. It is never uploaded to the platform and never injected into workers.
+
+---
+
+## Three-Layer Model
+
+### Layer 1: Platform Tools (Default)
+
+All platform tools resolve credentials server-side. The tool dispatcher in the API process looks up the credential by name, injects it into the service call, and returns only the result. Credential values never cross the postMessage boundary into the worker.
+
+```typescript
+// Credential 'my-gmail' is resolved server-side -- value never enters worker memory
+const result = await platform.call({
+  tool: 'gmail',
+  method: 'sendEmail',
+  credential: 'my-gmail',
+  params: { to: '...', subject: '...', body: '...' },
+})
+```
+
+This is the default pattern for all integrations that have a platform adapter (Gmail, Attio, Stripe, Resend, etc.).
+
+### Layer 2: HTTP Platform Tool
+
+For APIs without a dedicated platform adapter, use the `http` platform tool. Credentials are resolved and injected server-side before the outgoing HTTP request.
+
+```typescript
+const result = await platform.call({
+  tool: 'http',
+  method: 'request',
+  credential: 'my-custom-api',
+  params: {
+    url: 'https://api.example.com/v1/data',
+    method: 'GET',
+    headers: { 'Content-Type': 'application/json' },
+  },
+})
+// result = { status: 200, headers: {...}, body: {...} }
+```
+
+**Supported credential injection patterns:**
+
+| Pattern | Credential Config | How Injected |
+| --- | --- | --- |
+| Bearer token | `{ type: 'bearer', token: 'sk_...' }` | `Authorization: Bearer sk_...` header |
+| API key header | `{ type: 'api-key-header', header: 'X-API-Key', key: 'ak_...' }` | Custom header with key value |
+| Basic auth | `{ type: 'basic', username: '...', password: '...' }` | `Authorization: Basic base64(user:pass)` header |
+| Query parameter | `{ type: 'query-param', param: 'api_key', value: 'ak_...' }` | Appended to URL query string |
+| Body field | `{ type: 'body-field', field: 'apiKey', value: 'ak_...' }` | Merged into JSON request body |
+| Custom header | `{ type: 'custom-header', header: 'X-Custom', value: '...' }` | Arbitrary header with value |
+
+The credential type is selected when creating the credential in the command center UI.
+
+### Layer 3: getCredential() (Explicit Opt-In)
+
+For cases where a third-party SDK must be initialized with a raw key (e.g., `new Stripe(key)`), use `platform.getCredential()`. This is an explicit opt-in that causes the credential value to enter worker memory.
+
+```typescript
+import { platform } from '@elevasis/sdk/worker'
+
+// Explicit opt-in -- secret enters worker memory for duration of execution
+const cred = await platform.getCredential('my-stripe-key')
+const stripe = new Stripe(cred.credentials.secretKey)
+```
+
+`getCredential()` returns `{ provider: string, credentials: Record<string, string> }`. The fields in `credentials` depend on the credential type stored in the command center.
+
+**Security guardrails:**
+
+- All `getCredential()` calls are logged with credential name, deployment ID, and execution ID
+- Workers are ephemeral (destroyed after each execution) -- no credential persistence
+- Use `platform.call()` with the `http` tool instead when possible
+
+---
+
+## Credential Setup
+
+Credentials are created in the command center UI:
+
+1. Open the Elevasis command center
+2. Navigate to Credentials
+3. Click "Add Credential"
+4. Enter a name (e.g., `my-gmail`, `production-attio`, `custom-api`)
+5. Select the credential type (bearer, api-key-header, basic, etc.)
+6. Enter the secret values
+7. Save
+
+The credential name is what you pass as `credential: 'my-gmail'` in `platform.call()`.
+
+Credential names are case-sensitive. A mismatch causes a `PlatformToolError` with the message "credential not found."
+
+---
+
+## .env Scope
+
+`.env` in your workspace contains only:
+
+```
+ELEVASIS_API_KEY=sk_your_key_here
+```
+
+This key authenticates CLI operations (`elevasis deploy`, `elevasis check`, `elevasis exec`). It is never uploaded to the platform and never injected into workers.
+
+Do not put integration API keys in `.env`. They will not be available inside workflows.
+
+---
+
+## Choosing a Credential Pattern
+
+| Situation | Pattern |
+| --- | --- |
+| Using a supported platform tool (Gmail, Attio, Stripe, etc.) | `platform.call()` with the tool name |
+| Calling an API not in the tool catalog | `platform.call()` with `tool: 'http'` |
+| Third-party SDK that requires a raw key | `platform.getCredential()` |
+| CLI authentication | `ELEVASIS_API_KEY` in `.env` only |
+
+---
+
+## Migrating from elevasis env
+
+If you previously set integration credentials via `elevasis env set`, that command no longer exists. Use `elevasis env list` to see what was set, then recreate each entry as a platform credential in the command center. Update workflow code from `process.env.KEY` to `platform.call({ tool: 'http', credential: '...', ... })` or `platform.getCredential('...')`, then redeploy. The `.env` file remains but is scoped to `ELEVASIS_API_KEY` only.
+
+---
+
+**Last Updated:** 2026-02-26

package/reference/templates/data-enrichment.mdx

@@ -0,0 +1,162 @@
+---
+title: "Template: Data Enrichment"
+description: "LLM-powered enrichment of existing database records -- read rows, enrich each with an LLM, write results back to Supabase"
+loadWhen: "Applying the data-enrichment workflow template"
+---
+
+**Category:** Data Processing
+
+**Platform Tools:** `llm` (text generation), `supabase` (select and update)
+
+**Credentials Required:**
+
+- `my-database` -- Supabase project URL and service role key
+- LLM API keys are resolved server-side from platform configuration (no credential name needed)
+
+---
+
+## What This Workflow Does
+
+Fetches records from a Supabase table that need enrichment, sends each record to an LLM with a custom prompt, and writes the enriched field back to the table. Supports batching to process multiple records per execution. Suitable for enriching leads with AI-generated summaries, classifying records, extracting structured data from text fields, or scoring records.
+
+---
+
+## Input Schema
+
+```typescript
+z.object({
+  table: z.string(),              // Supabase table to enrich
+  filter: z.record(z.string()).optional(), // Filter rows to enrich (PostgREST format)
+  sourceField: z.string(),        // Field to send to the LLM as input
+  targetField: z.string(),        // Field to write enriched output to
+  prompt: z.string(),             // LLM prompt template (use {value} as placeholder)
+  limit: z.number().optional(),   // Max rows to process (default: 20)
+})
+```
+
+## Output Schema
+
+```typescript
+z.object({
+  processed: z.number(),          // Rows successfully enriched
+  skipped: z.number(),            // Rows skipped (missing source field, LLM error)
+  errors: z.array(z.string()),    // Error messages for skipped rows
+})
+```
+
+---
+
+## Workflow Code Pattern
+
+```typescript
+import type { WorkflowDefinition } from '@elevasis/sdk'
+import { platform } from '@elevasis/sdk/worker'
+import { z } from 'zod'
+
+const inputSchema = z.object({
+  table: z.string(),
+  filter: z.record(z.string()).optional(),
+  sourceField: z.string(),
+  targetField: z.string(),
+  prompt: z.string(),
+  limit: z.number().optional(),
+})
+const outputSchema = z.object({
+  processed: z.number(),
+  skipped: z.number(),
+  errors: z.array(z.string()),
+})
+
+type Input = z.infer<typeof inputSchema>
+
+export const dataEnrichment: WorkflowDefinition = {
+  config: {
+    resourceId: 'data-enrichment',
+    name: 'Data Enrichment',
+    type: 'workflow',
+    description: 'Enriches database records using an LLM',
+    version: '1.0.0',
+    status: 'dev',
+  },
+  contract: { inputSchema, outputSchema },
+  steps: {
+    enrich: {
+      id: 'enrich',
+      name: 'Enrich Records',
+      description: 'Fetch records, call LLM for each, write results back',
+      inputSchema,
+      outputSchema,
+      handler: async (input, context) => {
+        const { table, filter, sourceField, targetField, prompt, limit } = input as Input
+
+        // Fetch rows to enrich
+        const rows = await platform.call({
+          tool: 'supabase',
+          method: 'select',
+          credential: 'my-database',
+          params: { table, filter, limit: limit ?? 20 },
+        }) as Array<Record<string, unknown>>
+
+        let processed = 0
+        const errors: string[] = []
+
+        for (const row of rows) {
+          const sourceValue = row[sourceField]
+          if (!sourceValue || typeof sourceValue !== 'string') {
+            errors.push(`Row ${String(row.id)}: missing ${sourceField}`)
+            continue
+          }
+
+          try {
+            const enrichedPrompt = prompt.replace('{value}', sourceValue)
+            const result = await platform.call({
+              tool: 'llm',
+              method: 'generate',
+              params: {
+                provider: 'openai',
+                model: 'gpt-4o-mini',
+                messages: [{ role: 'user', content: enrichedPrompt }],
+              },
+            }) as string
+
+            await platform.call({
+              tool: 'supabase',
+              method: 'update',
+              credential: 'my-database',
+              params: {
+                table,
+                filter: { id: `eq.${String(row.id)}` },
+                data: { [targetField]: result },
+              },
+            })
+
+            context.logger.info('Enriched row', { id: row.id })
+            processed++
+          } catch (err) {
+            const msg = err instanceof Error ? err.message : String(err)
+            errors.push(`Row ${String(row.id)}: ${msg}`)
+          }
+        }
+
+        return { processed, skipped: errors.length, errors }
+      },
+      next: null,
+    },
+  },
+  entryPoint: 'enrich',
+}
+```
+
+---
+
+## Adaptation Notes
+
+- **Credential name:** Replace `'my-database'` with the user's database credential name.
+- **LLM provider and model:** Default uses `openai` / `gpt-4o-mini`. Adapt to the user's preference or available providers.
+- **Prompt template:** The `{value}` placeholder is replaced with the source field's value at runtime. Adapt the prompt for the user's specific enrichment task.
+- **Batch size:** Default limit is 20 rows. Increase for bulk processing, decrease for expensive LLM calls.
+- **Skill adaptation:** For beginners, explain what "enrichment" means and give concrete examples (adding a summary field, scoring, categorizing) before generating code.
+
+---
+
+**Last Updated:** 2026-02-26