$npx -y skills add prismatic-io/prismatic-skills --skill integration-patternsArchitecture patterns, manifest usage, code generation guides, and reference documentation for building Prismatic Code Native Integrations.
| 1 | # Integration Patterns |
| 2 | |
| 3 | Reference documentation for building Prismatic Code Native Integrations (CNI). |
| 4 | |
| 5 | <disallowed-tools> |
| 6 | Do NOT use these MCP tools — they return incomplete data that causes broken scaffolds and missing connections downstream. A hook will deny them, but avoid the wasted round trip. |
| 7 | |
| 8 | - `mcp__prism__prism_components_list` — Use `run.ts find-components <keyword>` instead |
| 9 | - `mcp__prism__prism_components_init` — Use `run.ts scaffold-component` instead |
| 10 | - `mcp__prism__prism_components_publish` — Use `run.ts publish-component` instead |
| 11 | - `mcp__prism__prism_components_generate_manifest` — Manifests are auto-generated during scaffolding |
| 12 | - `mcp__prism__prism_install_component_manifest` — Handled by `run.ts scaffold-project --components` |
| 13 | - `mcp__prism__prism_install_legacy_component_manifest` — Handled by `run.ts scaffold-project --components` |
| 14 | </disallowed-tools> |
| 15 | |
| 16 | ## Architecture Patterns |
| 17 | |
| 18 | ### Standard Integration Pattern |
| 19 | - Components accessed via manifests and componentRegistry |
| 20 | - Standard connection configuration |
| 21 | - Any component/manifest combination |
| 22 | |
| 23 | ## Component Manifest Pattern |
| 24 | |
| 25 | All components are accessed via manifests: |
| 26 | 1. Install: `prismatic-tools install-manifest <component-key>` |
| 27 | 2. Register in componentRegistry.ts with `componentManifests()` |
| 28 | 3. Import actions and call `.perform()`: `import slackActions from "./manifests/slack/actions"; await slackActions.postMessage.perform({...})` |
| 29 | - See `references/manifest-pattern.md` |
| 30 | |
| 31 | ## Config Mantra |
| 32 | |
| 33 | Every config element MUST use wrapper functions: |
| 34 | - `configVar()` for simple values |
| 35 | - `connectionConfigVar()` for connections |
| 36 | - `dataSourceConfigVar()` for data sources |
| 37 | - See `references/cni-examples/config-patterns-correct-vs-incorrect.md` |
| 38 | |
| 39 | ## Phase: Inline API Research |
| 40 | |
| 41 | When the DAG emits `status: "inline_task"` for API research, perform the research directly (no sub-agent). Key strategies: |
| 42 | |
| 43 | - **Start broad**: First WebFetch fetches the entry-point URL with a comprehensive prompt extracting auth, base URL, endpoints, webhooks, and rate limits in one pass |
| 44 | - **Anchor deduplication**: Many APIs publish all docs on a single page with `#anchor` links. Strip fragments before fetching — `https://docs.example.com/api#posts` is the same page as `https://docs.example.com/api` |
| 45 | - **Follow-up fetches**: Only for genuinely different URL paths (e.g., `/api/authentication` vs `/api`) |
| 46 | - **Max 10 WebFetch calls**: If docs are insufficient after 10 fetches, note gaps and move on |
| 47 | - **Official docs only**: Stay on the documentation domain. No third-party sources (Zapier, Make, Stack Overflow) |
| 48 | - **Auth priority**: OAuth2 > API Key > Bearer Token > Basic Auth |
| 49 | - **Output format**: Structured JSON with `authentication`, `baseUrl`, `resources`, `webhooks`, `rateLimiting` |
| 50 | - See `references/cni-examples/component-auth-patterns.md` for connection setup patterns |
| 51 | |
| 52 | ## Phase-Specific References |
| 53 | |
| 54 | Load only the references relevant to your current workflow phase. This keeps context focused and avoids attention budget waste. |
| 55 | |
| 56 | ### All Phases: Voice & Narration |
| 57 | - `references/narration-guide.md` - Orby's voice, personality traits, explanation depth rules, and phase milestone templates. Load at session start. |
| 58 | |
| 59 | ### Phase 2: Requirements Gathering |
| 60 | - Spec items carry `agent_context` (narration backbone), `implications` (per-option consequence maps), and `docs` (Prismatic doc URLs). The agent uses these inline — no external references needed for most questions. Docs are fetched on demand only when agent_context is insufficient or the user asks a follow-up beyond what the curated content covers. |
| 61 | |
| 62 | ### Phase 3: Credential Collection |
| 63 | - `references/auth-setup.md` - Authentication setup |
| 64 | |
| 65 | ### Phase 4: Scaffold |
| 66 | - `references/manifest-pattern.md` - Component manifest usage patterns |
| 67 | - `references/spectral-quickstart.md` - Spectral SDK basics |
| 68 | - `references/spectral-types.md` - **SDK type reference** — authoritative source for flow, errorConfig, retryConfig, queueConfig, configVar types. When the YAML spec and these types disagree, the types win. |
| 69 | |
| 70 | ### Phase 5: Code Generation (PRIMARY PHASE) |
| 71 | See the `<spec-loading>` block in cni-builder.md for progressive disclosure rules. |
| 72 | The references below are the full set available — load per the agent's guidance. |
| 73 | |
| 74 | - `references/answer-to-code-cookbook.md` - **LOAD FIRST** — Maps integration.yaml answers directly to TypeScript code snippets. Spec items with `cookbook_section` fields point to specific headings in this file — Grep for those headings to find exact patterns, especially after context compaction. |
| 75 | - `references/spectral-types.md` - **SDK type reference** — validate generated code against actual types |
| 76 | - `references/code-generation-guide.md` - File generation patterns and context object |
| 77 | - `references/code-anti-patterns.md` - **Common mistakes** — w |