@n8n/instance-ai 1.15.2 → 1.16.0

package/skills/data-table-manager/SKILL.md

@@ -16,8 +16,8 @@ platforms:
 # Data Table Manager
 
 Use this skill to build and maintain n8n Data Tables in the current turn with
-`data-tables` and, for attachments, `parse-file`. Do not delegate, spawn a
-sub-agent, or create a background plan for data-table-only work.
+`data-tables` and, for attachments, `parse-file`. Do not spawn another agent or
+create a background plan for data-table-only work.
 
 Also load this skill before planning or building a workflow whose trigger,
 processing steps, or outputs create, inspect, or write Data Table records, then
@@ -40,7 +40,7 @@ can target rows with narrow filters.
 4. Inspect schema before writes, deletes, column changes, imports into an
    existing table, and workflow-facing summaries.
 5. Execute the smallest direct tool sequence. Prefer read -> decide -> write;
-   never use create-tasks or delegate for standalone table work.
+   never use create-tasks for standalone table work.
 6. Close with facts: table name, table ID when available, project if relevant,
    columns changed, row counts inserted/updated/deleted, skipped rows, and any
    approval or permission blocker.

package/skills/intent-recognition/SKILL.md

@@ -0,0 +1,269 @@
+---
+name: intent-recognition
+description: >-
+  Classifies automation requests using two decisions: anchor (which primitive
+  owns the top-level control flow — workflow-anchored, agent-anchored,
+  needs-clarification, or out-of-scope) and embeds_other (whether the other
+  primitive appears embedded inside — an agent step inside a workflow, or a
+  workflow invoked as an agent tool). Must be used before deciding the intent
+  of any automation request, including compound requests with multiple
+  independent automations, mid-build extensions to an existing workflow or
+  agent, and requests that need clarification before an anchor can be chosen,
+  before choosing workflow-builder, planning, or an agent-oriented design.
+---
+
+# Intent recognition
+
+## Purpose
+
+Use this skill to classify an automation request before designing or building
+it. This skill must be used before deciding whether a request is
+workflow-anchored, agent-anchored, needs clarification, or out of scope, and
+before deciding whether the other primitive is embedded inside it. The
+deciding question is not a single "workflow or agent" label — it is two
+questions: who owns the top-level control flow, and does the other primitive
+show up inside that flow.
+
+If the user asked to build, route on the result: workflow-builder for
+workflow-anchored (a bounded LLM step is an AI node in the graph; an embedded
+agent is an AI Agent step inside it), an agent-oriented design for
+agent-anchored (a tool-use loop; build reusable actions as workflows the
+agent invokes), `ask-user` for needs-clarification, or answer directly for
+out-of-scope.
+
+## Inputs
+
+- The user's request or scenario prompt.
+- Whether the user is mid-build on an existing workflow or agent in this
+  conversation — incremental requests default to extending that primitive.
+- Any explicit constraints about determinism, auditability, latency, cost,
+  compliance, reusability, or allowed tools.
+- If the request is underspecified on an anchor-deciding axis, ask for the
+  missing detail instead of guessing.
+
+## Decisions
+
+Two orthogonal decisions per request, or per part for compound requests:
+
+**1. Anchor** — which primitive owns the top-level control flow:
+
+- **workflow-anchored**: the outer shell is a workflow graph. May include LLM
+  steps as bounded transformers (classify, extract, summarize, score, a
+  single decision feeding fixed branches).
+- **agent-anchored**: an agent owns the flow; the LLM decides the next step
+  at runtime.
+- **needs-clarification**: the request is under-specified on an
+  anchor-deciding axis.
+- **out-of-scope**: not a build intent at all. Covers meta or product
+  questions (e.g. asking what the assistant is capable of building) and
+  one-off content tasks with no trigger, no persistence, and no reuse intent
+  (summarize, translate, or draft something once) — answer or do these
+  directly instead of building an automation. Requests to operate on
+  existing resources (debugging a failed execution, listing or managing
+  workflows, querying data) are not classified by this skill at all — route
+  them through their normal paths.
+
+**2. Embeds other** — whether the other primitive appears inside the anchor:
+
+- workflow-anchored + `true`: an agent embedded as a workflow step (e.g. a
+  scheduled pipeline whose middle step is open-ended investigation).
+- agent-anchored + `true`: workflows invoked as tools of the agent —
+  especially when the user wants reusable or manually-triggerable actions, or
+  an action is itself a deterministic multi-step procedure.
+- `n/a` for needs-clarification and out-of-scope.
+
+**Migration from the old taxonomy**: old **hybrid** → workflow-anchored,
+`embeds_other: false`. Old **single AI task** → out-of-scope when it is a
+one-off request (do the task directly); workflow-anchored with one LLM step
+only when the user wants a persistent, triggerable automation. Old
+**ambiguous** → needs-clarification. Old **workflow** and **agent** map
+directly onto the matching anchor value.
+
+## Decision Steps
+
+0. If the user is mid-build on an existing workflow or agent, apply context
+   continuity (see Signals) before anything else — an incremental request
+   normally extends the current primitive.
+1. If the request is not a build intent — a meta or product question, or a
+   one-off content task with no trigger or reuse — classify **out-of-scope**
+   and answer or do it directly.
+2. Split the request into parts only if it contains multiple independent
+   automations with separate lifecycles (unrelated triggers, audiences, or
+   cadences). Markers like numbering or "and separately" are a giveaway but
+   are not required — a single plain sentence can contain two automations.
+   Do not split a single automation that merely enumerates many tools or
+   steps. Run steps 3-7 on each part.
+3. Test the agent signals. If any one holds, classify **agent-anchored**.
+4. Otherwise, test the workflow conditions. If all of them hold, classify
+   **workflow-anchored**.
+5. Decide `embeds_other` in both directions: does an agent step appear inside
+   this workflow, or does this agent invoke workflows as tools?
+6. If the request is under-specified on an anchor-deciding axis (rule-based
+   vs judgment-based, scope/autonomy, interaction mode), classify
+   **needs-clarification** and name the missing axis instead of guessing.
+7. If both anchors are genuinely defensible, apply the growth tiebreaker:
+   prefer whichever primitive scales with likely complexity growth — usually
+   agent-anchored when novel situations, longer horizons, or learning are
+   implied. The tiebreaker applies only to genuine ties: when a bounded
+   workflow reading fully satisfies the request, prefer it. If it is a real
+   toss-up, say so and name both readings instead of feigning certainty.
+
+## Signals
+
+**Agent-anchored** (any one is enough):
+
+- Reasoning dominates the flow: investigate, decide, act, iterate.
+- Multi-session or long-running: coordination across days, tracked open
+  threads, daily check-ins.
+- Proactive or heartbeat-driven: wakes on its own, checks state, decides
+  whether to intervene.
+- Self-improving or skill accretion is first-class: learns from feedback
+  over time, gets better at the task.
+- Chat or session-based interaction.
+- Cross-session memory.
+
+**Workflow-anchored** (all must hold):
+
+- Structure is a graph of enumerable steps.
+- Any LLM use is a bounded transformer: fixed-label classify, extract,
+  summarize, or a single decision.
+- Trigger and actions are deterministic.
+- Reproducibility or auditability is served by the same graph running every
+  time.
+
+**Embeds-other signals**:
+
+- Workflow with an embedded agent: a step in an otherwise fixed pipeline is
+  open-ended ("figure out why", "investigate", "decide what to do about it")
+  while the trigger and surrounding steps stay deterministic.
+- The embedding is often implicit — the request never says "agent". Ask of
+  each step: could a fixed-instruction transform do it (enumerable labels,
+  one bounded rewrite), or does doing it well require gathering and weighing
+  context that differs per item, then producing a judgment? A nightly job
+  that drafts a tailored renewal pitch for each account from its usage
+  history embeds an agent; a nightly job that condenses each ticket into a
+  two-sentence summary does not.
+- Agent with workflow tools: the user asks for actions that should also be
+  reusable, callable manually, or run outside the agent; or an action the
+  agent invokes is itself a deterministic multi-step procedure.
+
+**Context continuity** (step 0): inside a workflow build, a request to insert
+a scoring step stays a bounded LLM step, not a new agent. Inside an agent
+build, a request to post an update on completion is a new tool on that
+agent, not a spawned workflow. Only cross into the other primitive when the
+incremental request itself carries its own anchor signal — and even then,
+prefer asking before switching paradigm if it isn't clearly load-bearing.
+
+**Clarify triggers**: rule-based vs judgment-based (what defines "important"
+or "urgent"?), scope/autonomy (act on its own vs draft for review),
+interaction mode (one-shot vs chat). Do not clarify when the criterion could
+defensibly go either way — that is a genuine tie, name both readings
+instead.
+
+**False friends — not signals**:
+
+- Surface vocabulary: "agent", "assistant", "bot", "workflow", "automate" in
+  the request text carry no weight. Classify the shape, not the words.
+- Step count and tool count: long linear pipelines and high tool counts are
+  not agentic. Seven deterministic steps with zero branches is still a
+  workflow.
+
+## Examples
+
+- "Every day at 6pm, pull today's Shopify order count and post it to a
+  Discord channel." -> **workflow-anchored**, `embeds_other: false`: fixed
+  schedule, source, and destination.
+- "When a new Jira issue is created, classify it as bug/feature/question and
+  route it to the matching Discord channel." -> **workflow-anchored**,
+  `embeds_other: false`: bounded classification feeding fixed routing (would
+  have been **hybrid** under the old taxonomy).
+- "Every night, gather the day's failed background jobs, dig into the logs
+  and recent deploys to work out why each one failed, and post a write-up to
+  a Notion page." -> **workflow-anchored**, `embeds_other: true`: schedule
+  and destination are fixed; "work out why" is open-ended investigation, best
+  run as an embedded agent step.
+- "Give me a chat window where I can ask about our expense-reporting rules
+  and get answers pulled from the finance handbook." -> **agent-anchored**,
+  `embeds_other: false`: chat interaction, the LLM decides what to look up
+  each turn.
+- "Build an ops agent that can check server health, restart services via our
+  runbook, and file a Jira ticket if it can't resolve things — the restart
+  and ticket-filing should also be triggerable manually elsewhere." ->
+  **agent-anchored**, `embeds_other: true`: explicitly reusable actions are
+  workflows the agent calls as tools.
+- "Have an agent keep an eye on our AWS spend throughout the day and flag me
+  before we blow through budget, without me asking it to check." ->
+  **agent-anchored**, `embeds_other: false`: proactive, heartbeat-driven,
+  no fixed check schedule.
+- "Build an agent that drafts replies to Notion comment threads and sharpens
+  its sense of our tone the more we correct it." -> **agent-anchored**,
+  `embeds_other: false`: skill accretion from feedback is first-class.
+- "Put an agent in charge of coordinating our office relocation — track
+  vendors, follow up with each team lead, and send reminders through our
+  existing reminder workflow when a task stalls." -> **agent-anchored**,
+  `embeds_other: true`: long-running coordination invoking a workflow tool.
+- "Configure an AI agent to send me a nightly digest of new GitHub stars."
+  -> **workflow-anchored**, `embeds_other: false`: fixed schedule and action
+  despite the word "agent" — a false friend.
+- "Spin up a lightweight workflow that talks to shoppers on our storefront
+  and handles their product questions." -> **agent-anchored**: chat-based
+  Q&A means the LLM owns turn-by-turn control despite the word "workflow" —
+  a false friend in the other direction.
+- "Post every new Airtable record to a Discord channel, and separately set up
+  an agent that handles customer refund requests end-to-end." -> two parts,
+  joined only by topic, not data or trigger: "Airtable-to-Discord posting"
+  (**workflow-anchored**, `embeds_other: false`) and "refund-handling agent"
+  (**agent-anchored**, `embeds_other: true`).
+- "Transcribe my sales calls and chase the deals that go quiet." -> two
+  parts despite the plain single sentence: transcription is a bounded
+  per-call pipeline (**workflow-anchored**, `embeds_other: false`), while
+  chasing stalled deals is an ongoing judgment-driven automation with its
+  own lifecycle (**agent-anchored**).
+- "Set up a research helper capable of searching the web, querying our
+  internal wiki, pulling numbers from Google Analytics, and drafting a slide
+  deck that summarizes the findings." -> one part, **agent-anchored**,
+  `embeds_other: true`: many tools but one lifecycle — do not split on tool
+  count.
+- "Tell me when something important happens with our shipments." ->
+  **needs-clarification**: "important" is undefined; ask whether concrete
+  rules exist or this needs judgment-based triage.
+
+## Gotchas
+
+- Do not label a request agent-anchored just because it is long, multi-step,
+  or mentions AI.
+- Do not label classify-then-route as agent-anchored unless the model
+  repeatedly decides the next action after observing prior results.
+- Do not force vague prompts into an anchor; ask when an anchor-deciding
+  axis is missing.
+- Never default `embeds_other` to `false` without checking both directions:
+  an agent step hiding inside a workflow, and a workflow acting as an
+  agent's tool.
+- Never split a compound request on tool or step enumeration alone — split
+  only on separate lifecycles.
+- Unnecessary agency adds latency, cost, and compounding error risk — do not
+  reach for an agent when a bounded workflow fully satisfies the request.
+- Do not use an agent when progress cannot be verified: if the path cannot
+  be scripted and the result cannot be checked, the design is not ready.
+- Respect the current build context: an incremental request stays on the
+  active primitive unless it carries its own anchor signal.
+- Keep n8n framing clear: agents operate inside workflow guardrails; they do
+  not replace the workflow engine.
+
+## Output Format
+
+Return a concise classification and reason:
+
+```text
+Anchor: workflow-anchored | agent-anchored | needs-clarification | out-of-scope
+Embeds other: true | false | n/a
+Reason: <one or two sentences citing the deciding signals>
+Next step: <build workflow / build workflow with embedded agent step / design agent (workflows as tools where actions should be reusable) / ask clarification / answer directly>
+```
+
+For build requests, do not expose this format unless the user asks for
+classification. Instead, proceed according to the selected next step. When
+the user asks for classification in a specific format, such as a JSON block,
+follow that format and map the vocabulary accordingly (workflow-anchored,
+agent-anchored, needs-clarification, out-of-scope, and their equivalents).
+For compound requests, output one classification block per part.

