From make-skills
Configures Make.com scenario modules: parameters, connections, data mapping, webhooks, data stores, IML expressions, keys, and input/output structures. For practical module setup after scenario design.
npx claudepluginhub integromat/make-skills --plugin make-skillsThis skill uses the workspace's default tool permissions.
This skill covers configuring individual modules within a Make scenario. Once a scenario's module composition is decided (see **make-scenario-building**), each module must be configured: connections assigned, parameters filled, data mapped from upstream modules, and special components (webhooks, data stores, keys) wired up.
Implements Playwright E2E testing patterns: Page Object Model, test organization, configuration, reporters, artifacts, and CI/CD integration for stable suites.
Guides Next.js 16+ Turbopack for faster dev via incremental bundling, FS caching, and HMR; covers webpack comparison, bundle analysis, and production builds.
Discovers and evaluates Laravel packages via LaraPlugins.io MCP. Searches by keyword/feature, filters by health score, Laravel/PHP compatibility; fetches details, metrics, and version history.
This skill covers configuring individual modules within a Make scenario. Once a scenario's module composition is decided (see make-scenario-building), each module must be configured: connections assigned, parameters filled, data mapped from upstream modules, and special components (webhooks, data stores, keys) wired up.
Read the reference file that matches the current task:
| Task | Reference |
|---|---|
| Configuring any module (start here) | General Principles — 5-phase workflow: read interface, resolve components, run RPCs, fill params/mapper, validate |
| Setting up or assigning a connection | Connections — credential request flow, scope checking, Extract Blueprint Components |
| Creating or assigning a webhook | Webhooks — custom vs branded, data structure definition |
| Creating or assigning a data store | Data Stores — requires data structure first |
| Defining a data structure (schema) | Data Structures — field types, nested structures |
| Provisioning keys or certificates | Keys — SSH, PEM/PFX via credential requests |
| Writing IML expressions | IML Expressions — functions, variables, operators, backtick rule |
| Mapping data between modules | Mapping — module ID references, output schema discovery |
| Adding filter conditions | Filtering — operators, AND/OR grouping, placement rules |
| Configuring an aggregator | Aggregators — feeder/target, variants, configuration order exception |
| Configuring an AI agent module | AI Agents — tools array, AI-decided fields, restore metadata |
These apply to every module configuration. Violating any of them is the most common cause of broken scenarios.
Read the interface first. Call app-module_get with outputFormat: "instructions" before configuring any module. Never guess parameter names, types, or structures.
Validate every module. Call validate_module_configuration after assembling each module's config. Do not proceed if validation returns errors — no exceptions.
Component creation order. Data structures, then webhooks, then connections, then keys, then data stores (dependencies flow left to right). Connections and keys require credential requests (user completes auth); webhooks, data stores, and data structures can be created directly via MCP.
Configure left to right. Work upstream to downstream so output schemas are available for mapping. Exception: array aggregators need their target module configured first — see Aggregators.
Connection selection is interactive. Always present all matching connections to the user and let them choose. Never auto-select, even if only one match exists. See Connections.