`) goes in `` 2. `assets/engine/react.production.min.js`, wrapped in `` 3. `assets/engine/react-dom.production.min.js`, wrapped in `` 4. A config script — `` — built for the request, or `assets/samples/sample-config.js`'s content verbatim for a quick demo 5. `assets/engine/record-workspace.js`, wrapped in `` (must come after #4, since it reads the config global at load time) Full config shape, field types (including `lookup` and its cross-object navigation), `statusField`, `summaryRollups`, `relatedLists`, `sfWrite`, and `recordLinkField` are documented in [`references/field-schema-guide.md`](references/field-schema-guide.md) — read it before hand-writing a config rather than guessing the shape from the sample. **Assembly gotcha (learned the hard way):** if you're concatenating these pieces with shell commands, prefer a single Python (or similar) script that reads and writes files directly. Chaining many `echo`/`printf`/`cat` calls into one shell redirect has silently truncated output mid-write in practice, producing a file that looks fine by size at a glance but is missing its closing tags and simply renders blank. Always sanity-check the assembled file afterward: script tag counts should be balanced, and it should end with ``. ## 2. Multi-object / cross-object navigation, and related lists A `fieldSchema` entry with `type: 'lookup'` and a `refObject` naming another key in `objects` reads as a foreign id and renders as an in-workspace navigation link — in both the list-view table and the record view. Following it is a pure client-side nav-stack push, never a page load or `` — the record you land on can itself have lookups back the other way, and a dedicated Back control (top-left, always pure React state) steps back one hop at a time. This is independent of, and always alongside, the per-record "Open in Salesforce" deep link (`recordLinkField`) — one navigates within the artifact, the other always leaves it. **Related lists (360-style views) are automatic.** The engine scans every object's `fieldSchema` for `lookup` fields and, for whichever object each one points at, wires a related-list section back onto that target object's record view automatically -- e.g. if `Opportunity`, `Contact`, `Asset`, and `Activity` all have a `lookup` field pointing at `Account`, `Account`'s record view gets all four as related-list tabs with zero extra config. Every record view shows a Details/Related tab bar (styled like native Lightning record pages); Related only appears when something resolves. You can still set an explicit `relatedLists` array on an object to override labels/columns or add a relationship the data doesn't literally model as `type: 'lookup'`. See `field-schema-guide.md` for the exact shape of both `lookup` fields and explicit `relatedLists` entries. ## 3. Live data: reads and writes This skill's engine can operate on real records directly, with no separate capability-granting step needed beyond what's described here. **Reads:** populate the config's `records` arrays with real Salesforce data (e.g. from a `soqlQuery` tool call made before assembling the artifact) rather than placeholders. **Writes:** set `sfWrite: { sobjectType: 'Opportunity' }` on an object and a top-level `sfMcpUrl` (the user's connected Salesforce MCP server URL) on the workspace config, and every editable field on that object writes through to the live record automatically — no per-field whitelist required. Each field's real Salesforce API name comes from its own `apiName` (falls back to the field's `key` if omitted), so the simplest setup uses real API names as config keys directly. `lookup`-type fields and any field marked `noWrite: true` are excluded automatically. Full details, including how to exclude fields and how id/`idField` must be a real Salesforce Id (not a synthetic local key) for `sfWrite`-enabled objects, are in `field-schema-guide.md`. Mechanically, this works by having the published artifact call the Anthropic Messages API (`https://api.anthropic.com/v1/messages`) directly from inside the browser, passing the user's connected Salesforce MCP server via `mcp_servers`, and instructing that inline call to invoke `updateSobjectRecordTool`. See `references/wiring-live-mcp-data.md` for the exact request shape. Every write shows an **in-app confirm modal** before anything is sent — naming the exact field, new value, and (for bulk edits) record count. This is a real component (`ConfirmModal` in `record-workspace.js`), not `window.confirm()`/`window.alert()` — native browser dialogs are unreliable inside a sandboxed artifact iframe (often silently blocked, reading as an instant "cancel"), so don't reintroduce them if you're extending this.