Update to Mаke

{
  "name": "make-scenario-reference",
  "description": "Load when a Make scenario tool answers 403, refuses a write for a reason you cannot explain, or no tool seems to cover the request — the shared conventions of environment_get, scenario_*, app_find, module_spec, module_field_resolve and connection_*.",
  "included_files": [],
  "skill_md_contents": "---\nname: make-scenario-reference\ndescription: Load when a Make scenario tool answers 403, refuses a write for a reason you cannot explain, or no tool seems to cover the request — the shared conventions of environment_get, scenario_*, app_find, module_spec, module_field_resolve and connection_*.\nmetadata:\n  version: \"0.1.7\" # x-release-please-version\n---\n\n# Make scenario-management tools — reference\n\nThis is Make's scenario-management tool surface. The tool descriptions say what each tool does; this skill\nsays what they all assume. The companion skills carry the four rules a routine task needs; come here when a\ntool refuses something, answers 403, or a request seems to need a capability no tool covers — the answer is\noften \"this surface refuses that on purpose\".\n\n## Naming\n\nEvery tool is `{subject}_{action}`: `scenario_get`, `scenario_execution_inspect`, `module_spec`. Once you hold\na `scenarioId`, everything you can do with it starts with `scenario_`. A `_show` suffix is a UI twin that\nreturns byte-identical data and additionally renders a widget — use it only when the user asks to *see*\nsomething, never during multi-step work. Names and schemas are permanent; a breaking change ships as a new\ntool, which is why enums read slightly over-provisioned and output schemas are non-strict.\n\n## Scopes: all-or-nothing\n\nOne bundle of OAuth scopes gates the whole surface. A connection missing any of them is rejected with 403 on\nevery request. A 403 therefore never means \"this one tool needs more permission\" — it means the user has to\nreconnect the app and grant everything it asks for.\n\n## Read `content`, not only the structured data\n\nData rides in `structuredContent`. `content` is empty or a short remark that the data cannot say on its own —\na truncation, an ingestion lag, why a list is empty, \"the run is still executing\". **Treat every remark as an\ninstruction.** A remark that explains an absence also says to mention it only if the user seems to be missing\nsomething.\n\n## Two layers, two read tools, one write tool\n\n| layer | what it is | read | write |\n|---|---|---|---|\n| structure | modules, wiring, filters, trigger, schedule, declared inputs/outputs | `scenario_get` | `scenario_patch` structural operations |\n| configuration | one module's `config` (`parameters`, `mapper`, `data`, `flags`, `restore`, …) | `scenario_module_get` | `scenario_patch` `module_config_set`; `scenario_create` items |\n\n`scenario_get` is enough to explain what a scenario does. Call `scenario_module_get` only for the modules\nwhose values are the actual question — never for every module because the structural read omitted them. The\nsame restraint applies one level up: answer account-wide questions from `scenario_list`'s own fields and drill\ninto `scenario_get` for at most a few scenarios the user named or the list flagged.\n\n## The write model: one call, one save\n\n`scenario_create` and `scenario_patch` each make exactly one upstream write, after validating the whole\ncomposed result. There is no draft to stage a multi-step edit in, so **everything one change needs goes in one\ncall**. A refusal (`errors` array) is a free dry run — nothing was written, every problem came back at once;\nfix them all and resubmit. `scenario_patch` also refuses when the scenario changed since the `lastEdit` you\npassed: re-read and retry, never guess at what changed.\n\n## What the surface refuses to author, and how to say so\n\nA scenario can *use* things this surface cannot *create*; reads describe them, writes refuse them by name and\npoint at the Make editor. Relay the refusal as a boundary, not a bug to route around:\n\n- **Data stores and custom IML functions** — readable and debuggable, not creatable.\n- **Data structures (UDTs)** — reads work; creating one is not available.\n- **Incomplete-execution (DLQ) fix-and-retry** — Make's own UI is the path.\n- **The blueprint version a past run executed** — compare `scenario_get`'s `lastEdit` with the execution's\n  `startedAt` before blaming the current configuration for an old failure; nothing enforces this for you.\n- **Drafts/publish and connection re-authorization** — point at the editor.\n\nDo not extend the list by assumption: app-specific instant triggers, error handlers, agents and subscenarios\n*are* supported. When unsure, `module_spec` the module — it reports what the module needs, including whether a\nwebhook can be created for it.\n\n## State a guess before acting on it\n\nA relative date, \"the Sales channel\", a scenario named descriptively — when a write or a run would accept\nwhatever you resolve it to, say what you resolved it to *before* that call, not in the closing summary. Where a\nwrong guess is refused for free and the answer comes back (`module_field_resolve`, `scenario_run` naming the\ndeclared interface), resolving first and disclosing after is fine.\n\n## Lists are capped, never paged\n\n`scenario_list`, `scenario_execution_list` and option lists cap at 25 rows and take narrowing filters, not\noffsets. Ask a narrower question; do not try to page through hundreds of rows.\n\n## Vocabulary\n\nA team typed `\"private\"` is a **private space** — Make's term for a member's single-person workspace. \"My\npersonal account/team\" means that id; say \"private space\" back.\n\n## Companion skills\n\n- `make-scenario-explore` — orienting, listing, explaining an existing scenario, account-wide checks.\n- `make-scenario-building` — finding modules, connections, creating and editing scenarios.\n- `make-scenario-operations` — running, activating, and debugging runs and webhooks.\n- `make-api-shell` — a reusable API-call or HTTP scenario used as a retrieval transport into a SaaS account.\n"
}