package/skills/n8n-docs-assistant/SKILL.md

@@ -16,11 +16,14 @@ recommended_tools:
 Use this skill when the user asks how to configure, set up, troubleshoot, or
 understand n8n behavior and the answer should come from current n8n docs.
 
+Before calling `n8n-docs`, load it via `load_tool` (search "n8n docs" if it is
+not visible).
+
 ## Default Procedure
 
-1. Call `n8n-docs(action="lookup")` first for credential setup and direct n8n
-   docs questions. Use `search` then `read` only when you need tighter control
-   over candidate pages.
+1. Load `n8n-docs` via `load_tool` if needed, then call `n8n-docs(action="lookup")`
+   first for credential setup and direct n8n docs questions. Use `search` then
+   `read` only when you need tighter control over candidate pages.
 2. For credential setup, pass `intent: "credential-setup"` and all available
    context fields: `credentialType`, `credentialDisplayName`,
    `documentationUrl`, `oauthRedirectUrl`, and `nodeType`.

package/skills/planned-task-runtime/SKILL.md

@@ -3,13 +3,12 @@ name: planned-task-runtime
 description: >-
   Handles system follow-up turns: planned-task-follow-up (synthesize, replan,
   build-workflow, checkpoint), background-task-completed, running-tasks context,
-  create-tasks silence rules, and detached delegate completion. Load whenever
-  any of these tags appear or after spawning   create-tasks or delegate.
+  and create-tasks silence rules. Load whenever any of these tags appear or
+  after calling create-tasks.
 recommended_tools:
   - create-tasks
   - complete-checkpoint
   - build-workflow
