$npx -y skills add prismatic-io/prismatic-skills --skill component-patternsArchitecture patterns, code generation guides, and reference documentation for building Prismatic custom components.
| 1 | # Component Patterns |
| 2 | |
| 3 | Reference documentation for building Prismatic custom components. |
| 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 | ### Connector Components |
| 19 | - Wrap external APIs (Salesforce, Canny, HubSpot, etc.) |
| 20 | - Support OAuth2, API Key, Bearer Token, Basic Auth |
| 21 | - Define connections, actions, triggers, and data sources |
| 22 | - Installed via Prism CLI |
| 23 | |
| 24 | ### Utility Components |
| 25 | - Provide helper actions (data transformation, formatting, etc.) |
| 26 | - No external connections needed |
| 27 | - Define only actions with typed inputs |
| 28 | |
| 29 | ## Config Mantra |
| 30 | |
| 31 | Components define their own inputs — not `configVar()` wrappers. Each action uses `input()` definitions directly: |
| 32 | - `input()` for typed action inputs (label, type, required, comments, default) |
| 33 | - `connection()` for auth field definitions (key, label, inputs) |
| 34 | - Use `util.types` for input type constants |
| 35 | - See `references/authentication-patterns.md` for connection field patterns |
| 36 | |
| 37 | ## Phase: Existing Component Check |
| 38 | |
| 39 | Before scaffolding any connector component, check whether Prismatic already ships one: |
| 40 | |
| 41 | ``` |
| 42 | https://github.com/prismatic-io/components/tree/main/components |
| 43 | ``` |
| 44 | |
| 45 | Browse or search (`repo:prismatic-io/components <service-name>`) to see if a subdirectory exists for the target service. If it does: |
| 46 | 1. Tell the user an official component exists and link to it |
| 47 | 2. Ask whether they want to build a custom variant anyway (e.g., extended actions, different auth) or stop here |
| 48 | 3. If proceeding, use the production component as a reference for auth patterns, action structure, and error handling — it reflects current SDK best practices |
| 49 | |
| 50 | This check only applies to connector components (those wrapping external APIs), not utility components. |
| 51 | |
| 52 | ## Phase: API Research |
| 53 | |
| 54 | When the `on_answer` trigger fires for `api_docs_url`, the agent spawns the `external-api-researcher` |
| 55 | agent with the URL. The researcher fetches and analyzes the API docs, producing a structured JSON |
| 56 | spec at `{session_dir}/api-research.json`. The component builder waits for results before proceeding. |
| 57 | |
| 58 | - See `references/api-research-guide.md` for the output format and research strategies |
| 59 | - Research results inform `auth_type`, `confirm_resources`, `webhook_support`, `base_url` |
| 60 | |
| 61 | ## Phase-Specific References |
| 62 | |
| 63 | Load only the references relevant to your current workflow phase. This keeps context focused and avoids attention budget waste. |
| 64 | |
| 65 | ### Phase 2: Requirements Gathering |
| 66 | - 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. |
| 67 | - `references/api-research-guide.md` - How to research external APIs (load when `api_docs_url` is answered) |
| 68 | |
| 69 | ### Phase 3: Scaffold |
| 70 | - `references/component-architecture.md` - Component directory structure |
| 71 | - `references/spectral-component-quickstart.md` - Spectral SDK basics |
| 72 | |
| 73 | ### Phase 4: Code Generation (PRIMARY PHASE) |
| 74 | See the `<spec-loading>` block in component-builder.md for progressive disclosure rules. |
| 75 | The references below are the full set available — load per the agent's guidance. |
| 76 | |
| 77 | - **Production components** (`https://github.com/prismatic-io/components/tree/main/components`) — When building a connector, browse the repo for a component that uses the same auth type or a similar API. These are production-grade and show current SDK idioms for client setup, error handling, pagination, and action structure. Fetch raw source with `https://raw.githubusercontent.com/prismatic-io/components/tree/main/components/<name>/src/index.ts`. |
| 78 | - `references/answer-to-code-cookbook.md` - **LOAD FIRST** — Maps component.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. |
| 79 | - `references/code-generation-guide.md` - File generation patterns and |