Update to Mаke

{
  "name": "make-api-shell",
  "description": "Use when the user wants data out of (or an action in) a SaaS account through Make without a purpose-built automation — \"get my unread emails\", \"list my Jira tickets\" — via a small on-demand scenario wrapping the provider's Make an API Call module or a generic HTTP request.",
  "included_files": [
    {
      "relative_path": "examples/api-shell.json",
      "size_in_bytes": 1329
    },
    {
      "relative_path": "examples/http-shell.json",
      "size_in_bytes": 2184
    },
    {
      "relative_path": "references/http-fallback.md",
      "size_in_bytes": 3366
    }
  ],
  "skill_md_contents": "---\nname: make-api-shell\ndescription: Use when the user wants data out of (or an action in) a SaaS account through Make without a purpose-built automation — \"get my unread emails\", \"list my Jira tickets\" — via a small on-demand scenario wrapping the provider's Make an API Call module or a generic HTTP request.\nmetadata:\n  version: \"0.1.7\" # x-release-please-version\n---\n\n# Make API shells — a reusable API endpoint inside Make\n\nAn **API shell** is a three-module on-demand scenario — `scenario-service:StartSubscenario` → the provider's\n*Make an API Call* module → `scenario-service:ReturnData` — that takes `path`, `method`, `header`, `qs`,\n`body` as inputs and returns the provider's response body. Built once per provider **and connection**, it\nturns any Make-connected account into an authenticated HTTP endpoint the assistant can call with\n`scenario_run`. It is a transport, not business logic: interpreting the response happens afterwards.\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## Workflow\n\n1. **Resolve the anchor before any tool call**: provider (Gmail vs Outlook, HubSpot vs Salesforce, Jira vs\n   Linear), and the account or mailbox when several are plausible. Ask only for what is missing.\n2. `environment_get` → `organizationId`/`teamId`.\n3. **Find the API-call module.** `app_find` with \"<provider> make an API call\". The module's name is not\n   standardized (`makeAnApiCall`, `makeApiCall`, `MakeAPICall`, `ActionMakeAnApiCall`, …) — take it from the\n   result, never guess. No Make app for the provider (or only a community one) → build an HTTP shell instead:\n   [HTTP fallback](./references/http-fallback.md).\n4. `module_spec(schemas: true)` on `[\"scenario-service:StartSubscenario\", \"<app>:<apiCallModule>\",\n   \"scenario-service:ReturnData\"]`. Note the API-call module's connection requirement and its `mapper` field\n   names (`url`, `method`, `headers`, `qs`, `body` — confirm; a few apps differ) and its output field that\n   carries the response body (usually `body`).\n5. **Connection.** Reuse an id from `connection.existing` when it is the right account; otherwise\n   `connection_create` → the user authorizes → `connection_get`. A connection that authenticates but lacks the\n   scope for the intended call fails at run time with a provider permission error — treat that as \"no suitable\n   connection\" and request a new one; connections cannot be widened in place.\n6. **Reuse an existing shell only for an existing connection.** `scenario_list` with `search` for the shell\n   naming convention (`API shell: <app>`), then `scenario_get` to confirm the three modules and\n   `scenario_module_get` to confirm which connection the middle module is bound to. A **new connection always\n   gets a new shell** — never repoint an existing shell at a different account.\n7. `scenario_create` from [api-shell.json](./examples/api-shell.json): `scheduling: {\"type\": \"on-demand\"}`,\n   the `interface` with the five inputs and one `data` output, and `ReturnData` mapped to\n   `{\"data\": \"{{2.body}}\"}` — the response body, not the whole bundle `` {{`2`}} `` and not a guessed\n   nested field.\n8. `scenario_activate`, then a **narrow validation run**: `scenario_run` with\n   `inputs: {\"path\": \"…\", \"method\": \"GET\", \"header\": [], \"qs\": [{\"name\": \"limit\", \"value\": \"5\"}], \"body\": null}`.\n   Read `outputs.data`. A 404 whose URL shows a doubled segment (`/calendar/calendar/v3/…`) means the module's\n   base URL already carries that prefix — strip it from `path`.\n9. **Then retrieve for real**: list or search with a narrow filter → collect ids → detail calls for the\n   shortlist → normalize for the user. Every step goes through the shell; do not fall back to the app's native\n   search modules for this workflow family.\n\nSay which phase you are in (provisioning vs retrieval), whether the shell and the connection are reused or\nnew, and the exact API path you chose for the business question.\n\n## Rules\n\n- **Writes need confirmation.** `POST`/`PUT`/`PATCH`/`DELETE` through a shell mutate the live account: state\n  the call and get an explicit yes before running it. Default retrieval is `GET`.\n- **Query parameters go in `qs`**, as `[{name, value}]`, never concatenated into `path`. Split a\n  `path?x=1` the caller hands you.\n- **Empty body on GET.** Some provider modules serialize an empty `body` badly on `GET`/`DELETE`. If a read\n  fails only when `body` is present-but-empty, drop the `body` mapping from the middle module (a read-only\n  shell) and keep a separate write shell that maps it. `ReturnData` stays unchanged either way.\n- **A shell is bound to one app module.** A Gmail shell is not a Google Calendar shell even though both are\n  \"Google\" — different app, module, and connection family. Build one per provider app.\n- **Interpret failures by phase.** Connection request problems are provisioning; an activation refusal is the\n  shell; an empty or odd payload from a successful run is the API path or the normalization — first check that\n  `ReturnData` still maps the middle module's `body`, then the path/method/qs, before touching the blueprint.\n  A provider auth or scope error is never fixed by editing the shell — go back to step 5.\n- Reading and running a shell needs the same scopes as any scenario; the *provider's* permissions are proven\n  only by a successful run of the intended call.\n\n## Not covered here\n\n- Scenarios that run on their own trigger or schedule — `make-scenario-building`.\n- Debugging a shell run beyond `scenario_run`'s response — `make-scenario-operations`\n  (`scenario_execution_inspect`, `scenario_execution_module_get`).\n"
}