Skip to content

Commit f976a4a

Browse files
Merge branch 'simstudioai:main' into main
2 parents 0ebc798 + 856182b commit f976a4a

205 files changed

Lines changed: 67294 additions & 1377 deletions

File tree

Some content is hidden

Large Commits have some content hidden by default. Use the searchbox below for content that may be hidden.

.agents/skills/validate-integration/SKILL.md

Lines changed: 4 additions & 5 deletions
Original file line numberDiff line numberDiff line change
@@ -102,8 +102,8 @@ For **every** tool file, check:
102102
- [ ] No fields are missing that the API provides and users would commonly need
103103
- [ ] No phantom fields defined that the API doesn't return
104104
- [ ] `optional: true` is set on fields that may not exist in all responses
105-
- [ ] When using `type: 'json'` and the shape is known, `properties` defines the inner fields
106-
- [ ] When using `type: 'array'`, `items` defines the item structure with `properties`
105+
- [ ] When using `type: 'json'` and the shape is known, `properties` defines the inner fields (tool outputs only — block outputs do not support `properties`)
106+
- [ ] When using `type: 'array'`, `items` defines the item structure with `properties` (tool outputs only)
107107
- [ ] Field descriptions are accurate and helpful
108108

109109
### Types (types.ts)
@@ -190,9 +190,8 @@ For **each tool** in `tools.access`:
190190
### Block Outputs
191191
- [ ] Outputs cover the key fields returned by ALL tools (not just one operation)
192192
- [ ] Output types are correct (`'string'`, `'number'`, `'boolean'`, `'json'`)
193-
- [ ] `type: 'json'` outputs either:
194-
- Describe inner fields in the description string (GOOD): `'User profile (id, name, username, bio)'`
195-
- Use nested output definitions (BEST): `{ id: { type: 'string' }, name: { type: 'string' } }`
193+
- [ ] `type: 'json'` outputs describe inner fields in the description string: `'User profile (id, name, username, bio)'` or `'[{address, status, type}]'` for arrays
194+
- [ ] **Do NOT add a `properties: {...}` field on block outputs.** Block-level `OutputFieldDefinition` (from `@sim/workflow-types/blocks`) only accepts `{ type, description?, condition?, hiddenFromDisplay? }`. Nested `properties` is a tool-level construct (`OutputProperty`) — adding it to a block output will fail TypeScript at build time
196195
- [ ] No opaque `type: 'json'` with vague descriptions like `'Response data'`
197196
- [ ] Outputs that only appear for certain operations use `condition` if supported, or document which operations return them
198197

.claude/commands/add-enrichment.md

