About make-scenario-building
A skill for building and editing Make scenarios, guiding users and agents through design, module discovery, configuration, connections, and verification. It emphasizes resolving ambiguous choices before acting and keeping each scenario save or patch focused.
Key features
- 01Step-by-step scenario creation
- 02Module and field discovery
- 03Connection setup guidance
- 04Scenario editing with change checks
- 05Trigger-specific verification
Use cases
- 01Building a new Make automation scenario
- 02Adding modules to an existing scenario
- 03Configuring a webhook with unknown payload fields
Install
Copy the command and run it in a terminal.
npx skills add https:/ / github.com/ integromat/ make-skills --skill make-scenario-buildingAfter installing, type/make-scenario-buildingin Claude Code to confirm it loaded.
Bundled files
References and scripts installed along with SKILL.md.
examples/ai-agent-with-tool.jsonerror-handler.jsonif-else-merge.jsoniterator-aggregator.jsonon-demand-subscenario.jsonpolling-sheets-ai-update-row.jsonREADME.mdrouter-fanout.jsonwebhook-to-google-sheets.jsonreferences/ai-agents.mdapp-gotchas.mddata-stores.mderror-handling.mdflow-control.mdiml-functions.mdmapping.mdsubscenarios.mdDetails
From the project READMEMake scenarios — creating and editing
The tool descriptions carry each tool's rules; this skill carries the order of operations and the decisions the tools cannot make. A straight-line scenario needs nothing beyond the workflow below. Load a reference only when its trigger applies.
Ground rules. A 403 means the whole connection must be re-authorized with every permission — never one
tool. A content remark on a result is an instruction, not decoration. scenario_create/scenario_patch
make one save each: put everything one change needs in one call, and read a refused write's errors as a
free dry run. Say what you resolved an ambiguous value to ("the Sales channel", "next Monday") before the
call that acts on it. Details and the refusal contract: make-scenario-reference, when something is refused.
Build a new scenario
- Pin the design in words the user agrees with: every app by name (ask when they name a category — "email", "a form", "AI"), what starts it, what moves where, what happens to non-matching items.
environment_get→organizationId/teamId.app_findwith the user's words, once per goal. Given an instant and a polling trigger for the same source, say which you chose and why.module_specfor every planned module in one call,schemas: true— it gives each module's exactconfigshape and itsdynamicpaths.- Connections: reuse an id from
connection.existing; otherwise oneconnection_createfor every app, hand over the link,connection_getwhen the user says they are done. module_field_resolveeverydynamicpath independsOnorder, copyingvalueintoconfig. A polling trigger's start point is the/datapath — ask "existing items or from now?" before resolving it. (module_options_getis the same lookup keyed bymodule_spec'sdynamicFieldsand aconnectionId; use one or the other per field, not both.)- Compose the flat list: your ids, one
root: "main", everything elsefollowsorparent, oneconfigper module,filterfor a plain continue-or-stop gate. Google Sheets, Gmail, Make AI Tools or date math involved → App gotchas first. scenario_create,autoActivateoff unless asked. Fix everything inerrorsand resubmit; relaywarnings.- Verify, then
scenario_activate. On-demand:scenario_runwithinputs. Polling/scheduled: activate,scenario_run,scenario_execution_get. Webhook: the user sends one real request —scenario_rundoes not exercise a webhook. Then givehttps://<zone>.make.com/<teamId>/scenarios/<scenarioId>.
Edit an existing scenario
scenario_getfor structure andlastEdit;scenario_module_getonly for the modules you will change.- Adding modules:
app_findandmodule_spec(schemas: true)as above; resolvedynamicpaths against the module's currentconfig. - One
scenario_patchwithexpectedLastEditand every operation the change needs. Send only theconfigdomains you changed. Fix every{{<id>.field}}reference a removed or moved module leaves dangling in the same call. - A module added in a call gets its id on save, so wiring onto it is a second call with the returned
lastEdit. Verify from the response'smodulesecho.
A webhook whose payload is unknown
payloadShape: "learned" in module_spec, or a bare gateway:CustomWebHook: create with the trigger alone →
the user sends one real request (or scenario_trigger_learn first) → scenario_trigger_inspect →
scenario_patch the rest. Do not activate a webhook scenario whose fields nobody has seen.
Decisions the tools leave to you
- Filter vs if-else vs router. Skip non-matching items and nothing else →
filter. Non-matching items need their own action →builtin:BasicIfElse(+builtin:BasicMergeto rejoin). Several arms that may all fire →builtin:BasicRouter. - Do not over-build. No error handlers, aggregators or variables unless the design needs them.
References — load only on the trigger
| Trigger | Reference |
|---|---|
| Mapping a trigger's or on-demand input, a whole bundle or an array element; a mapped field came back empty | Mapping |
| A value must be transformed (dates, text, arrays, conditionals) | IML functions |
| More than a straight line: routers, if-else + merge, multi-condition filters, iterating, aggregating | Flow control |
| The scenario is on-demand, calls another scenario, or is called by one or by an agent | Subscenarios |
| Placing a Make AI Agent module with tools | AI agents |
| A run must remember earlier runs (dedup, counters), or a payload needs a fixed schema | Data stores |
| The user asks for retries or fallbacks, or failure/data loss is unacceptable — most scenarios need none | Error handling |
| Finalizing a Google Sheets, Gmail or Make AI Tools config, or a date expression | App gotchas |
A complete scenario_create call to pattern from | Examples |