-  - delegate
   - task-control
   - workflows
   - verify-built-workflow
@@ -20,12 +19,12 @@ recommended_tools:
 
 Load this skill when the current message contains `<planned-task-follow-up>`,
 `<background-task-completed>`, `<running-tasks>`, or immediately after calling
-`create-tasks` or `delegate`.
+`create-tasks`. Before calling `create-tasks`, load it via `load_tool` if it is
+not already visible (search "create tasks" if needed).
 
 ## Silence after spawning tasks
 
-**After calling detached or scheduled task tools** (`delegate` or
-`create-tasks`): do not write any text. The task card or approval card shows the
+**After calling `create-tasks`**: do not write any text. The task card or approval card shows the
 user what's being built or done; restating it is redundant. Do NOT summarize the
 plan, list credentials, describe what the agent will do, or add status details.
 Progress is already visible to the user in real time.
@@ -37,7 +36,7 @@ invent synthetic follow-up turns.
 
 ## Never poll
 
-**Never poll and never sleep.** Background tasks (`delegate`) settle via
+**Never poll and never sleep.** Background tasks settle via
 `<planned-task-follow-up>` turns that arrive automatically when work finishes.
 After you spawn or acknowledge one, end your turn. Do not call
 `workflows(action="list")`, `executions(action="list")`, or any shell command
