@n8n/instance-ai 1.21.2 → 1.22.0

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

@@ -68,7 +68,7 @@ Pick in this order:
 2. **Simplified Custom Auth** (`httpTemplatedCustomAuth`) for any service
    without a dedicated type whose auth is expressible as header/query/body
    values — which covers API keys and bearer tokens (`Authorization: Bearer
-   <token>` becomes `{"headers":{"Authorization":"Bearer {{api_key}}"}}`, not
+<token>` becomes `{"headers":{"Authorization":"Bearer {{api_key}}"}}`, not
    `httpBearerAuth`). Always provide a recipe (below) so the user only pastes
    their secret.
 3. **Plain generic types** (`httpBasicAuth`, `httpDigestAuth`, `oAuth2Api`, …)
@@ -121,26 +121,26 @@ key-check endpoint):
 
 ```json
 {
-  "action": "setup",
-  "workflowId": "...",
-  "credentialHints": [
-    {
-      "suggestedName": "fal.ai API Key",
-      "template": {
-        "headers": { "Authorization": "Key {{api_key}}" }
-      },
-      "placeholders": [
-        {
-          "name": "api_key",
-          "title": "fal.ai API key",
-          "info": "Key ID and secret, separated by a colon",
-          "type": "password"
-        }
-      ],
-      "docsUrl": "https://fal.ai/dashboard/keys",
-      "testUrl": "https://api.fal.ai/v1/models/usage"
-    }
-  ]
+	"action": "setup",
+	"workflowId": "...",
+	"credentialHints": [
+		{
+			"suggestedName": "fal.ai API Key",
+			"template": {
+				"headers": { "Authorization": "Key {{api_key}}" }
+			},
+			"placeholders": [
+				{
+					"name": "api_key",
+					"title": "fal.ai API key",
+					"info": "Key ID and secret, separated by a colon",
+					"type": "password"
+				}
+			],
+			"docsUrl": "https://fal.ai/dashboard/keys",
+			"testUrl": "https://api.fal.ai/v1/models/usage"
+		}
+	]
 }
 ```
 
@@ -265,16 +265,18 @@ For a workflow with more than one trigger (`triggerNodes` has multiple entries):
      again.
    - If `verificationReadiness.status === "already_verified"`, treat the
      workflow as verified and do **not** call `verify-built-workflow` again.
-  - If `verificationReadiness.status === "ready"`, call
-    `verify-built-workflow` with the `workflowId`, the `workItemId` when you
-    have it, and the trigger-appropriate `inputData` shape.
-   - If `verificationReadiness.status === "needs_setup"`, call
-     `workflows(action="setup")` with the workflowId so the user can configure it
-     through the inline setup card in the AI Assistant panel.
-   - If `verificationReadiness.status === "not_verifiable"`, do not infer
-     lower-level verification conditions; use the readiness guidance to give a
-     clear warning or manual-test note. This is a warning completion state, not
-     a verified state and not an infinite blocker.
+
+- If `verificationReadiness.status === "ready"`, call
+  `verify-built-workflow` with the `workflowId`, the `workItemId` when you
+  have it, and the trigger-appropriate `inputData` shape.
+- If `verificationReadiness.status === "needs_setup"`, call
+  `workflows(action="setup")` with the workflowId so the user can configure it
+  through the inline setup card in the AI Assistant panel.
+- If `verificationReadiness.status === "not_verifiable"`, do not infer
+  lower-level verification conditions; use the readiness guidance to give a
+  clear warning or manual-test note. This is a warning completion state, not
+  a verified state and not an infinite blocker.
+
 2. Judge coverage, not just status. A `verify-built-workflow` result with
    `success: true` but a non-empty `nodesNotReached` is **partial** evidence:
    the execution ended early (see `lastNodeExecuted` and `coverageNote`) and
@@ -282,7 +284,9 @@ For a workflow with more than one trigger (`triggerNodes` has multiple entries):
    - Most common cause: a lookup/query node returned zero items (n8n stops
      downstream nodes on empty item lists). If the dead-end is a Data Table
      lookup, insert a matching test row with `data-tables(action="insert-rows")`,
-     re-run `verify-built-workflow`, and delete the test row afterwards.
+     re-run `verify-built-workflow`, and delete the test row afterwards. The same
+     holds for data you seed anywhere else to unblock a run — it is yours to
+     remove once the run is done (see "Cleaning up after a live test").
    - If you cannot seed the data source, report honestly: name which nodes
      were verified and which were not, and tell the user the unreached part
      needs a manual test. Do not start a live `executions(action="run")`
@@ -315,16 +319,24 @@ For a workflow with more than one trigger (`triggerNodes` has multiple entries):
    when the latest verification evidence used mocks or simulations. If this
    follow-up is due, ask only whether the user wants the live test. Do not
    mention publishing or ask about the error workflow in the same response.
-7. If testing has not already been offered or completed, ask whether the user
+7. Before your final summary, scan the **whole conversation** for live runs that
+   already wrote test data into an external system — earlier turns included, not
+   just this one. For each such record still sitting there, follow
+   [Cleaning up after a live test](#cleaning-up-after-a-live-test): name it and
+   offer to remove it. This is about data that **already exists** — a promise to
+   clean up after some future run does not discharge it, and neither does the
+   user's silence. If a later run failed, that says nothing about records an
+   earlier successful run left behind; they are still there.
+8. If testing has not already been offered or completed, ask whether the user
    wants to test the workflow. Skip this if `verify-built-workflow` already
    proved it works end-to-end with full coverage.
-8. Only call `workflows(action="publish")` when the user explicitly asks to
+9. Only call `workflows(action="publish")` when the user explicitly asks to
    publish. Never publish automatically or proactively offer publishing before
    the publish-readiness requirement above is met.
-9. After a direct new primary workflow is successfully published, follow
-   [Error workflow follow-up](#error-workflow-follow-up).
-   Do not replace this explicit opt-in with a generic "add
-   anything else?", publish, or test question.
+10. After a direct new primary workflow is successfully published, follow
+    [Error workflow follow-up](#error-workflow-follow-up).
+    Do not replace this explicit opt-in with a generic "add
+    anything else?", publish, or test question.
 
 ## Error workflow follow-up
 
@@ -397,6 +409,49 @@ not offer publishing. If the user declines or defers, state what remains
 untested, do not claim live end-to-end verification, and do not offer
 publishing.
 
+## Cleaning up after a live test
+
+A live run against real credentials leaves **real artifacts** — a row in their
+sheet, a message in their channel, a block on their page. Test data you created
+is your mess, not theirs.
+
+This applies to any live run in the conversation, **not only one from this
+turn**. A test record written three turns ago is still on the user's page now,
+and the debt is still yours — carry it forward until it is cleared or the user
+declines. Undertaking to clean up after some _future_ run does not settle a
+record that already exists, and a run that failed afterwards does not remove
+what an earlier successful run wrote.
+
+When a live test, or a verification you seeded data for, wrote/sent/changed
+anything in an external system:
+
+1. **Name what it left behind**, in the message that reports the run — or, for a
+   record from an earlier turn, in your next response: which record, where, and
+   how to recognise it ("a `[Test] …` to-do at the bottom of
+   the toggle"). Read it back from the effect node's output rather than guessing.
+2. **Offer to remove it yourself.** You can delete it the same way you wrote it —
+   the target has an API and you can reach it with a workflow. When no node or
+   tool does it directly, build a **one-off cleanup workflow**; that is exactly
+   what `one-off-operations` is for. Never present manual deletion as how this
+   gets resolved, and never claim you have no way to delete it — "I don't have a
+   delete tool for X" is false whenever X has a write API you just used. Noting
+   that the user _could_ also remove it by hand is fine only alongside your own
+   offer.
+3. **Ask before deleting.** Removal is destructive, so it goes through the usual
+   approval gate. Never clean up silently — something labelled "test" may still
+   be data the user wants.
+4. **Don't stack test data.** Do not offer another live run against the same
+   target while an earlier test artifact is still sitting there. Clear it first,
+   or say plainly that the next run will add a second one.
+
+If the user declines, note that the item is still there and move on — don't
+re-ask.
+
+**Not every write is test data.** When the live run _was_ the point — a one-off
+operation whose whole purpose is the effect (see `one-off-operations`) — what it
+wrote is the deliverable. There you offer to clean up the _workflow_, never the
+result.
+
 ## Claiming success
 
 Do not tell the user a workflow is "fixed", "verified", "tested", "working", or
@@ -411,8 +466,8 @@ complete; do not infer correctness from the fact that a node ran. The same
 applies to rows or records written to an external system: never make quantitative
 claims ("22 rows written", "columns matched") that you did not read back from
 the effect node's actual output (`executions(action="get-node-output")`) or from
-the target system itself — a successful run status does not prove the *right
-data* was written, only that nodes ran. If you could not run the
+the target system itself — a successful run status does not prove the _right
+data_ was written, only that nodes ran. If you could not run the
 failing path or inspect the artifact, say so plainly — "I couldn't verify X
 because Y" — and name what is unconfirmed. An honest "could not verify" beats an
 unverified success claim.
@@ -444,6 +499,18 @@ building, and use the chosen credential name in the workflow code. Exception: th
 user already named the credential in their message — use it directly. With a
 single candidate, auto-apply and do not ask.
 
+**Honor an explicit "create a new credential" request.** When the user asks for a
+new credential of a type, never pick an existing one for them and never ask them
+to choose among existing ones — not even when exactly one exists (the build would
+otherwise attach it silently and skip setup entirely). Pass the credential type in
+`preferNewCredentials` on both `build-workflow` and `workflows(action="setup")`
+(or `preferNew: true` on the `credentials(action="setup")` entry). Setup then
+opens on credential creation while still listing the existing credentials, so the
+user can change their mind — say so in one short sentence rather than
+re-litigating the choice. If they had skipped that card earlier, pass
+`reopenSkipped` alongside it: `preferNewCredentials` decides what the card offers,
+`reopenSkipped` decides whether the card comes back at all.
+
 **Ask which auth type to use when a service supports more than one.**
 `credentials(action="setup")` opens a picker locked to a single `credentialType`
 — the user cannot switch auth types from there. So when

package/skills/workflow-builder/SKILL.md

@@ -325,6 +325,16 @@ 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 the user explicitly asks for a **new** credential ("create a new Slack
+  credential"), the unresolved `newCredential('Name')` is not enough on its own —
+  the build would still attach their sole existing credential of that type, and
+  setup would preselect their most recent one. Pass the credential type in
+  `preferNewCredentials` on `build-workflow` **and** on
+  `workflows(action="setup")` (or `preferNew: true` on the entry of
+  `credentials(action="setup")`). The slot then stays unresolved through the build
+  and the card opens on credential creation, with existing credentials still
+  listed in case the user changes their mind. Pass it only on an explicit request,
+  never by default — reuse is the right behavior everywhere else.
 - When `build-workflow` returns `resolvedCredentialsByNode`, the build already
   attached a credential to those nodes — either an existing stored credential or
   an n8n credits–managed one (entries with `id: null` and `__aiGatewayManaged:
@@ -593,8 +603,9 @@ first.
 
 `.group(name, members, { description })` on the workflow builder; members are the node handles.
 Read `knowledge-base/reference/node-groups.md` for the exact rules (trigger nodes excluded,
-one connected section, AI sub-nodes stay with their Agent) before creating groups — an invalid
-group is rejected on save. When editing an existing workflow, keep existing `.group(...)` calls
+one connected section, AI sub-nodes stay with their Agent) before creating groups. Agent save
+tools drop an invalid group from the saved workflow and report a warning, so fix the source
+instead of re-emitting it. When editing an existing workflow, keep existing `.group(...)` calls
 and their descriptions intact unless the change is about grouping.
 
 ## Workflow Rules