Lines changed: 142 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,142 @@
1+
---
2+
description: Add a code-defined table enrichment (registry entry) backed by a provider cascade, ensuring each provider tool has hosted-key support
3+
argument-hint: <enrichment-name>
4+
---
5+
6+
# Adding a Table Enrichment
7+
8+
Enrichments are code-defined entries in `apps/sim/enrichments/` that run **directly per table row** (no workflow). Each enrichment declares inputs, outputs, and an ordered list of **providers**; the cascade runner tries providers in order and the first non-empty result fills the cell. Each provider calls one existing Sim tool via `executeTool`, which injects the workspace's BYOK key or a **hosted key** and bills usage automatically.
9+
10+
Because enrichments run on Sim's hosted keys by default, **every provider tool you reference must have hosted-key support** — otherwise it can only run when the workspace brings its own key. This command makes that check a required step.
11+
12+
## Overview
13+
14+
| Step | What | Where |
15+
|------|------|-------|
16+
| 1 | Pick the data-source tool(s) for each output | `tools/{service}/` + `tools/registry.ts` |
17+
| 2 | **Verify each tool has `hosting`; if not, run `/add-hosted-key`** | `tools/{service}/{action}.ts` |
18+
| 3 | Write the enrichment definition | `enrichments/{name}/{name}.ts` + `index.ts` |
19+
| 4 | Register it | `enrichments/registry.ts` |
20+
| 5 | Verify | tsc / biome / manual run |
21+
22+
## Architecture (what you're plugging into)
23+
24+
- **`enrichments/types.ts`**`EnrichmentConfig { id, name, description, icon, inputs, outputs, providers }` and `EnrichmentProvider { id, label, toolId, buildParams, mapOutput }`. Providers are **plain data** (no `@/tools` import) so the catalog stays client-safe.
25+
- **`enrichments/providers.ts`**`toolProvider(...)` (typed passthrough) plus shared input helpers: `str(v)`, `normalizeDomain(v)`, `firstNonEmpty(arr)`, `splitName(fullName)`.
26+
- **`enrichments/run.ts`** — the server-only cascade runner. Calls `executeTool(provider.toolId, { ...params, _context: { workspaceId } })`, accumulates hosted-key cost, returns the first non-empty mapped result. **You do not edit this** — it works for any registry entry.
27+
- **`enrichments/registry.ts`**`ENRICHMENT_REGISTRY` / `ALL_ENRICHMENTS` / `getEnrichment`. Register new entries here.
28+
29+
Outputs automatically become table columns; billing, the catalog/sidebar UI, the column meta-header icon, and per-row execution all work with no extra wiring.
30+
31+
## Step 1: Pick the data-source tool(s)
32+
33+
For each output the enrichment produces, decide which existing tool provides it. Look up the service's API and the tool in `apps/sim/tools/{service}/` (e.g. `hunter_email_finder`, `pdl_person_enrich`, `pdl_company_enrich`). Confirm:
34+
35+
- The tool id is registered in `apps/sim/tools/registry.ts`.
36+
- Its `params` accept what you can derive from table columns (read the tool's `params`).
37+
- Its `outputs` / `transformResponse` actually expose the field you need (read the real output shape — don't assume).
38+
39+
Order providers **cheapest / most-likely-to-hit first**; the cascade stops at the first non-empty result. Apollo / LinkedIn are not hosted-safe (ToS) — don't use them.
40+
41+
## Step 2: Verify hosted-key support — chain to `/add-hosted-key` if missing
42+
43+
**This is the required gate.** For every tool a provider calls, open `apps/sim/tools/{service}/{action}.ts` and check for a `hosting` block:
44+
45+
```typescript
46+
hosting: {
47+
envKeyPrefix: 'SERVICE_API_KEY',
48+
apiKeyParam: 'apiKey',
49+
byokProviderId: 'service',
50+
pricing: { /* ... */ },
51+
rateLimit: { /* ... */ },
52+
}
53+
```
54+
55+
- **If `hosting` is present** — good. Note the `envKeyPrefix`; the deployment needs `{PREFIX}_COUNT` + `{PREFIX}_1..N` env vars set for the hosted key to actually resolve at runtime (ops concern, not code). If those env vars aren't set in the target environment, the provider will only run with a workspace BYOK key.
56+
- **If `hosting` is absent** — the tool can't use a Sim-provided key, so the enrichment would silently produce blank cells on hosted Sim. **Stop and run `/add-hosted-key <service>`** to add hosted-key support to that tool first, then come back. Do this for every provider tool that lacks it.
57+
58+
Why it matters: the cascade runner only bills (and only reads `output.cost.total`) when `executeTool` injected a hosted key, which requires the tool's `hosting` config. No `hosting` → no hosted key → the enrichment depends entirely on per-workspace BYOK.
59+
60+
## Step 3: Write the enrichment definition
61+
62+
Create `apps/sim/enrichments/{name}/{name}.ts` and a barrel `index.ts`. Mirror the existing entries (`work-email`, `phone-number`, `company-domain`, `company-info`).
63+
64+
```typescript
65+
import { SomeIcon } from 'lucide-react'
66+
import { filterUndefined } from '@sim/utils/object'
67+
import { normalizeDomain, splitName, str, toolProvider } from '@/enrichments/providers'
68+
import type { EnrichmentConfig } from '@/enrichments/types'
69+
70+
export const myEnrichment: EnrichmentConfig = {
71+
id: 'my-enrichment',
72+
name: 'My Enrichment',
73+
description: 'One concise sentence describing what it finds.',
74+
icon: SomeIcon,
75+
inputs: [
76+
// Person enrichments take a single canonical `fullName` (Clay-style);
77+
// split it with splitName() for tools that need first/last.
78+
{ id: 'fullName', name: 'Full name', type: 'string', required: true },
79+
{ id: 'companyDomain', name: 'Company domain', type: 'string' },
80+
],
81+
outputs: [{ id: 'value', name: 'value', type: 'string' }],
82+
providers: [
83+
toolProvider({
84+
id: 'provider-a',
85+
label: 'Provider A',
86+
toolId: 'service_action', // must have `hosting` (Step 2)
87+
buildParams: (inputs) => {
88+
// Return null when there aren't enough inputs → cascade skips this provider.
89+
const name = splitName(inputs.fullName)
90+
const domain = normalizeDomain(inputs.companyDomain)
91+
if (!name || !domain) return null
92+
return { domain, first_name: name.firstName, last_name: name.lastName }
93+
},
94+
mapOutput: (output) => {
95+
// Return { [outputId]: value } on a hit, or null to fall through.
96+
const value = str(output.value)
97+
return value ? { value } : null
98+
},
99+
}),
100+
// ...additional fallback providers, in priority order.
101+
],
102+
}
103+
```
104+
105+
```typescript
106+
// apps/sim/enrichments/{name}/index.ts
107+
export { myEnrichment } from './my-enrichment'
108+
```
109+
110+
Rules:
111+
- Keep the file **client-safe**: import only `lucide-react`, `@sim/utils/*`, `@/enrichments/providers`, and the types. **Never import `@/tools`** here — the runner does the tool call.
112+
- `buildParams` returns `null` when inputs are insufficient (provider skipped). `mapOutput` returns `null`/empty for a miss (falls through). Use `filterUndefined` when assembling optional tool params; coerce numbers explicitly (don't pass `''` to number outputs).
113+
- Output `id`s are the keys `mapOutput` returns; output `name`s are the default column names (the user can rename them in the config).
114+
115+
## Step 4: Register it
116+
117+
In `apps/sim/enrichments/registry.ts`, import and add the entry (catalog order is registration order):
118+
119+
```typescript
120+
import { myEnrichment } from '@/enrichments/my-enrichment'
121+
122+
export const ENRICHMENT_REGISTRY: EnrichmentRegistry = {
123+
// ...existing
124+
[myEnrichment.id]: myEnrichment,
125+
}
126+
```
127+
128+
## Step 5: Verify
129+
130+
1. `bunx tsc --noEmit` (from `apps/sim`, `NODE_OPTIONS=--max-old-space-size=8192`) and `bunx biome check` on the changed files.
131+
2. In a table → **+ New column → Enrichments** → pick the new enrichment, map its inputs to columns, name the output column(s), Save. Confirm it appears in the catalog with its icon/description.
132+
3. With hosted keys (or a workspace BYOK key) configured for each provider's service, run a row and confirm the cell fills; the dev-server log shows `Enrichment hit { provider }`. A row whose providers all miss completes blank; a row where every provider errored shows an error cell.
133+
134+
## Checklist
135+
136+
- [ ] Each output mapped to a real tool field (verified against the tool's `params`/`outputs`)
137+
- [ ] **Every provider tool has a `hosting` block — ran `/add-hosted-key` for any that didn't**
138+
- [ ] Providers ordered cheapest / most-likely-first; Apollo/LinkedIn not used
139+
- [ ] Enrichment file is client-safe (no `@/tools` import); uses `toolProvider` + shared helpers
140+
- [ ] `buildParams` returns `null` on insufficient inputs; `mapOutput` returns `null` on a miss
141+
- [ ] Registered in `enrichments/registry.ts`
142+
- [ ] tsc + biome clean; created and ran the column end-to-end

.claude/commands/validate-integration.md

Lines changed: 4 additions & 5 deletions
Original file line numberDiff line numberDiff line change
@@ -87,8 +87,8 @@ For **every** tool file, check:
8787
- [ ] No fields are missing that the API provides and users would commonly need
8888
- [ ] No phantom fields defined that the API doesn't return
8989
- [ ] `optional: true` is set on fields that may not exist in all responses
90-
- [ ] When using `type: 'json'` and the shape is known, `properties` defines the inner fields
91-
- [ ] When using `type: 'array'`, `items` defines the item structure with `properties`
90+
- [ ] When using `type: 'json'` and the shape is known, `properties` defines the inner fields (tool outputs only — block outputs do not support `properties`)
91+
- [ ] When using `type: 'array'`, `items` defines the item structure with `properties` (tool outputs only)
9292
- [ ] Field descriptions are accurate and helpful
9393

9494
### Types (types.ts)
@@ -175,9 +175,8 @@ For **each tool** in `tools.access`:
175175
### Block Outputs
176176
- [ ] Outputs cover the key fields returned by ALL tools (not just one operation)
177177
- [ ] Output types are correct (`'string'`, `'number'`, `'boolean'`, `'json'`)
178-
- [ ] `type: 'json'` outputs either:
179-
- Describe inner fields in the description string (GOOD): `'User profile (id, name, username, bio)'`
180-
- Use nested output definitions (BEST): `{ id: { type: 'string' }, name: { type: 'string' } }`
178+
- [ ] `type: 'json'` outputs describe inner fields in the description string: `'User profile (id, name, username, bio)'` or `'[{address, status, type}]'` for arrays
179+
- [ ] **Do NOT add a `properties: {...}` field on block outputs.** Block-level `OutputFieldDefinition` (from `@sim/workflow-types/blocks`) only accepts `{ type, description?, condition?, hiddenFromDisplay? }`. Nested `properties` is a tool-level construct (`OutputProperty`) — adding it to a block output will fail TypeScript at build time
181180
- [ ] No opaque `type: 'json'` with vague descriptions like `'Response data'`
182181
- [ ] Outputs that only appear for certain operations use `condition` if supported, or document which operations return them
183182

.cursor/commands/validate-integration.md

Lines changed: 4 additions & 5 deletions
Original file line numberDiff line numberDiff line change
@@ -82,8 +82,8 @@ For **every** tool file, check:
8282
- [ ] No fields are missing that the API provides and users would commonly need
8383
- [ ] No phantom fields defined that the API doesn't return
8484
- [ ] `optional: true` is set on fields that may not exist in all responses
85-
- [ ] When using `type: 'json'` and the shape is known, `properties` defines the inner fields
86-
- [ ] When using `type: 'array'`, `items` defines the item structure with `properties`
85+
- [ ] When using `type: 'json'` and the shape is known, `properties` defines the inner fields (tool outputs only — block outputs do not support `properties`)
86+
- [ ] When using `type: 'array'`, `items` defines the item structure with `properties` (tool outputs only)
8787
- [ ] Field descriptions are accurate and helpful
8888

8989
### Types (types.ts)
@@ -170,9 +170,8 @@ For **each tool** in `tools.access`:
170170
### Block Outputs
171171
- [ ] Outputs cover the key fields returned by ALL tools (not just one operation)
172172
- [ ] Output types are correct (`'string'`, `'number'`, `'boolean'`, `'json'`)
173-
- [ ] `type: 'json'` outputs either:
174-
- Describe inner fields in the description string (GOOD): `'User profile (id, name, username, bio)'`
175-
- Use nested output definitions (BEST): `{ id: { type: 'string' }, name: { type: 'string' } }`
173+
- [ ] `type: 'json'` outputs describe inner fields in the description string: `'User profile (id, name, username, bio)'` or `'[{address, status, type}]'` for arrays
174+
- [ ] **Do NOT add a `properties: {...}` field on block outputs.** Block-level `OutputFieldDefinition` (from `@sim/workflow-types/blocks`) only accepts `{ type, description?, condition?, hiddenFromDisplay? }`. Nested `properties` is a tool-level construct (`OutputProperty`) — adding it to a block output will fail TypeScript at build time
176175
- [ ] No opaque `type: 'json'` with vague descriptions like `'Response data'`
177176
- [ ] Outputs that only appear for certain operations use `condition` if supported, or document which operations return them
178177

apps/docs/components/icons.tsx

Lines changed: 12 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -415,6 +415,18 @@ export function MailIcon(props: SVGProps<SVGSVGElement>) {
415415
)
416416
}
417417

418+
export function InstantlyIcon(props: SVGProps<SVGSVGElement>) {
419+
return (
420+
<svg {...props} viewBox='0 0 766.8 766.8' xmlns='http://www.w3.org/2000/svg'>
421+
<circle cx='383.4' cy='383.4' r='383.4' fill='#0081ff' />
422+
<path
423+
d='M276.12 438.81h-101.8c-3.58 0-5.83-3.87-4.05-6.98l163.07-284.97h238.63c3.87 0 6.06 4.44 3.69 7.51L459.07 305.59c-2.36 3.07-.18 7.51 3.69 7.51h124.51c4.2 0 6.26 5.11 3.23 8.02L235.8 662.51c-3.37 3.24-8.88.06-7.76-4.48l52.61-213.45c.72-2.93-1.5-5.77-4.53-5.77z'
424+
fill='#fff'
425+
/>
426+
</svg>
427+
)
428+
}
429+
418430
export function EmailBisonIcon(props: SVGProps<SVGSVGElement>) {
419431
return (
420432
<svg {...props} viewBox='-66 -2 88 64' fill='none' xmlns='http://www.w3.org/2000/svg'>

apps/docs/components/ui/icon-mapping.ts

Lines changed: 2 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -99,6 +99,7 @@ import {
9999
ImageIcon,
100100
IncidentioIcon,
101101
InfisicalIcon,
102+
InstantlyIcon,
102103
IntercomIcon,
103104
JinaAIIcon,
104105
JiraIcon,
@@ -319,6 +320,7 @@ export const blockTypeToIconMap: Record<string, IconComponent> = {
319320
imap: MailServerIcon,
320321
incidentio: IncidentioIcon,
321322
infisical: InfisicalIcon,
323+
instantly: InstantlyIcon,
322324
intercom: IntercomIcon,
323325
intercom_v2: IntercomIcon,
324326
jina: JinaAIIcon,

0 commit comments

Comments
 (0)