@@ -49,9 +48,6 @@ yourself. Do not re-dispatch a build whose task ID is already visible in
 When `<running-tasks>` context is present, use it only to reference active task
 IDs for cancellation or corrections.
 
-Always pass `conversationContext` when spawning background agents (`delegate`) —
-summarize what was discussed, decisions made, and information gathered.
-
 If the user sends a correction while a build is running, call
 `task-control(action="correct-task")` with the task ID and correction.
 
@@ -81,7 +77,8 @@ create another plan.
 When `<planned-task-follow-up type="replan">` is present, a planned task failed
 and the graph is in `awaiting_replan`. You MUST take action in this same turn —
 handle a single simple task directly (matching tool: `build-workflow`,
-`data-tables`, `delegate`, etc.), call `create-tasks` with
+`data-tables`, etc.), load `create-tasks` via `load_tool` if needed and call
+`create-tasks` with
 `planningContext.source: "replan"` for multiple dependent tasks, or explain the
 blocker to the user if nothing sensible remains. Do NOT reply with an
 acknowledgement or status update alone — the scheduler will not fire another
@@ -91,7 +88,8 @@ Replan routing (do not re-plan from scratch):
 
 - One simple task remains (single data-table op, credential setup, single-workflow
   patch) → handle directly with the matching tool.
