|
| 1 | +--- |
| 2 | +description: Validate an existing Sim integration (tools, block, registry) against the service's API docs |
| 3 | +argument-hint: <service-name> [api-docs-url] |
| 4 | +--- |
| 5 | + |
| 6 | +# Validate Integration Skill |
| 7 | + |
| 8 | +You are an expert auditor for Sim integrations. Your job is to thoroughly validate that an existing integration is correct, complete, and follows all conventions. |
| 9 | + |
| 10 | +## Your Task |
| 11 | + |
| 12 | +When the user asks you to validate an integration: |
| 13 | +1. Read the service's API documentation (via WebFetch or Context7) |
| 14 | +2. Read every tool, the block, and registry entries |
| 15 | +3. Cross-reference everything against the API docs and Sim conventions |
| 16 | +4. Report all issues found, grouped by severity (critical, warning, suggestion) |
| 17 | +5. Fix all issues after reporting them |
| 18 | + |
| 19 | +## Step 1: Gather All Files |
| 20 | + |
| 21 | +Read every file for the integration: |
| 22 | + |
| 23 | +``` |
| 24 | +apps/sim/tools/{service}/ # All tool files, types.ts, index.ts |
| 25 | +apps/sim/blocks/blocks/{service}.ts # Block definition |
| 26 | +apps/sim/tools/registry.ts # Tool registry entries |
| 27 | +apps/sim/blocks/registry.ts # Block registry entry |
| 28 | +``` |
| 29 | + |
| 30 | +## Step 2: Pull API Documentation |
| 31 | + |
| 32 | +Fetch the official API docs for the service. This is the source of truth for: |
| 33 | +- Endpoint URLs, HTTP methods, and auth headers |
| 34 | +- Required vs optional parameters |
| 35 | +- Parameter types and allowed values |
| 36 | +- Response shapes and field names |
| 37 | +- Pagination patterns |
| 38 | + |
| 39 | +## Step 3: Validate Tools |
| 40 | + |
| 41 | +For **every** tool file, check: |
| 42 | + |
| 43 | +### Params |
| 44 | +- [ ] All required API params are marked `required: true` |
| 45 | +- [ ] All optional API params are marked `required: false` |
| 46 | +- [ ] Param types match the API (`'string'`, `'number'`, `'boolean'`, `'json'`) |
| 47 | +- [ ] Visibility is correct: |
| 48 | + - `'hidden'` for OAuth access tokens and system-injected params only |
| 49 | + - `'user-only'` for API keys, credentials, and account-specific IDs |
| 50 | + - `'user-or-llm'` for everything else (search queries, content, filters, etc.) |
| 51 | +- [ ] All tool IDs use `snake_case` (`{service}_{action}`) |
| 52 | + |
| 53 | +### Request |
| 54 | +- [ ] URL matches the API endpoint (correct base URL, path, path params) |
| 55 | +- [ ] HTTP method matches the API spec (GET, POST, PUT, PATCH, DELETE) |
| 56 | +- [ ] Headers include correct auth (Bearer token, API key header, etc.) |
| 57 | +- [ ] Body sends all required fields |
| 58 | +- [ ] Query params are passed correctly (for GET requests) |
| 59 | +- [ ] ID fields are `.trim()`-ed to prevent copy-paste whitespace errors |
| 60 | + |
| 61 | +### Response |
| 62 | +- [ ] `transformResponse` extracts the correct fields from the API response |
| 63 | +- [ ] All nullable fields use `?? null` |
| 64 | +- [ ] All optional arrays use `?? []` |
| 65 | +- [ ] Error cases are handled (check for `!data.data` or similar patterns) |
| 66 | +- [ ] Logger is imported and used for error logging |
| 67 | + |
| 68 | +### Outputs |
| 69 | +- [ ] All output fields match what the API actually returns |
| 70 | +- [ ] No fields are missing that the API provides and users would need |
| 71 | +- [ ] No phantom fields are defined that the API doesn't return |
| 72 | +- [ ] `optional: true` is set on fields that may not exist in all responses |
| 73 | +- [ ] `type: 'json'` outputs define `properties` when the shape is known |
| 74 | +- [ ] `type: 'array'` outputs define `items` with the item structure |
| 75 | + |
| 76 | +### Types |
| 77 | +- [ ] `types.ts` has interfaces for all param types |
| 78 | +- [ ] `types.ts` has interfaces for all response types (extending `ToolResponse`) |
| 79 | +- [ ] Optional params use `?` in the interface |
| 80 | +- [ ] Types match actual API field names |
| 81 | + |
| 82 | +### Registry |
| 83 | +- [ ] All tools are exported from `index.ts` |
| 84 | +- [ ] All tools are registered in `tools/registry.ts` with snake_case keys |
| 85 | +- [ ] Registry keys match tool IDs exactly |
| 86 | + |
| 87 | +## Step 4: Validate Block |
| 88 | + |
| 89 | +### SubBlocks |
| 90 | +- [ ] Operation dropdown lists all tool operations |
| 91 | +- [ ] Dropdown option IDs match tool IDs (if using `tool: (params) => params.operation` pattern) |
| 92 | +- [ ] Every required tool param has a corresponding subBlock input |
| 93 | +- [ ] Conditions are correct — each subBlock only shows for the operations that use it |
| 94 | +- [ ] Condition values use arrays when a field applies to multiple operations |
| 95 | +- [ ] Required fields are marked `required: true` (or conditional required) |
| 96 | +- [ ] OAuth/credential field has correct `serviceId` |
| 97 | +- [ ] `dependsOn` is set for fields that need other values (e.g., selectors depending on credential) |
| 98 | + |
| 99 | +### Advanced Mode |
| 100 | +- [ ] Optional, rarely-used fields are set to `mode: 'advanced'`: |
| 101 | + - Pagination tokens |
| 102 | + - Time range filters (start/end time) |
| 103 | + - Sort order / direction options |
| 104 | + - Max results / limits |
| 105 | + - Reply settings |
| 106 | + - Rarely used IDs |
| 107 | +- [ ] Required fields are NOT set to `mode: 'advanced'` |
| 108 | + |
| 109 | +### WandConfig |
| 110 | +- [ ] Timestamp fields have `wandConfig` with `generationType: 'timestamp'` |
| 111 | +- [ ] Complex inputs (filters, queries, comma-separated lists) have `wandConfig` with descriptive prompts |
| 112 | +- [ ] WandConfig prompts end with "Return ONLY the [format] - no explanations, no extra text." |
| 113 | + |
| 114 | +### Tools Config |
| 115 | +- [ ] `tools.access` lists every tool ID the block uses |
| 116 | +- [ ] `tools.config.tool` returns the correct tool ID for each operation |
| 117 | +- [ ] `tools.config.params` handles type coercions (Number(), Boolean(), JSON.parse()) — NOT in `tools.config.tool` |
| 118 | +- [ ] Empty string dropdown values are converted to `undefined` in params |
| 119 | + |
| 120 | +### Outputs |
| 121 | +- [ ] Block outputs cover the key fields returned by all tools |
| 122 | +- [ ] Output types are correct (`'string'`, `'number'`, `'boolean'`, `'json'`) |
| 123 | +- [ ] `type: 'json'` outputs describe inner fields in the description (or use nested definitions) |
| 124 | + |
| 125 | +### Block Metadata |
| 126 | +- [ ] `type` is snake_case |
| 127 | +- [ ] `name` is human-readable |
| 128 | +- [ ] `description` is a concise one-liner |
| 129 | +- [ ] `longDescription` provides detail for docs |
| 130 | +- [ ] `docsLink` points to correct docs URL |
| 131 | +- [ ] `category` is `'tools'` |
| 132 | +- [ ] `bgColor` matches the service's brand color |
| 133 | +- [ ] `icon` references the correct icon component |
| 134 | +- [ ] `authMode` is set correctly (OAuth or ApiKey) |
| 135 | +- [ ] Block is registered in `blocks/registry.ts` alphabetically |
| 136 | + |
| 137 | +## Step 5: Report and Fix |
| 138 | + |
| 139 | +### Report Format |
| 140 | + |
| 141 | +Group findings by severity: |
| 142 | + |
| 143 | +**Critical** (will cause runtime errors or incorrect behavior): |
| 144 | +- Wrong endpoint URL |
| 145 | +- Missing required params |
| 146 | +- Wrong HTTP method |
| 147 | +- Incorrect response field mapping |
| 148 | +- Missing error handling |
| 149 | + |
| 150 | +**Warning** (follows conventions incorrectly or has usability issues): |
| 151 | +- Optional field not set to `mode: 'advanced'` |
| 152 | +- Missing `wandConfig` on timestamp/complex fields |
| 153 | +- Wrong visibility on params |
| 154 | +- Missing `optional: true` on nullable outputs |
| 155 | +- Opaque `type: 'json'` without property descriptions |
| 156 | + |
| 157 | +**Suggestion** (minor improvements): |
| 158 | +- Better description text |
| 159 | +- Missing `.trim()` on ID fields |
| 160 | +- Inconsistent naming |
| 161 | + |
| 162 | +### Fix All Issues |
| 163 | + |
| 164 | +After reporting, fix every critical and warning issue. Apply suggestions where they don't add unnecessary complexity. |
| 165 | + |
| 166 | +## Checklist Summary |
| 167 | + |
| 168 | +- [ ] Read all tool files for the service |
| 169 | +- [ ] Pulled and read official API documentation |
| 170 | +- [ ] Validated every tool's params, request, response, and outputs against API docs |
| 171 | +- [ ] Validated block subBlocks, conditions, modes, and wandConfig |
| 172 | +- [ ] Validated tools.config mapping and type coercions |
| 173 | +- [ ] Validated registry entries |
| 174 | +- [ ] Reported all issues grouped by severity |
| 175 | +- [ ] Fixed all critical and warning issues |
| 176 | +- [ ] Ran `bun run lint` after fixes |
| 177 | +- [ ] Verified TypeScript compiles clean |
0 commit comments