Update to Mаke

{
  "name": "make-scenario-explore",
  "description": "Use when orienting in a Make account — listing organizations, teams and scenarios, explaining what an existing scenario does, checking connection health, auditing several scenarios. Not for creating, editing, running or debugging.",
  "included_files": [],
  "skill_md_contents": "---\nname: make-scenario-explore\ndescription: Use when orienting in a Make account — listing organizations, teams and scenarios, explaining what an existing scenario does, checking connection health, auditing several scenarios. Not for creating, editing, running or debugging.\nmetadata:\n  version: \"0.1.7\" # x-release-please-version\n---\n\n# Make scenarios — orienting and explaining\n\nThe read-only path from \"what does this account have\" to \"explain this scenario\" — the entry point of almost\nevery conversation, and the tool of choice for a non-technical question about an automation.\n\n**Ground rules.** A 403 means the whole connection must be re-authorized with every permission — never one\ntool. A `content` remark on a result is an instruction, not decoration. Say what you resolved an ambiguous\nvalue to before the call that acts on it. The refusal contract and the rest: `make-scenario-reference`, when\nsomething is refused or no tool seems to fit.\n\n## Start with `environment_get`\n\nAlways first, no arguments: every organization and team the connection reaches, including private spaces,\nand the `zone` needed for `https://<zone>.make.com/<teamId>/scenarios/<id>` links. An organization-bound\nconnection sees one organization and a remark counts the rest — mention that only if the user expects\nsomething that is not there.\n\n## Finding a scenario\n\n`scenario_list` returns at most 25, most recently edited first. Omitting `status` returns every status — it\nis not a hidden \"active only\" filter. Its `trigger` is coarse (`instant`/`scheduled`/`on-demand`); the\nwebhook-vs-polling distinction lives in `scenario_get`. Narrow by name, folder or status rather than paging.\n`scenario_folder_list` only when the user refers to a folder. `scenario_list_show` only when they ask to see\nthe list rendered.\n\n## Explaining one scenario\n\n`scenario_get` is **enough by itself**: every module in flow order, nesting via `parent` (router arms,\nif-else branches, error handlers, agent tools), filters, trigger and schedule, connection health, declared\ninputs and outputs. It omits each module's `config` on purpose — do not read that as incomplete, and do not\nfan `scenario_module_get` across every module. Call `scenario_module_get` (with `config: true`) only when a\nspecific value is the question: which spreadsheet, what the message says, how a field is computed.\n\nHow to read a few fields for a non-technical user:\n\n- **`trigger.kind`** decides what \"make it run\" means: `webhook` → give a URL to post to; `polling` /\n  `scheduled` → it runs on its schedule; `on-demand` → run it directly, the only kind that returns outputs.\n- **`connections[].status: \"missing\"`** covers both deleted and broken — the fix is the same, reconnect the\n  app in Make — and it is the most common reason a scenario \"stopped working\". No other tool surfaces it.\n- **`isWaitingOnIncompleteExecutions`** means the scenario runs sequentially and is frozen behind stored\n  failed runs: no new data flows until those are resolved in Make (this surface cannot). Different from a\n  non-zero `incompleteExecutions` alone, which is informational on a non-sequential scenario.\n- **`status: \"error\"`** carries no reason — Make records none. The cause is in the run history\n  (`make-scenario-operations`), never in a guess.\n- **`modules[].issues`** are Make's own complaints about a module (\"not set up\") — usually the direct answer\n  to \"why won't it activate\".\n\nScenario ids come from `scenario_list` or from a create/patch response; `scenario_get` and\n`scenario_module_get` take no `teamId`.\n\n## Account-wide health checks\n\n`scenario_list`'s `status` and `incompleteExecutions` are a cheap first pass, not the answer: `status` only\nturns `error` after Make deactivates a scenario for *repeated* failures, so a scenario that started failing\nyesterday still reads `active`. **A structural read says nothing about whether recent runs succeeded.** For a\nreal answer, call `scenario_execution_list` (narrowed to `status: \"error\"`) for every scenario in scope, then\n`scenario_get` on the ones that turn up failures for connection health and issues. With more scenarios than\nthe 25-row cap, narrow by folder or status and say the sweep is partial.\n\n## Not covered here\n\n- Running, activating, or debugging — `make-scenario-operations`.\n- Creating or editing — `make-scenario-building`.\n"
}