-- Multiple dependent tasks still need scheduling → `create-tasks` with
+- Multiple dependent tasks still need scheduling → load `create-tasks` via
+  `load_tool` if needed, then call `create-tasks` with
   `planningContext.source: "replan"`.
 - Nothing sensible remains → explain the blocker to the user.
 
@@ -157,8 +155,8 @@ and let replan take over.
 ## Background task completed
 
 When `<background-task-completed>` is present, a detached background task
-finished. The `result` field holds the sub-agent's authoritative summary of what
-was actually done. **When you write the user-facing recap, take factual details —
+finished (for example eval setup). The `result` field holds the task's
+authoritative summary of what was actually done. **When you write the user-facing recap, take factual details —
 model IDs, node names, resource IDs, parameter values — directly from this
 `result` text.** Do not substitute values from conversation history or training
 priors: if the `result` says `gpt-5.4-mini`, write `gpt-5.4-mini`, not "GPT-4o

package/skills/planning/SKILL.md

@@ -20,8 +20,11 @@ recommended_tools:
 # Planning
 
 Use this skill to design a dependency-aware task graph in the orchestrator and
-submit it with `create-tasks`. Do not spawn another agent, do not delegate the
-planning step, and do not use incremental plan item tools.
+submit it with `create-tasks`. Do not spawn another agent and do not use
+incremental plan item tools.
+
+Before calling `create-tasks`, load it via `load_tool` (search "create tasks" if
+it is not visible).
 
 ## When NOT to use this skill
 
@@ -69,7 +72,8 @@ with direct `data-tables` and `parse-file` calls.
    artifact shared across tasks.
 6. Add checkpoint tasks only for exceptional semantic checks that normal
    workflow verification cannot cover.
-7. Call `create-tasks` with `planningContext.source: "planning-skill"`,
+7. Load `create-tasks` via `load_tool` if needed, then call `create-tasks` with
+   `planningContext.source: "planning-skill"`,
    a concise `summary`, optional `assumptions`, `postBuildRunRequested: true`
    only when the user explicitly asked to run, execute, or test a workflow
    after building it, and the final task graph.
