@n8n/instance-ai 1.24.3 → 1.25.0

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@n8n/instance-ai",
-  "version": "1.24.3",
+  "version": "1.25.0",
   "main": "dist/index.js",
   "module": "src/index.ts",
   "types": "dist/index.d.ts",
@@ -8,8 +8,8 @@
     "dist/**/*",
     "knowledge-base/**/*",
     "skills/**/*",
-    "LICENSE.md",
-    "LICENSE_EE.md"
+    "LICENSE_EE.md",
+    "LICENSE.md"
   ],
   "exports": {
     ".": {
@@ -42,12 +42,12 @@
   "dependencies": {
     "@daytona/sdk": "0.205.1",
     "@e965/xlsx": "0.20.3",
-    "@n8n/agents": "0.24.2",
-    "@n8n/ai-utilities": "0.32.2",
-    "@n8n/api-types": "1.39.2",
-    "@n8n/mcp-browser": "0.20.0",
-    "@n8n/utils": "1.47.0",
-    "@n8n/workflow-sdk": "0.32.1",
+    "@n8n/agents": "0.25.0",
+    "@n8n/ai-utilities": "0.33.0",
+    "@n8n/api-types": "1.40.0",
+    "@n8n/mcp-browser": "0.21.0",
+    "@n8n/utils": "1.48.0",
+    "@n8n/workflow-sdk": "0.33.0",
     "@opentelemetry/api": "1.9.1",
     "@thednp/dommatrix": "^3.1.1",
     "ai": "^7.0.66",
@@ -56,7 +56,7 @@
     "linkedom": "^0.18.13",
     "luxon": "3.7.2",
     "mammoth": "1.12.1",
-    "n8n-workflow": "2.39.1",
+    "n8n-workflow": "2.40.0",
     "nanoid": "6.0.1",
     "pdf-parse": "2.4.5",
     "psl": "1.15.0",
@@ -68,8 +68,8 @@
   "devDependencies": {
     "@langchain/anthropic": "1.5.6",
     "@langchain/core": "1.2.8",
-    "@n8n/typescript-config": "1.11.0",
-    "@n8n/vitest-config": "1.21.0",
+    "@n8n/typescript-config": "1.12.0",
+    "@n8n/vitest-config": "1.22.0",
     "@types/luxon": "3.2.0",
     "@types/psl": "1.1.3",
     "@types/turndown": "^5.0.6",

package/skills/agent-builder/SKILL.md

@@ -1,12 +1,12 @@
 ---
 name: agent-builder
 description: >-
-  Load before calling build-agent for a new or existing n8n Agent. Governs
-  prerequisite creation, faithful handoff of the user's request, agent
-  targeting across turns, builder questions, testing, and publishing. Use
-  directly for routine follow-ups when the conversation already targets an
-  Agent; rerun intent-recognition only when the requested artifact is no
-  longer clear.
+  Load immediately after an Agent intent. Then call build-agent with the user's
+  request after any required orchestrator-owned prerequisites are ready. Agent
+  Builder owns Agent setup and implementation questions. Governs prerequisite
+  creation, faithful handoff, targeting, testing, and publishing. Use directly
+  for routine Agent follow-ups; rerun intent-recognition only when the requested
+  artifact is no longer clear.
 recommended_tools:
   - build-agent
   - build-workflow
@@ -22,6 +22,15 @@ when the conversation already targets an Agent and the user is continuing that
 build. Do not rerun intent recognition for routine Agent edits or extensions.
 Use `build-agent` only for Agent artifacts.
 
+For a new Agent request, make the first `build-agent` call with a faithful copy
+of the request as soon as any required orchestrator-owned prerequisites are
+ready. Before that call, use `ask-user` only to choose a supported channel or to
+define a workflow or data-table prerequisite that the orchestrator must create.
+Only ask about the channel after `list-agent-capabilities` shows that the
+requested channel is unsupported. Do not collect model, service, tool, topic,
+schedule, credential, or other Agent implementation choices first. The embedded
+Agent Builder asks those questions through the `build-agent` call.
+
 When the conversation opens from an existing Agent in the editor and the user
 asks to change its configuration or capabilities, that is an agent-anchored
 request — target that Agent and call `build-agent`. Do not reroute to

package/skills/credential-recipe-research/SKILL.md

@@ -34,7 +34,7 @@ that is not expressible as a template — use the matching generic type instead
 ## 2. Key page (docsUrl)
 
 Find where a logged-in user CREATES or COPIES the key. The URL is not shown
-in the form — the AI Assistant help thread presents it as THE place to get
+in the form — the n8n Assistant help thread presents it as THE place to get
 the value, so a wrong URL sends the user to a dead end with full confidence:
 
 - Search `"<service> dashboard API keys"`, and scan the fetched auth docs for

package/skills/debugging-executions/SKILL.md

@@ -27,6 +27,30 @@ empty node, or a missing node is a real defect to investigate, not something to
 explain away. If you genuinely cannot re-run the failing path, say so plainly and
 name what is unconfirmed instead of repeating a success claim.
 
+## Draft versus live
+
+A published workflow runs the version that was published, not the draft you
+edit. Your save creates a draft, and the draft is not live until somebody
+publishes it. So a fix to a live workflow changes nothing in production on its
+own.
+
+Two consequences when the user reports a live workflow failing:
+
+- **Read the version each execution ran.** `executions(action="list", workflowId)`
+  returns `workflowVersionId` on every row, plus `workflow.activeVersionId`
+  (the published version) and `workflow.draftVersionId`. Only a row whose
+  `workflowVersionId` equals `workflow.activeVersionId` ran the published code.
+  A run of a draft proves nothing about production. A `workflow.draftVersionId`
+  different from `workflow.activeVersionId` means the latest changes, including
+  any fix you just made, are not live.
+- **Name the version when you invite a retest.** Say whether the user tests the
+  draft or the published version. "Try it again" after a draft-only fix sends
+  the user to the broken published version, and the fix looks like it failed.
+
+Do not report a fix as live until the published version is the fixed one. Ask
+whether to publish it instead. After a publish, a new live run is what confirms
+the fix — an earlier execution ran the old version.
+
 ## Testing event-triggered workflows
 
 Use `executions(action="run")` with `inputData` matching the trigger's output

package/skills/instance-awareness/SKILL.md

@@ -0,0 +1,122 @@
+---
+name: instance-awareness
+description: >-
+  Load when the request depends on what is already on this instance rather than
+  on what the user just typed: a short or ambiguous opener ("fix it", "carry on",
+  "what should I look at"), a reference to earlier work in a new conversation, or
+  any question about what has recently run or broken.
+recommended_tools:
+  - activity
+  - workflows
+  - executions
+  - credentials
+---
+
+# Instance Awareness
+
+The conversation is not the only context you have. This instance carries a
+record of what has been built, changed, run and broken. Most of it is cheap to
+read, and reading it is usually better than asking.
+
+## The one rule
+
+**Ask about intent. Look up state.**
+
+What the user wants next is theirs to tell you. What already exists here is
+yours to find out. A question you could have answered by looking costs the user
+a turn and tells them you are not paying attention — and it is the most common
+complaint in reviewed conversations: the assistant re-asking for something it
+had, or restarting work it had already finished.
+
+## Read in this order — cheapest first
+
+Each rung answers a narrower question at a higher cost. Stop at the first one
+that answers yours. Do not start at the bottom.
+
+### 0. The block you were already given
+
+If an `<instance-context>` block is in this turn, you already have three things
+for free: which workflows exist here, what changed recently, and what has run
+or failed. Read it before your first tool call.
+
+It is a set of pointers, not contents. Each change line ends with the resource
+it is about, and the bracketed number is a stable id. Run lines carry the
+execution id of the last failure, which is what `executions` takes.
+
+A later turn may bring a shorter block that says it is an addition. Those are
+extra entries, not a replacement — the earlier ones still stand.
+
+### 1. `activity(action="list")` and `activity(action="expand", id=N)`
+
+`list` looks further back than the block, or filters to one category or one
+resource. `expand` opens a single entry in full **and returns up to 20 more
+recent entries for the same resource** — which is how you see a workflow's
+recent change history in a single call. Twenty is a cap, not a total: an older
+history continues past it, and `list` with that `resourceId` reads further
+back.
+
+Use `expand` when a line is interesting but thin: a save you want the detail of,
+or a workflow you want the history of. An id that no longer resolves is ordinary
+— entries are pruned — so carry on rather than treating it as an error.
+
+The log covers workflow and credential changes. It does not record runs; those
+come from the block, and `executions` has the detail.
+
+### 2. One workflow, read in full
+
+`workflows(action="get", workflowId, full=true)` on **one** example — the one
+the block points at, or the one the user named. This rung is for what an entry
+cannot express: parameter values, naming, retry settings, error-workflow
+wiring, how a prompt is structured.
+
+Pass `full=true`. Without it a large workflow comes back as structure only,
+with its node parameters omitted — which is exactly what this rung is for.
+
+Read one, not several. If one example is not enough to see the pattern, there is
+probably no pattern to follow.
+
+## What each surface can and cannot tell you
+
+| Question | Where it is answered |
+|---|---|
+| What already exists here? | the block, rung 0 |
+| What did they just change? | the block, rung 0 |
+| Which workflow do they mean by "it"? | the block — the most recent one they touched |
+| What is broken right now? | the block's run lines, then `executions` for the detail |
+| Did the nightly job run? | the block, then `executions` |
+| Who changed this, and was it me? | `activity(action="expand")` — entries carry provenance |
+| How do they configure it? | one workflow, rung 2 |
+| Do they have a credential for X? | `credentials(action="list")` |
+
+## Resolving a vague opener
+
+"fix it", "carry on", "why is this broken", "what should I look at", or a new
+conversation about work from yesterday: the answer is nearly always the most
+recent thing in the block, and usually the most recent *failure*.
+
+Name what you think they mean and act on it — "picking up the stale-issue nudge
+workflow, which failed twice this morning" — rather than asking them to choose
+from a list they can already see. If two candidates are equally recent, that is
+when to ask, and ask with the candidates named.
+
+## Reusing what they changed by hand
+
+A save entry records which node types were added or removed, and whether the
+change came from the assistant or from the user. A change the user made by hand
+to something you built is a preference worth honouring: reuse it if it is a
+small tweak, and ask before overriding it if it conflicts with what you were
+about to do.
+
+## Where this stops
+
+- **An entry is not the workflow.** It records that a save happened and which
+  node types moved, never the parameters. Anything about contents is rung 2.
+- **An entry can outlive its resource.** A deletion entry points at a workflow
+  that is gone; that is the entry doing its job.
+- **Runs end where retention ends.** The instance keeps executions for a bounded
+  window, so an older failure may be gone even though the workflow is not.
+- **Recent is not the same as typical.** The newest workflow may be the odd one
+  out.
+- **Do not narrate the block.** It is context for reading intent, not a status
+  report. Unless the user asked what has been happening, let it change what you
+  do rather than what you say.

package/skills/intent-recognition/SKILL.md

@@ -10,8 +10,9 @@ description: >-
   including compound requests, independent automations introduced mid-build,
   one-off questions or reports that need external systems you cannot query
   directly, and requests that need clarification before an anchor can be
-  chosen. Do not load for routine edits or extensions when the conversation
-  already targets a workflow or Agent.
+  chosen. An explicit Agent request routes to agent-builder before ask-user.
+  Do not load for routine edits or extensions when the conversation already
+  targets a workflow or Agent.
 ---
 
 # Intent recognition
@@ -44,8 +45,10 @@ directly for out-of-scope.
   Context continuity and Existing-agent modification.
 - 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.
+- If the user did not explicitly select an Agent and the request is
+  underspecified on an anchor-deciding axis, ask for the missing detail instead
+  of guessing. An explicit Agent request already decides the anchor. Leave
+  missing setup and implementation details to the Agent Builder.
 
 ## Decisions
 
@@ -57,10 +60,10 @@ Two orthogonal decisions per request, or per part for compound requests:
   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. n8n Agents are not chat-only: besides chat sessions, they run
-  recurring objectives on a cron schedule (**tasks**) and keep memory across
-  sessions and runs — so recurring or scheduled duties do not disqualify this
-  anchor.
+  at runtime or owns an ongoing role that requires judgment. n8n Agents are not
+  chat-only: besides chat sessions, they run recurring objectives on a cron
+  schedule (**tasks**) and keep memory across sessions and runs — so recurring
+  or scheduled duties do not disqualify this anchor.
 - **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
@@ -73,9 +76,14 @@ Two orthogonal decisions per request, or per part for compound requests:
   tracker, wiki, or CRM) is not out-of-scope — classify it, and when
   answering requires judgment-driven navigation of those systems it is
   agent-anchored (see Signals). Requests to operate on existing resources
-  (debugging a failed execution, listing or managing workflows or agents,
-  querying data) are not classified by this skill at all — route them
-  through their normal paths. Finally, a one-off task with a concrete
+  (running or triggering a workflow the user already has, debugging a failed
+  execution, listing or managing workflows or agents, querying data) are not
+  classified by this skill at all — route them through their normal paths.
+  Per the system prompt's "Existing Resources" section, check
+  `workflows(action="list")` before reading "trigger my X" as a build: a
+  workflow's own name can contain a build verb ("X — Create"), and a link to
+  a service you integrate with is an input value, not a request to build an
+  integration for it. Finally, a one-off task with a concrete
   external *effect* (export/copy data somewhere once, a migration, a
   backfill) is **workflow-anchored**, not out-of-scope — the workflow is
   just the vehicle. Classify it by shape (bounded data already in hand,
@@ -128,16 +136,21 @@ builder.
 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. **Explicit artifact requests.** When the user names the deliverable —
-   "build me an agent/assistant that…", "create a workflow that…" — the
-   named primitive is a routing instruction, not surface vocabulary.
-   Classify by it unless the described behavior is unambiguously the other
-   primitive's shape (e.g. "an agent" whose behavior is a fixed
-   schedule-fetch-notify pipeline). Even then, never switch silently:
-   propose the reclassified design and say you are deviating from the named
-   primitive, grounding the choice in the task's shape. The false-friends
-   rule applies to task descriptions, not to an explicitly requested
-   artifact.
+1. **Explicit artifact requests.** "Build me an Agent/assistant that…" selects
+   an Agent artifact and decides the anchor. Do not ask the user to reconsider
+   that choice during intent recognition. Do not silently substitute a workflow,
+   even when it could implement the same behavior. You may explain a simpler
+   workflow alternative, but switch only after the user chooses it. Route
+   missing setup and implementation choices to Agent Builder. The immediate
+   next routing action is to load `agent-builder`. Do not call `ask-user`
+   between classification and that handoff. Forward the request without
+   selecting services, tools, topics, schedules, or other implementation
+   details. Agent Builder owns those questions. An explicit
+   workflow request normally selects a workflow. If its required interaction is
+   unambiguously Agent-shaped, such as ongoing open-ended chat, explain why an
+   Agent fits and say that you are deviating from the named workflow. The
+   false-friends rule applies to task descriptions, not to an explicit Agent
+   request.
 2. 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.
@@ -148,11 +161,16 @@ builder.
    Do not split a single automation that merely enumerates many tools or
    steps. Run steps 4-9 on each part.
 4. Test the agent signals. If any one holds, classify **agent-anchored**.
-5. Otherwise, test the workflow conditions. If all of them hold, classify
+5. Before selecting a workflow, verify that the request supplies or clearly
+   entails every workflow condition. Do not invent a fixed sequence, decision
+   policy, or bounded LLM task from a generic outcome. If a missing
+   anchor-defining detail could make the work judgment-driven, classify
+   **needs-clarification** and ask only for that detail.
+6. Otherwise, test the workflow conditions. If all of them hold, classify
    **workflow-anchored**.
-6. Decide `embeds_other` in both directions: does an agent step appear inside
+7. Decide `embeds_other` in both directions: does an agent step appear inside
    this workflow, or does this agent invoke workflows as tools?
-7. **Degenerate-shell check.** If a workflow-anchored design reduces to a
+8. **Degenerate-shell check.** If a workflow-anchored design reduces to a
    trigger plus a single open-ended agent step that does all the work — no
    deterministic steps earning the shell — the anchor is wrong: reclassify
    **agent-anchored** and build an n8n Agent (an on-demand duty becomes the
@@ -160,9 +178,6 @@ builder.
    this check while building: when fixed nodes prove unusable and the work
    migrates into one embedded agent step, stop and re-anchor instead of
    finishing the degenerate workflow.
-8. 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.
 9. 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
@@ -177,6 +192,11 @@ builder.
 **Agent-anchored** (any one is enough):
 
 - Reasoning dominates the flow: investigate, decide, act, iterate.
+- Persistent delegated role: the user gives an analyst, coordinator,
+  receptionist, researcher, or similar role continuing responsibility for a
+  changing domain. The role must require judgment such as choosing what
+  matters, selecting tools, following up, or adapting actions. A role noun by
+  itself is not enough.
 - On-demand question or report that requires judgment-driven navigation of
   external systems (which items matter, how they map to goals) and cannot be
   answered directly with your own tools — the user is in effect already
@@ -208,14 +228,15 @@ builder.
 
 **Scheduled judgment work** (recurring cadence + open-ended body): both
 primitives can own it — a workflow shell with an embedded agent step, or an
-agent with a scheduled task. Default to the workflow shell for a standalone,
-single-duty job: a deterministic trigger and delivery around one open-ended
-step keeps auditability and avoids unnecessary agency. Choose an agent with a
-task instead when the duty belongs to an agent the user also interacts with
-or that has other duties, when it needs memory across runs (tracking open
-threads, "what did I flag last time"), or when the user explicitly asked for
-an agent. A recurring duty added to an agent mid-build is always a task on
-that agent, never a spawned workflow.
+agent with a scheduled task. Default to an Agent task when the open-ended duty
+is the whole outcome and the workflow shell would only trigger the duty and
+deliver its result. Use a workflow shell when its deterministic collection,
+gating, transformation, branching, or delivery steps are independently
+meaningful and the agent owns only one bounded stage. Choose an Agent when the
+duty belongs to a persistent role, needs memory across runs, supports user
+interaction, or has other duties. An explicit Agent request remains binding.
+A recurring duty added to an agent mid-build is always a task on that agent,
+never a spawned workflow.
 
 **Embeds-other signals**:
 
@@ -271,16 +292,17 @@ that the agent cannot fully satisfy, not a workflow-anchored one.
 
 **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.
+interaction mode (one-shot vs chat). Clarify when the missing answer changes
+the anchor. When the request supplies enough evidence and both designs remain
+valid, apply the growth tiebreaker instead of asking a theoretical preference.
 
-**False friends — not signals**:
+**False friends — not signals by themselves**:
 
 - Surface vocabulary: "agent", "assistant", "bot", "workflow", "automate"
-  in a *task description* carry no weight — classify the shape, not the
-  words. An explicit artifact request ("build me an agent that…") is not a
-  false friend; see Decision Step 1.
+  in a *task description* carries no weight — classify the shape, not the
+  words. A persistent delegated role combines the role with ongoing judgment,
+  so it is a real Agent signal. An explicit artifact request ("build me an
+  agent that…") is binding; see Decision Step 1.
 - 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.
@@ -319,12 +341,18 @@ instead.
   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. When the user instead
-  explicitly asks to *build an agent* around a fixed pipeline like this,
-  keep the workflow classification but say so rather than switching
-  silently (step 1).
+- "Every night, fetch the day's new GitHub stars and send me a digest." ->
+  **workflow-anchored**, `embeds_other: false`: fixed schedule, source,
+  transform, and delivery, with no Agent artifact or judgment requirement.
+- "Build me an agent that fetches new GitHub stars each night and sends me a
+  digest." -> **agent-anchored**, `embeds_other: false`: the user selected an
+  Agent, and the recurring duty is a scheduled task on it. A workflow can be
+  offered as an alternative, but it cannot silently replace the requested
+  artifact.
+- "Set up a daily market analyst. It should research market changes, decide
+  which developments matter, and send me a briefing each morning." ->
+  **agent-anchored**, `embeds_other: false`: the analyst owns a persistent,
+  judgment-driven role; the morning cadence is a task on that Agent.
 - "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" —
@@ -363,6 +391,9 @@ instead.
 - "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.
+- "Ingest each cybersecurity alert, analyze it, and take actions depending on
+  the finding." -> **needs-clarification**: ask whether fixed rules select the
+  actions or whether an investigator must choose and adapt them.
 - "Build me an agent my team can @mention on WhatsApp to triage customer
   messages." -> **agent-anchored** (explicit agent artifact + chat
   interaction), but call `list-agent-capabilities` first: WhatsApp is absent,
@@ -397,6 +428,9 @@ instead.
 - Unnecessary agency adds latency, cost, and compounding error risk — do not
   reach for an agent when a bounded workflow fully satisfies a task-shaped
   request. This is not a license to override an explicit agent request.
+- Unnecessary workflow shells hide Agent intent. Do not wrap an open-ended
+  delegated duty in a workflow when the shell only supplies a schedule and a
+  destination.
 - Never satisfy an **agent-anchored** classification with a workflow
   containing a Chat Trigger + AI Agent node. Agent-anchored requests
   produce an n8n Agent artifact via the agent build path; the AI Agent
@@ -413,7 +447,7 @@ instead.
   agent steps inside a pipeline the user described as a pipeline.
 - A workflow whose only real step is one embedded agent doing all the work
   is an agent wearing a workflow costume — the mirror image of the Chat
-  Trigger gotcha above. Apply the degenerate-shell check (step 7) and
+  Trigger gotcha above. Apply the degenerate-shell check (step 8) and
   re-anchor instead of shipping trigger + AI Agent node.
 - Do not treat a cron schedule as a workflow signal by itself — agents run
   scheduled tasks. Classify by the body of each run, and when a one-off

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

@@ -2,10 +2,9 @@
 name: n8n-docs-assistant
 description: >-
   Answers n8n product, setup, credential, node, hosting, API, and usage
-  questions from current n8n docs. Load n8n-docs via load_tool before calling it
-  (search "n8n docs" if not visible). Use when the user asks how to configure,
+  questions from current n8n docs. Use when the user asks how to configure,
   set up, troubleshoot, or understand n8n behavior, especially credential setup
-  questions opened from the credential modal.
+  questions — including which OAuth scopes or permissions a provider app needs.
 recommended_tools:
   - n8n-docs
   - credentials
@@ -17,14 +16,11 @@ 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. 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.
+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.
 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

@@ -133,7 +133,7 @@ workflow loop or when the user explicitly requested a live run. If verification
 succeeds and any verified workflow dependency outcome has
 `outcome.setupRequirement.status === "required"`, call
 `workflows(action="setup")` with that workflowId before `complete-checkpoint`;
-the inline setup card appears automatically in the AI Assistant panel, so do not
+the inline setup card appears automatically in the n8n Assistant panel, so do not
 tell the user to open the editor, use the canvas, or click a Setup button. If
 setup returns `deferred: true`, or reports `skippedByUser`, respect it and still
 complete the checkpoint with a result that says setup was deferred — never call
@@ -156,7 +156,7 @@ and let replan take over.
 ## Background task completed
 
 When `<background-task-completed>` is present, a detached background task
-finished (for example eval setup). The `result` field holds the task's
+finished. 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

package/skills/planning/SKILL.md

@@ -1,5 +1,8 @@
 ---
 name: planning
+dependencies:
+  tools:
+    - create-tasks
 description: >-
   ONLY for coordinated multi-artifact work: multiple workflows with dependencies,
   shared data-table schema/migration across tasks, or the user explicitly asked