@@ -78,8 +82,7 @@ with direct `data-tables` and `parse-file` calls.
 
 ## Task Graph Rules
 
-- Use task kinds exactly as supported: `build-workflow`, `delegate`, and
-  `checkpoint`.
+- Use task kinds exactly as supported: `build-workflow` and `checkpoint`.
 - Each task `id` must be stable and referenced by dependency edges.
 - Each `title` should be short and user-facing.
 - Each `spec` must be the complete executor briefing for that task. The task
@@ -115,8 +118,6 @@ with direct `data-tables` and `parse-file` calls.
   set `isSupportingWorkflow: true` on that task. Do not set it for helper
   sub-workflows that are only intermediate artifacts inside a larger main
   workflow task.
-- For `delegate` tasks, include all context the background task needs and list
-  only the tools it should use.
 - For `checkpoint` tasks, write structured semantic verification instructions:
   `Verify trigger mode`, `Verify external systems`, `Verify required effects`,
   `Verify required branches`, `Verify required data`,
@@ -166,13 +167,13 @@ contracts, confirming a report combines upstream data correctly, validating a
 business invariant across deliverables, or checking a condition that cannot be
 covered by normal runtime verification.
 
-Do not add checkpoints for delegate tasks, and do not list `tools` on checkpoint
-tasks.
+Do not add checkpoints for routine verification-only work.
 
 ## Revisions
 
-If the user rejects the plan with requested changes, revise surgically and call
-`create-tasks` again in the same orchestrator run with
+If the user rejects the plan with requested changes, revise surgically, load
+`create-tasks` via `load_tool` if needed, and call `create-tasks` again in the
+same orchestrator run with
 `planningContext.source: "planning-skill"`.
 
 If the user denies the plan outright, stop. Do not call `create-tasks` again in

package/skills/post-build-flow/SKILL.md

@@ -257,6 +257,15 @@ default path. Workflow verification is automatic from the build outcome; the
 orchestrator handles workflow setup after verification when the saved workflow
 still has mocked credentials or placeholders.
 
+**Trust the build outcome over your own source file.** When `build-workflow`
+returns `resolvedCredentialsByNode` (or `setupRequirement.status ===
+"not_required"`), the saved workflow is already connected to existing
+credentials — even if your source used an unresolved `newCredential()` call.
+Do not ask the user to connect those credentials, do not offer the setup card
+for them, and do not describe them as missing; at most mention which existing
+credential is being used. Route credential setup only when the build outcome
+reports mocked credentials or `setupRequirement.status === "required"`.
+
 **Ask once when a service has multiple credentials of the same type.** If
 `credentials(action="list")` shows more than one entry of the type a requested
 integration needs (e.g. two `openAiApi` accounts, three Google Calendar

package/skills/workflow-builder/SKILL.md

@@ -28,8 +28,8 @@ saved workflow changes.
 
 This skill runs inside the orchestrator — no separate builder agent, handoff,
 or tool allowlist; use the orchestrator and workspace file tools already
-available this turn (plus any relevant tool-search/MCP tool). Never call
-`delegate` to build, patch, fix, verify, or update workflows.
+available this turn (plus any relevant tool-search/MCP tool). Workflow building
+runs in the orchestrator with this skill and `build-workflow`.
 
 For new single-workflow requests, build directly with
 `build-workflow({ filePath, sourceCode })` — the complete TypeScript SDK
@@ -257,18 +257,70 @@ decision after testing.
   workflow already had it. Otherwise use `newCredential('Suggested Credential
   Name')` — build tools mock unresolved credentials for verification and setup
   collects real ones later.
+- When `build-workflow` returns `resolvedCredentialsByNode`, the build already
+  attached a credential to those nodes — either an existing stored credential or
+  an n8n Connect–managed one (entries with `id: null` and `__aiGatewayManaged:
+  true`). Treat them all as connected: do not ask the user to connect or create
+  those credentials, do not route them to credential setup, and mention at most
+  that the credential (or n8n Connect) is being used.
 - Never use raw credential objects like `{ id: '...', name: '...' }` in SDK
   code; replace them with `newCredential()` when editing roundtripped code.
 - If a required credential type is not listed, call
   `credentials(action="search-types")` with the service name. Prefer dedicated
   credential types over generic auth; when generic auth is truly needed,
   prefer `httpBearerAuth` over `httpHeaderAuth`.
+- `credentials(action="list", type=...)` may include a synthetic n8n Connect
+  entry `{ id: null, name: "n8n Connect", type, __aiGatewayManaged: true }`
+  when the type is covered by n8n Connect (see n8n Connect Preference). It is
+  not a stored credential: never pass it to `newCredential(...)` and never
+  emit `id: null` or the `__aiGatewayManaged` marker in SDK output. Setup
+  applies it automatically when the user has no stored credential of that type.
 - These rules apply to outbound service calls. Inbound trigger nodes (Webhook,
   Form, Chat, MCP Trigger) keep authentication at its default `none` unless
   the user explicitly asks to authenticate inbound traffic.
 - Always declare `output` on nodes that use unresolved credentials when mock
   data is needed for verification.
 
+## n8n Connect Preference
+
+"n8n Connect" is the user-facing name of n8n's managed credential
+service. On instances licensed for it, several common AI-provider and
+scraping nodes can run with zero credential setup on the user's side.
+
+**Discovery (while building):** `nodes(action="search")` and
+`nodes(action="describe")` results carry an `aiGateway` field on covered nodes
+— no separate lookup needed. When `aiGateway.supported === true`, prefer that
+node over comparable alternatives *when the user has not named a specific
+tool*, and respect the constraints it reports:
+  - Set `typeVersion >= aiGateway.minVersion` when present.
+  - Constrain `resource` / `operation` to entries in `aiGateway.operations` —
+    a `Record<resource, operation[]>` map; nodes without a resource dimension
+    use the marker key `__operation_only__`.
+  - Do not set parameters listed in `aiGateway.hiddenProperties`.
+
+**Enumeration (answering "what does n8n Connect support?"):**
+  - All supported nodes: `nodes(action="list", n8nConnectOnly=true)` — each
+    result carries the full `aiGateway` field (minVersion, operations,
+    hiddenProperties).
+  - All supported credential types:
+    `credentials(action="search-types", n8nConnectOnly=true)`.
+  - Operations for a specific supported node: `nodes(action="describe", …)`
+    → `aiGateway.operations`.
+
+**Preference rule:** When adding a new node that has no credential assigned
+yet, prefer n8n Connect over stored credentials if the credential type is
+supported — it provides zero-setup access and avoids spending the user's API
+quota. The synthetic entry in `credentials(action="list", type=...)` (see
+Credential Rules) is your signal that a type is covered. Do not change
+credentials on nodes that already have one assigned (editing an existing
+workflow, or after the user has made a credential choice).
+
+- If the user explicitly specified their own credential (by name or by
+  choosing one from a list), use that credential and do not substitute
+  n8n Connect.
+- When speaking to the user in chat, always refer to this feature as
+  "n8n Connect" — not "AI Gateway", which is only an internal name.
+
 ## Missing Resources
 
 When `nodes(action="explore-resources")` returns no results for a required
@@ -297,7 +349,7 @@ decompose into supporting sub-workflows (`executeWorkflowTrigger` v1.1 with an
 explicit input schema, built with `isSupportingWorkflow: true`) referenced from
 the main workflow's `executeWorkflow` node (`source: 'database'`, real returned
 `workflowId`), main workflow saved last. This is part of the approved build
-task — not a reason to call `delegate` or create a new plan, and simple
+task — not a reason to create a new plan, and simple
 workflows stay in one workflow. Before writing multi-workflow code, load this
 skill's `references/compositional-workflows.md` linked file for the required
 steps and SDK examples.

package/skills/workflow-builder/references/compositional-workflows.md

@@ -1,8 +1,7 @@
 # Compositional Workflows
 
 For complex workflows, you may decompose work into supporting sub-workflows and
-a main workflow. This is part of an approved build task, not a reason to call
-`delegate` or create a new plan.
+a main workflow. This is part of an approved build task, not a reason to create a new plan.
 
 Use this pattern when a workflow is large, has reusable chunks, or benefits from
 independent testing. Simple workflows should stay in one workflow.

package/dist/tools/orchestration/delegate.schemas.d.ts

@@ -1,44 +0,0 @@
-import { z } from 'zod';
-export declare const delegateInputSchema: z.ZodObject<{
-    role: z.ZodString;
-    instructions: z.ZodString;
-    tools: z.ZodDefault<z.ZodArray<z.ZodString, "many">>;
-    briefing: z.ZodString;
-    artifacts: z.ZodOptional<z.ZodRecord<z.ZodString, z.ZodUnknown>>;
-    conversationContext: z.ZodOptional<z.ZodString>;
-}, "strip", z.ZodTypeAny, {
-    tools: string[];
-    role: string;
-    instructions: string;
-    briefing: string;
-    artifacts?: Record<string, unknown> | undefined;
-    conversationContext?: string | undefined;
-}, {
-    role: string;
-    instructions: string;
-    briefing: string;
-    tools?: string[] | undefined;
-    artifacts?: Record<string, unknown> | undefined;
-    conversationContext?: string | undefined;
-}>;
-export type DelegateInput = z.infer<typeof delegateInputSchema>;
-export declare const delegateOutputSchema: z.ZodObject<{
-    result: z.ZodString;
-    toolCallCount: z.ZodOptional<z.ZodNumber>;
-    toolErrorCount: z.ZodOptional<z.ZodNumber>;
-    durationMs: z.ZodOptional<z.ZodNumber>;
-    blockers: z.ZodOptional<z.ZodArray<z.ZodString, "many">>;
-}, "strip", z.ZodTypeAny, {
-    result: string;
-    toolCallCount?: number | undefined;
-    toolErrorCount?: number | undefined;
-    durationMs?: number | undefined;
-    blockers?: string[] | undefined;
-}, {
-    result: string;
-    toolCallCount?: number | undefined;
-    toolErrorCount?: number | undefined;
-    durationMs?: number | undefined;
-    blockers?: string[] | undefined;
-}>;
-export type DelegateOutput = z.infer<typeof delegateOutputSchema>;

package/dist/tools/orchestration/delegate.schemas.js

@@ -1,46 +0,0 @@
-"use strict";
-Object.defineProperty(exports, "__esModule", { value: true });
-exports.delegateOutputSchema = exports.delegateInputSchema = void 0;
-const zod_1 = require("zod");
-exports.delegateInputSchema = zod_1.z.object({
-    role: zod_1.z
-        .string()
-        .describe('Free-form role description (e.g., "workflow builder", "execution debugger")'),
-    instructions: zod_1.z
-        .string()
-        .describe('Task-specific system prompt for the sub-agent. Be specific about what to do and how.'),
-    tools: zod_1.z
-        .array(zod_1.z.string())
-        .default([])
-        .describe('Subset of registered native domain tool names the sub-agent needs'),
-    briefing: zod_1.z.string().describe('The specific task to accomplish, including all relevant context'),
-    artifacts: zod_1.z
-        .record(zod_1.z.unknown())
-        .optional()
-        .describe('Relevant IDs, data, or context (workflow IDs, credential IDs, etc.)'),
-    conversationContext: zod_1.z
-        .string()
-        .optional()
-        .describe('Brief summary of the conversation so far — what was discussed, decisions made, and information gathered. The sub-agent uses this to avoid repeating information the user already knows.'),
-});
-exports.delegateOutputSchema = zod_1.z.object({
-    result: zod_1.z.string().describe('The sub-agent synthesized answer'),
-    toolCallCount: zod_1.z
-        .number()
-        .int()
-        .min(0)
-        .optional()
-        .describe('Total number of tool invocations the sub-agent made'),
-    toolErrorCount: zod_1.z
-        .number()
-        .int()
-        .min(0)
-        .optional()
-        .describe('Number of tool invocations that failed'),
-    durationMs: zod_1.z.number().optional().describe('Wall-clock duration in milliseconds'),
-    blockers: zod_1.z
-        .array(zod_1.z.string())
-        .optional()
-        .describe('Specific blockers encountered during execution'),
-});
-//# sourceMappingURL=delegate.schemas.js.map